Hacker News Reader

Hacker News

Comment by rwoerz | Hacker News Reader

Full thread

rwoerz

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

[2] https://www.oreilly.com/library/view/making-software/9780596...

View on HN

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

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

I'm hoping to have a written version by the end of September.

Fair enough! You make some great points there which changed my perspective.

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.

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.

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/

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.

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.

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.

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.

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.

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

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

Reply on news.ycombinator.com