4 ms·

> 10x every project timeline and it's fixed, simple as. I'm skeptical. I've seen too many developers write poorly performing code purely out of indifference. I

> 10x every project timeline and it's fixed, simple as. I'm skeptical. I've seen too many developers write poorly performing code purely out of indifference. If you gave them more time they'd have a lot more Reddit karma but I'd still be finding N+1 problems in every other code review.

WettowelReactor 3y ago
Is it really indifference or are employees responding to incentives? Few places reward code performance. Companies are getting exactly what they pay for and missing a deadline to improve efficiency is irrational under current comp strategies.
therealdrag0 3y ago
“Premature optimization…” we’re taught early on not to waste time on investigating performance.
jmmv 3y ago
Indifference... or lack of knowledge. I've conducted hundreds of interviews and it's interesting how many people know their O notation and how they can write code that theoretically is "efficient"... but performance is in the details and in knowing the stack top-to-bottom, and most people just don't know that. And the real problem is that they don't know what they don't know. You'd say that code reviews is where this stuff should be caught, but unfortunately, code reviews are performative in most cases or the reviewers also don't know / care about these details either.
- jeremyjh 3y ago
  Most people don’t catch it in code reviews, and I don’t catch everything, but I catch a lot. I see knowledge transfer as the primary purpose of code reviews though.
- SamuelAdams 3y ago
  The real reason is the industry. We don’t reward deep knowledge of a particular language anymore. Things change too quickly. Imagine a really good Angular dev who’s been using it for 7+ years. Sure, their code might be fast, but everything’s moving to React now. Even backend languages change quite a bit. .NET Core is a big winner in performance compared to .NET Framework, but you can still write lousy-performing code in it. From an architecture perspective, people seem to have a hard-on for serverless lately. Which typically involves considerably more HTTP requests, which causes performance issues. On a simple test system things are fast enough, but once you scale the latency starts to add up.
  - etherealG 3y ago
    Sorry to say, but it’s no different now than before in terms of skills and keeping up with “deep knowledge” to be successful in the way described above. Sure, things move quicker now… but pace of change was never the challenge for good vs. bad engineers. The good ones easily keep up now, and the bad ones still existed when pace of change was slower. In my experience it’s more about people’s willingness to invest in deep understanding. Bad engineers generally just don’t care to learn their stack deeply.
hinkley 3y ago
Or they'll write an engine so they don't ever have to write any boring code again.
jbergens 3y ago
When you have more time and budget for a project you can teach junior developers to optimize code better.

WettowelReactor 3y ago

Is it really indifference or are employees responding to incentives? Few places reward code performance. Companies are getting exactly what they pay for and missing a deadline to improve efficiency is irrational under current comp strategies.

therealdrag0 3y ago

“Premature optimization…” we’re taught early on not to waste time on investigating performance.

jmmv 3y ago

Indifference... or lack of knowledge. I've conducted hundreds of interviews and it's interesting how many people know their O notation and how they can write code that theoretically is "efficient"... but performance is in the details and in knowing the stack top-to-bottom, and most people just don't know that. And the real problem is that they don't know what they don't know. You'd say that code reviews is where this stuff should be caught, but unfortunately, code reviews are performative in most cases or the reviewers also don't know / care about these details either.

jeremyjh 3y ago
Most people don’t catch it in code reviews, and I don’t catch everything, but I catch a lot. I see knowledge transfer as the primary purpose of code reviews though.
SamuelAdams 3y ago
The real reason is the industry. We don’t reward deep knowledge of a particular language anymore. Things change too quickly. Imagine a really good Angular dev who’s been using it for 7+ years. Sure, their code might be fast, but everything’s moving to React now. Even backend languages change quite a bit. .NET Core is a big winner in performance compared to .NET Framework, but you can still write lousy-performing code in it. From an architecture perspective, people seem to have a hard-on for serverless lately. Which typically involves considerably more HTTP requests, which causes performance issues. On a simple test system things are fast enough, but once you scale the latency starts to add up.
- etherealG 3y ago
  Sorry to say, but it’s no different now than before in terms of skills and keeping up with “deep knowledge” to be successful in the way described above. Sure, things move quicker now… but pace of change was never the challenge for good vs. bad engineers. The good ones easily keep up now, and the bad ones still existed when pace of change was slower. In my experience it’s more about people’s willingness to invest in deep understanding. Bad engineers generally just don’t care to learn their stack deeply.

hinkley 3y ago

Or they'll write an engine so they don't ever have to write any boring code again.

jbergens 3y ago

When you have more time and budget for a project you can teach junior developers to optimize code better.