rrrjjjqqq

I agree that there's a balance between the two. My ideal team is probably a quarter that know core CS concepts and how/when to use them and the other three quarters devs can write good code whether or not they know core CS concepts.

The part that makes me frustrated enough to comment on this is that I've found that a lot easier to convince a dev who doesn't know Big O that they need to than it is to convince a dev that does know Big O that it's not always necessary. Convincing is significantly harder if the dev graduated from college in the past 3 years.

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.

I just left a low paying 80 hour a week job for a high paying 40 hour a week job with that exact logic - I can do what makes me tick in my spare time.

As it turns out, that's a lot harder than you're making it sound. I absolutely loved my previous job, where I was building a quality product that I knew my customers would enjoy. There were some leadership-related issues that came up there, so I thought I could build a product on my own in my extra 40 hours a week. Now I have no product (or product ideas) and no customers. Instead I spend my time networking with people who might have those two things. I feel like I lost out, even though I'm getting higher pay.