- cross-posted to:
- talks@programming.dev
- cross-posted to:
- talks@programming.dev
You must log in or register to comment.
Can’t watch atm. What’s the gist of it?
Dude interviewed some people that did both software and other forms of engineering. Vast majority said software engineering is real engineering.
These are a few things that stood out to me.
In software engineering the gap between tradecraft and engineering is a lot smaller than the other engineering fields like electricians and electrical engineers.
Software engineering can iterate faster because it’s cheap. If civil engineers could iterate like software engineers they would. New modeling tools are allowing this.
A lot of physical engineering defects are being fixed with software. 737 Max was given as an example where the new engine configuration made the plane unstable and it was fixed in software.
A lot of things can be learned from the different fields. All the other engineering fields wish they had version control. Software engineering needs more very focused deep dive books like this the other engineering fields have. Ex: https://www.amazon.com/First-Snap-Fit-Handbook-3E-Attachments/dp/1569905959
Holy balls, thank you! Expected nothing, got an amazing summary!
Lemmy might actually stand a chance.
Thank you for the thorough write-up. I’m surprised the answer is a “(mostly) yes” (Betteridge’s law).
Will listen to it as soon as I have time.
I was going to ask if it seemed to have overlap with this article. Then I noticed the author of the article is the one that gave the talk, so I’m taking that as a yes.
Removed by mod
TLDW. But I think it’s better to treat programming as being more like math, where you need sound inference rather than mere experimental observation to believe things work.
Example: if you drive a 10 ton truck over a bridge and the bridge doesn’t collapse, that’s encouraging. If you drive a million of those trucks over the bridge and the bridge still doesn’t collapse, that’s sufficient engineering certainty that you can declare the bridge safe to handle a 10 ton load. But software surviving a million test cases (which could happen in just 1 second of operation) is far less meaningful. Weird corner cases matter a lot more. Attackers actively seeking inputs to break the program will uncover and explit far more bugs than normal variations in test inputs will find (fuzzing helps). Changes in the build environment or library versions can break stuff that depended (without your realizing it) on undocumented behaviour of the surrounding system. This stuff happens all the time. People put way too much trust in software that passed some tests but wasn’t really thought through.
Tldr: you have to think things through at a level closer to that of mathematics than to that of traditional engineering.
I think that’s a helpful analogy and comment. Please remember this while I go on to nitpick. I’m aiming at in both fields, there may be more math-leaning scientists and concrete-leaning workers, with the engineer being somewhat in the middle.
Declaring bridges safe probably involves a lot of math and tables in the background. I guess we don’t actually run a million trucks but estimate the safety theoretically, with a few experimental tests. Likewise, a security specialist can define the edge cases against which the tests should be run. That may be the same person who also implements the test, but I want to emphasize it’s two different roles. And we might consider one more of a scientist, and the other more of a worker.
So how much your activity resembles that of a mathematician, or a traditional engineer probably depends on your specific task, and how much your team requires you to generalize or specialize.
