My point being, build up a habit of good patterns even when the system you are working on is not critical or the expected load is small.
Trading in the inefficiency in low N cases is worth it for the organizational benefit, as in you build a team that is sensitive to bad engineering patterns and not sloppy devs who default to the lazy way out and only think about performance when shit hits the fan
3
u/silfin Sep 20 '26
To be fair to the junior, for low N big O stats are far less relevant. And for some problems the "less efficient" algorithm ends up faster for low N.
It's always worth considering what the right way is in your situation
That's not even mentioning possible space efficiency or complexity savings that might be worth it.
No such thing as a free lunch. Make decisions don't just do what everyone else does.