4 ms·
I used to manage a team of devs who looked down on other devs for not knowing what Big O is. I've argued with them more than once that yes, their algorithm is t
by rrrjjjqqq 9y ago
I used to manage a team of devs who looked down on other devs for not knowing what Big O is. I've argued with them more than once that yes, their algorithm is technically more efficient, but the 20 extra network calls they're adding means it's going to perform significantly worse without exponential growth. I'd rather have a person on my team who can develop solutions for the circumstances they're working in over a person that can write perfect, white paper worthy code for spherical cows in vacuums any day.
- dsacco 9y agoI think that's an orthogonal issue. Prematurely optimizing, or inappropriately optimizing code by over-engineering its efficiency is mutually exclusive from knowing how to optimize in the first place. It's a bit of a false dichotomy - you don't have two camps, one which understands optimization and does it too much, and another which doesn't understand it and produces code faster. It's a fair expectation to have developers reasonably cognizant of computer science fundamentals and also to utilize them sparingly and appropriately. In the same way, it's important to understand how microservice architecture works and what its benefits are for scale at a theoretical level, at least. But that does not mean that you split everything into microservices for a GitHub side project or for a SaaS with fewer than 100 active users. When you need the tool, you open your toolbox. But the mere presence of the tool does not mean it will be used. I also don't think it's fair to look down on peers for a lack of education, as long as they are not willfully antagonistic to improving themselves.