5 ms·

We software engineers are still more like alchimists rather than chemists. That list reminds me of [1], which rants about this state of affairs and [2] that pu

by rwoerz 6y ago

We software engineers are still more like alchimists rather than chemists. That list reminds me of [1], which rants about this state of affairs and [2] that puts many beliefs to the test. [1] https://youtu.be/WELBnE33dpY https://youtu.be/WELBnE33dpY [2] https://www.oreilly.com/library/view/making-software/9780596808310/ https://www.oreilly.com/library/view/making-software/9780596...

fmakunbound 6y ago
In addition to that, I also feel calling ourselves engineers is a stretch.
- milquetoastaf 6y ago
  Agreed. If we were actually engineers we'd all be writing TLA+ and Coq to verify the correctness of what we do and there'd be a formal cert program codified by the state
- hwayne 6y ago
  I used to think this, and then I interviewed people who did both traditional and software engineering professionally, and now I'm not so sure. I did a first draft of what I learned here: https://www.youtube.com/watch?v=3018ABlET1Y https://www.youtube.com/watch?v=3018ABlET1Y I'm hoping to have a written version by the end of September.
  - fmakunbound 6y ago
    Fair enough! You make some great points there which changed my perspective.
  - ozim 6y ago
    This is great. People romanticize construction, mechanical and other engineering like there would be no failures in those disciplines. Buildings collapse, machines break down in unforeseen circumstances. My pet theory is that in software it is just a lot easier to create a lot of stuff, so it is also a lot easier to create issues. You can add that in eastern Europe you can get engineering degree which is "technical bachelor" from technical university, so I am software engineer as it is printed in my diploma.
    - rwoerz 6y ago
      Yes, software is immaterial and thus not constrained by laws of physic (except speed of light). It is comparably easy to change but also comparably hard to specify and model in advance.
    - gjulianm 6y ago
      It's not about the failures, it's about the modes of failure. I assume that the modes of failure of a bridge, or of a building, are pretty well understood. Software has far more distinct pieces than any other product you can find anywhere (maybe the human body?) so it's impossible to completely check the modes of failure. I was just reading before about a hardware corruption bug due to a kernel feature [1] and it's hard to imagine the same chain reaction in other engineering areas. In software it's also really hard to model behavior. In engineering you'll get tolerances, strength and other features of the pieces you use. In software, you can't even benchmark something and expect the same benchmark to translate to a different computer. 1: https://lwn.net/Articles/304105/ https://lwn.net/Articles/304105/
  - mkoubaa 6y ago
    I'm a mechanical engineer who writes software for mechanical engineers. I find that the work of MechE moves slower due to operational issues. if there could move fast and break things cheaply to get to market faster they would. all that matters is that the final product is tested and hardened which is something that software shops mostly do anyways not to mention things like generative design and process automation are getting us to that point.
- rurp 6y ago
  I don't know, my partner works at a civil engineering firm and the day to day work there sounds pretty similar to what I do as a software dev. Sometimes they have to do complicated calculations and research, but by far most of the work is copying templates and tweaking them as needed. The hardest part of most projects is taking unrealistic and ever changing client demands and trying to turn them into something that will actually work in reality; a process which is probably all too familiar to many software developers.
- dynamite-ready 6y ago
  I think that's a very interesting point. I think software 'engineering' is uniquely ambiguous in this regard, because software development as a discipline is in equal parts both design, and construction, and the design part bleeds into the 'construction' part, corrupting it (for want of a better word) in a way you would imagine that 'pure' engineering would not.
- realtalk_sp 6y ago
  I suspect many developers would find software a lot less appealing if it were closer to a traditional engineering discipline (slow, unforgiving, dramatically reduced expressive power and creative potential, etc). I'm somewhat ADD and get bored easily, so not only do I need to do something more like software but I also have to stay as broad and high-level as possible within the discipline, to stave off ennui. NOTE: very much not arguing this is a good way to go through life.
- elric 6y ago
  I've always considered "engineer" to be more of a personality trait than a formal qualification. Most engineers I've met (whether Software, Bio, Civil or whatever) have a similar mindset to my own, although that might be selection bias at play. There's a sense of curiosity and wanting to understand, not in an academic way, but by virtue of doing.
mistermann 6y ago
> "...but I do want to underscore a really important point: almost everything in software is a belief - it is something we have experience about, it is something we have opinions on, but it's not something we have hard data on. In most cases, we just don't know. But we can find out. We find out through..." This seems applicable to everything, almost, in this whole experiment humans have going on here on planet earth, it just doesn't seem like it. To see it, you have to have (at least) the ability and willingness to look.
JAlexoid 6y ago
Because most of the issues arise from the bug that is present between the chain and the keyboard. The issues are us - the developers. The machine code is mostly fine...

by rwoerz 6y ago

fmakunbound 6y ago

In addition to that, I also feel calling ourselves engineers is a stretch.

milquetoastaf 6y ago
Agreed. If we were actually engineers we'd all be writing TLA+ and Coq to verify the correctness of what we do and there'd be a formal cert program codified by the state
hwayne 6y ago
I used to think this, and then I interviewed people who did both traditional and software engineering professionally, and now I'm not so sure. I did a first draft of what I learned here: https://www.youtube.com/watch?v=3018ABlET1Y https://www.youtube.com/watch?v=3018ABlET1Y I'm hoping to have a written version by the end of September.
- fmakunbound 6y ago
  Fair enough! You make some great points there which changed my perspective.
- ozim 6y ago
  This is great. People romanticize construction, mechanical and other engineering like there would be no failures in those disciplines. Buildings collapse, machines break down in unforeseen circumstances. My pet theory is that in software it is just a lot easier to create a lot of stuff, so it is also a lot easier to create issues. You can add that in eastern Europe you can get engineering degree which is "technical bachelor" from technical university, so I am software engineer as it is printed in my diploma.
  - rwoerz 6y ago
    Yes, software is immaterial and thus not constrained by laws of physic (except speed of light). It is comparably easy to change but also comparably hard to specify and model in advance.
  - gjulianm 6y ago
    It's not about the failures, it's about the modes of failure. I assume that the modes of failure of a bridge, or of a building, are pretty well understood. Software has far more distinct pieces than any other product you can find anywhere (maybe the human body?) so it's impossible to completely check the modes of failure. I was just reading before about a hardware corruption bug due to a kernel feature [1] and it's hard to imagine the same chain reaction in other engineering areas. In software it's also really hard to model behavior. In engineering you'll get tolerances, strength and other features of the pieces you use. In software, you can't even benchmark something and expect the same benchmark to translate to a different computer. 1: https://lwn.net/Articles/304105/ https://lwn.net/Articles/304105/
- mkoubaa 6y ago
  I'm a mechanical engineer who writes software for mechanical engineers. I find that the work of MechE moves slower due to operational issues. if there could move fast and break things cheaply to get to market faster they would. all that matters is that the final product is tested and hardened which is something that software shops mostly do anyways not to mention things like generative design and process automation are getting us to that point.
rurp 6y ago
I don't know, my partner works at a civil engineering firm and the day to day work there sounds pretty similar to what I do as a software dev. Sometimes they have to do complicated calculations and research, but by far most of the work is copying templates and tweaking them as needed. The hardest part of most projects is taking unrealistic and ever changing client demands and trying to turn them into something that will actually work in reality; a process which is probably all too familiar to many software developers.
dynamite-ready 6y ago
I think that's a very interesting point. I think software 'engineering' is uniquely ambiguous in this regard, because software development as a discipline is in equal parts both design, and construction, and the design part bleeds into the 'construction' part, corrupting it (for want of a better word) in a way you would imagine that 'pure' engineering would not.
realtalk_sp 6y ago
I suspect many developers would find software a lot less appealing if it were closer to a traditional engineering discipline (slow, unforgiving, dramatically reduced expressive power and creative potential, etc). I'm somewhat ADD and get bored easily, so not only do I need to do something more like software but I also have to stay as broad and high-level as possible within the discipline, to stave off ennui. NOTE: very much not arguing this is a good way to go through life.
elric 6y ago
I've always considered "engineer" to be more of a personality trait than a formal qualification. Most engineers I've met (whether Software, Bio, Civil or whatever) have a similar mindset to my own, although that might be selection bias at play. There's a sense of curiosity and wanting to understand, not in an academic way, but by virtue of doing.

mistermann 6y ago

> "...but I do want to underscore a really important point: almost everything in software is a belief - it is something we have experience about, it is something we have opinions on, but it's not something we have hard data on. In most cases, we just don't know. But we can find out. We find out through..." This seems applicable to everything, almost, in this whole experiment humans have going on here on planet earth, it just doesn't seem like it. To see it, you have to have (at least) the ability and willingness to look.

JAlexoid 6y ago

Because most of the issues arise from the bug that is present between the chain and the keyboard. The issues are us - the developers. The machine code is mostly fine...