←back to thread

127 points leoncaet | 1 comments | | HN request time: 0.397s | source
Show context
burnt-resistor ◴[] No.44539155[source]
I'm disillusioned because it never happens, but purveyors of conferences and books are happy to sell the promised land™ of how "it's really going to be different this time."

Processes, tools, and diligence vigilantly seem the most apparent path. Perhaps rehash the 50 year old debate of professionalization while AI vibes coding is barking at the door, because what could possibly go wrong with even less experience doing the same thing and expecting a different result.

replies(3): >>44540097 #>>44540223 #>>44540697 #
rachofsunshine ◴[] No.44540697[source]
It doesn't happen because building the best software is not the goal of a software engineering job.

If you want to do that on your own time, that's fine - but the purpose of a job is economic. Of course you should write software of some reasonable quality, but optimizations have diminishing economic returns. Eventually, the returns are lower than the cost (in time, money, etc) of further optimizing, and this break-even point is usually at a lower level of quality than engineers would like it to be. Leadership and engineering managers know this and behave accordingly.

replies(3): >>44540744 #>>44540803 #>>44540961 #
jcgrillo ◴[] No.44540744[source]
While I agree with everything you've said, I think you might be making an assumption that quality costs time. In my experience this isn't the case, unless you're starting from a low quality codebase or working with low quality people. A high quality team can produce high quality software in less time than it takes a low quality team to produce low quality software meeting the same functional requirements.

The whole ballgame is making sure you have no low quality people on your team.

replies(3): >>44541062 #>>44541235 #>>44541437 #
1. ◴[] No.44541062[source]