4 ms·

The reason is that the money people don't want to pay for it. We absolutely have the coding talent to make efficient, maintainable code, what we don't have are

The reason is that the money people don't want to pay for it. We absolutely have the coding talent to make efficient, maintainable code, what we don't have are the available payroll hours. 10x every project timeline and it's fixed, simple as. Granted, the big downside is, you have to keep your talent motivated and on-task 10x as long, that's like turning a quarter horse into a plough horse, it's not likely to happen quickly, if at all. You'd really need to start over with the kids who are in highschool now writing calculator apps in python by making them re-write them in C and grade them on how few lines they use. ie, it's a pipe dream, and will continue to be until we run out of hardware capability, which has been "soon" for the last 30 years, so don't hold your breath.

runeks 3y ago
> 10x every project timeline and it's fixed, simple as. > Granted, the big downside is, you have to keep your talent motivated and on-task 10x as long [...] No, the big downside is that you have to tell your client it'll be 10x times as expensive because you want better performance.
jeremyjh 3y ago
> 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.

runeks 3y ago

> 10x every project timeline and it's fixed, simple as. > Granted, the big downside is, you have to keep your talent motivated and on-task 10x as long [...] No, the big downside is that you have to tell your client it'll be 10x times as expensive because you want better performance.

jeremyjh 3y ago

> 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.