As I wrote elsewhere in this thread I actually wrote software to estimate the amount of fuel a jet should load to comply with the rules. This was commissioned by the airline and they were scared shitless that they would ever be found to be in breach of the regulations on this aspect. It is one of those red lines that you really do not wish to cross. There are other aspects of flight where you are right but this particular one is different.
The main reason why airlines would like to take the least amount of fuel is because it immediately increases payload capacity and thus flight efficiency. This being a cut-throat market there is a serious incentive to cut it as fine as possible. So the regulations around this particular issue are incredibly strict: you have to have a certain amount of fuel left upon landing, you have to write up truthfully how much you still had left and you will be investigated without fail if you cut into the reserve. The good thing about unions here is that they help to make sure that pilots know they are safe reporting truthfully because the airlines can not retaliate if they would pressure the pilot to not report an incident (which all pilots would normally definitely do). So they're a factor, but it is the regulator that writes the rules here and they are super strict about this.
And that's immediately why the calculation of the estimate becomes so important: you now have 30 minutes (or 45, depending) of deadweight + the deadweight for two alternates and an x amount of time in a holding pattern, plus up to three go-arounds. That really adds up, so you have to do your best to get the calculation as close as possible to what it will be in practice without ever cutting into that reserve.
It took me the better part of a year and massive amount of learning to write a small amount of code + associated tests to pass certification. It also taught me more about software engineering (as opposed to development) than anything I did up to that point in time and it made me very wary about our normal software development practices.
As an aviation fan just reading this thread is quite eye-opening in terms of how much risk tolerance the average commenter has vs what is standard in the aviation community and on aviation forums. It's almost like peeking into two different worlds. I wonder if there would be any value in teaching an "engineering when lives are on the line" or "war stories from accident investigations" classes to new engineers. I feel like there's value in appreciating just how much more work goes into building a system where people's lives are at stake.
Yeah it bothers me to no end with the "engineering"-inflation of various jobs.
Like, I'm definitively not an engineer, nor does my day job really involve engineering, yet my title contains Engineer! I'm a proud CRUD monkey and designer.
I have done engineering work previously when developing hardware, and it's really a different mindset (even in an agile & fast-moving engineering org). Safety, cost, reliability, multidisciplinary integration, etc. just don't really come up in a lot in web and app development (which is a wonderful thing, really—I love it!)
It is an endless source of frustration to see poorly engineered software solutions powering critical systems.
> I wonder if there would be any value in teaching an "engineering when lives are on the line" or "war stories from accident investigations" classes to new engineers.
There would be immense value in that. But who is going to pay for it? It's a course that will essentially cause your crew to start producing software at 1/10th the rate they would otherwise do.
The average commenter here is a software guy. I imagine for the average software guy a Master Caution would be like a minor compile-time warning, i.e. feel free to just disregard it. :)
That would be funny if it wasn't uncomfortably close to the truth.