Can't watch atm. What's the gist of it?
this post was submitted on 02 Oct 2023
28 points (81.8% liked)
Programming
17312 readers
262 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 1 year ago
MODERATORS
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.
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.