5 ms·

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 differen

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.

intelVISA 1y ago
Aye, it never happens but it does sell a lot of books ;) I don't think we'll reach this promised land™ until incentives re-align. Treating software as an assembly line was obviously The Wrong Thing judging by the results - problem is how can we ever move to a model that rewards quality perhaps similar to (book) authors and royalties? Owner-operator SaaS is about as close as you can get but limits you to web and web-adjacent.
- ozim 1y ago
  Just like all the fitness content. Get couple shredded guys and gals to show off how fit they are so everyone feels guilty they are snacking past 8PM. Sell another batch of “how to do pushups” followed by “how to do pushups vol.2” with “pushup pro this time even better”. Where in the end normal people are not getting paid for getting shredded, they get paid for doing their stuff. I just constantly feel like I am not a proper dev because I mostly skip unit tests - but on the other hand I built last 15 years couple of systems that worked and were bringing in value.
  - zoover2020 1y ago
    Why would you skip unit tests? Especially in the AI age. You can quickly verify your behavior. Also, by not writing them you're also missing out on opportunities to modularize your code. Obviously, this assumes you write enterprise grade code. YMMV
    - ozim 1y ago
      You can write modular code without writing tests - I write testable code - I don't write tests. When I need I can always add them back, but I tend to skip it as mostly it doesn't make sense. But still cottage industry of "clean code" is pushing me into self doubts and shame.
      - esafak 1y ago
        If it's testable it's trivial to write tests for! You don't want the next person to introduce a bug, do you?
        ozim 1y ago
        Read my original post again. We don’t have bugs that all those “do it right way” people claim doing it for 15 years with good track record. You just contribute to BS scare tactics of people selling “clean code”.
        esafak 1y ago
        How do you know you don't have bugs? Is everything instrumented (observable)? I could just as easily say you're peddling ignorance as bliss!
        ozim 1y ago
        You can have a lot of other processes and tests on other levels than unit tests ;)
      - sigwinch 1y ago
        That’s how I do it. 100% test coverage doesn’t make bug reports irrelevant. Every test should have a reason.
      - capyba 1y ago
        I’m a mechanical engineer, not a software person, but I write a lot of (hopefully close to professional quality) code for my work. writing tests while in the beginning/middle of my development cycle has been the best change I’ve made in how I do things in quite a long time. Since I’m a self-taught amateur often working solo, its invaluable for helping me gain confidence that everything I’m doing is working correctly as I learn the language/libraries necessary for me to build each new program. I’m not saying that you yourself have this attitude - but the “tests are for suckers, I just ship” crowd really grinds my gears because to me it says “ha! Why do you care about getting things right?” Totally get where you’re coming from though, sometimes the expected behavior is trivial to verify or (in the case of GUIs) can be very difficult and not worth the effort to implement.
  - qznc 1y ago
    You could switch into a domain where safety-critical software is developed. Here devs complain about the inverse problem: Why are we required to have 100% test coverage?! (The answer btw: Because nobody would be able to explain to a jury/judge that 80% or whatever is enough)
    - pydry 1y ago
      Or they complain that they know everything has gone to hell but if they blow the whistle revenge will be taken against them. Everybody who worked with the 2005 Toyota Camry ETCS would have known what was up when it killed a few people, for example. Nobody can work on spaghetti code of that magnitude and not realize that something is off. Boeing employees who tried to blow the whistle were similarly ignored or silenced while a few died in mysterious circumstances.
jackblemming 1y ago
It happens when an ex-engineer is in a leadership position. The results are good, but it’s typically a small part of having a successful company. However, you should want to build quality software because building quality things is fulfilling. Unfortunately certain systems have made the worship of money the end all be all of human experience.
- burnt-resistor 1y ago
  The cult of morbid wealth slithered into the minds of people who have little or no money yet see themselves as temporarily-embarrassed, future billionaires because they work at one of the corporations as a peon or see billionaires on TV.
rachofsunshine 1y ago
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.
- jcgrillo 1y ago
  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.
  - deleted 1y ago
    [deleted]
  - wiseowise 1y ago
    > 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. Key word is ‘can’. And it takes far more time and money to assemble “quality” team.
  - rachofsunshine 1y ago
    This isn't an apples-to-apples comparison. The quality of your team is more-or-less a pre-existing background variable. The question is whether a team of comparable quality takes longer to produce quality software than hacked-together software, and the answer appears to be "yes". The only way out of this is if optimizing more for code quality *actually helps you recruit better engineers*. I can put a little data to that question, at least. I run a recruiting company that does interviews, so we have data both on preferences and on apparent skill level. I went and split our data set by whether an engineer indicated that emphasis on code quality was important to them. Our data suggests that you can probably make slightly better hires (in a raw technical-ability sense) by appealing to that candidate pool: - Candidates who emphasized quality were slightly (non-significantly) more likely to pass our interview and, - Candidates who emphasized quality were slightly (non-significantly) less likely to have gotten a job already The effect is pretty small, though, and I doubt it outweighs the additional cost.

intelVISA 1y ago

Aye, it never happens but it does sell a lot of books ;) I don't think we'll reach this promised land™ until incentives re-align. Treating software as an assembly line was obviously The Wrong Thing judging by the results - problem is how can we ever move to a model that rewards quality perhaps similar to (book) authors and royalties? Owner-operator SaaS is about as close as you can get but limits you to web and web-adjacent.

ozim 1y ago
Just like all the fitness content. Get couple shredded guys and gals to show off how fit they are so everyone feels guilty they are snacking past 8PM. Sell another batch of “how to do pushups” followed by “how to do pushups vol.2” with “pushup pro this time even better”. Where in the end normal people are not getting paid for getting shredded, they get paid for doing their stuff. I just constantly feel like I am not a proper dev because I mostly skip unit tests - but on the other hand I built last 15 years couple of systems that worked and were bringing in value.
- zoover2020 1y ago
  Why would you skip unit tests? Especially in the AI age. You can quickly verify your behavior. Also, by not writing them you're also missing out on opportunities to modularize your code. Obviously, this assumes you write enterprise grade code. YMMV
  - ozim 1y ago
    You can write modular code without writing tests - I write testable code - I don't write tests. When I need I can always add them back, but I tend to skip it as mostly it doesn't make sense. But still cottage industry of "clean code" is pushing me into self doubts and shame.
    - esafak 1y ago
      If it's testable it's trivial to write tests for! You don't want the next person to introduce a bug, do you?
      - ozim 1y ago
        Read my original post again. We don’t have bugs that all those “do it right way” people claim doing it for 15 years with good track record. You just contribute to BS scare tactics of people selling “clean code”.
        esafak 1y ago
        How do you know you don't have bugs? Is everything instrumented (observable)? I could just as easily say you're peddling ignorance as bliss!
        ozim 1y ago
        You can have a lot of other processes and tests on other levels than unit tests ;)
    - sigwinch 1y ago
      That’s how I do it. 100% test coverage doesn’t make bug reports irrelevant. Every test should have a reason.
    - capyba 1y ago
      I’m a mechanical engineer, not a software person, but I write a lot of (hopefully close to professional quality) code for my work. writing tests while in the beginning/middle of my development cycle has been the best change I’ve made in how I do things in quite a long time. Since I’m a self-taught amateur often working solo, its invaluable for helping me gain confidence that everything I’m doing is working correctly as I learn the language/libraries necessary for me to build each new program. I’m not saying that you yourself have this attitude - but the “tests are for suckers, I just ship” crowd really grinds my gears because to me it says “ha! Why do you care about getting things right?” Totally get where you’re coming from though, sometimes the expected behavior is trivial to verify or (in the case of GUIs) can be very difficult and not worth the effort to implement.
- qznc 1y ago
  You could switch into a domain where safety-critical software is developed. Here devs complain about the inverse problem: Why are we required to have 100% test coverage?! (The answer btw: Because nobody would be able to explain to a jury/judge that 80% or whatever is enough)
  - pydry 1y ago
    Or they complain that they know everything has gone to hell but if they blow the whistle revenge will be taken against them. Everybody who worked with the 2005 Toyota Camry ETCS would have known what was up when it killed a few people, for example. Nobody can work on spaghetti code of that magnitude and not realize that something is off. Boeing employees who tried to blow the whistle were similarly ignored or silenced while a few died in mysterious circumstances.

jackblemming 1y ago

It happens when an ex-engineer is in a leadership position. The results are good, but it’s typically a small part of having a successful company. However, you should want to build quality software because building quality things is fulfilling. Unfortunately certain systems have made the worship of money the end all be all of human experience.

burnt-resistor 1y ago
The cult of morbid wealth slithered into the minds of people who have little or no money yet see themselves as temporarily-embarrassed, future billionaires because they work at one of the corporations as a peon or see billionaires on TV.

rachofsunshine 1y ago

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.

jcgrillo 1y ago
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.
- deleted 1y ago
  [deleted]
- wiseowise 1y ago
  > 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. Key word is ‘can’. And it takes far more time and money to assemble “quality” team.
- rachofsunshine 1y ago
  This isn't an apples-to-apples comparison. The quality of your team is more-or-less a pre-existing background variable. The question is whether a team of comparable quality takes longer to produce quality software than hacked-together software, and the answer appears to be "yes". The only way out of this is if optimizing more for code quality *actually helps you recruit better engineers*. I can put a little data to that question, at least. I run a recruiting company that does interviews, so we have data both on preferences and on apparent skill level. I went and split our data set by whether an engineer indicated that emphasis on code quality was important to them. Our data suggests that you can probably make slightly better hires (in a raw technical-ability sense) by appealing to that candidate pool: - Candidates who emphasized quality were slightly (non-significantly) more likely to pass our interview and, - Candidates who emphasized quality were slightly (non-significantly) less likely to have gotten a job already The effect is pretty small, though, and I doubt it outweighs the additional cost.