HN Theater @HNTheaterMonth

I found this video on the topic very compelling: Intro to Empirical Software Engineering: What We Know We Don't Know • Hillel Wayne • GOTO 2019: https://www.youtube.com/watch?v=WELBnE33dpY

If Hillel Wayne’s talk on empirical software design is any good measure then either method is fine[0] so long as you and the team you work with can agree about it’s utility in code review. If it’s just you on the project then do whatever is most comfortable.

[0] https://m.youtube.com/watch?v=WELBnE33dpY

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

⬐ JAlexoid

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

⬐ mistermann

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

⬐ fmakunbound

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

⬐ realtalk_sp

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.

⬐ rurp

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.

⬐ elric

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.

⬐ dynamite-ready

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.

⬐ milquetoastaf

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

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.

⬐ mkoubaa

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.

⬐ fmakunbound

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

⬐ ozim

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

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

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/

⬐ undreren

I thought this was a very thought provoking talk, even if we talk nothing the speaker says for granted.

A year or so ago I had a semi-breakdown over the fact that all the best practices I stood by was more or less just a regurgitation of what some software "guru" had to say on the subject. I didn't know if it was true, but I damn sure believed it.

I believed so hard that my opinions and feelings was almost (if not entirely) religious in nature. Sure, I had some experiences with things that absolutely did not work, some techniques that worked under the specific circumstances I applied them in.

But in general? After 10 years of software development, I can't tell you why I solve a specific kind of coding problem the way I do. I can give you a lot of reasons, but only based on vague hand-wavey stuff such as feelings and experience.

Don't get me wrong; experience is really great. But it's not the same as truth. What works for me might not work for you, and vice versa. And what I believe works for me might in fact slow me down.

And there's no real way for me to know for sure.

⬐ hwayne

I put all of the references, slides, and questions I got here: https://www.hillelwayne.com/talks/what-we-know-we-dont-know/