Things I Believe About Software Engineering

Not OP/GP, but I think it's mostly about the definition of correct.

Does it correctly handle every possible sequence of inputs? For the vast majority of software in use today, the answer is "no"; The follow up question is "does it matter?" and (luckily or unluckily) the answer for the vast majority of software in the vast majority of use cases, is "no" as well.

But occasionally it does, e.g. https://en.wikipedia.org/wiki/Therac-25 is a famous poster child, and I quote:

>>> The failure occurred only when a particular nonstandard sequence of keystrokes was entered on the VT-100 terminal which controlled the PDP-11 computer: an "X" to (erroneously) select 25 MeV photon mode followed by "cursor up", "E" to (correctly) select 25 MeV Electron mode, then "Enter", all within eight seconds

Software was not obviously correct or incorrect; In fact, it had been acceptable for an earlier model (which had some hardware protections missing from the newer one). Reaching the incorrect state required the race described above to trigger, which did, in fact, happen in practice a handful of times.

You can work very hard to formally prove your implementation, only to find out that the compiler had a bug and makes your software bad. Or the CPU does; Or all the designs are fine, but there's an bit flip due to electro-migration or cosmic rays. Many people consider this "force majeur" - "an act of god" one cannot anticipate, but cosmic rays are in fact an expected -- and hard to avoid -- input to many systems.

You are in control of a logical model which you can, with extra work, do (provably) correctly. But that IS, from experiencce, 10x to 100x more expensive, and unless you go for 10x-100x more expensive hardware, reduces and moves the sloppiness factor around, but does not eliminate it.

I kind of see where they're coming from with this one, although I don't think it's true. The definitions of trivial and correct can be moved to fit whatever they're trying to say.

Rephrasing it as something like it's incredibly difficult to write a large piece of software with no bugs makes more sense. And I think for most organisations it may as well be impossible.

How far down the stack does it need to be correct? Can a 100% correct Python script be considered correct if there could still be bugs further down the stack? Also what's the context of the software? Much software has pretty safe failure modes, but if it's a medical system for example, knowing level of correctness right down to hardware level may be useful.

I think in that light, most modern software can be built to be robust and easily maintainable rather than correct. Like the difference between building a bridge, where you understand everything in the system, versus building a vehicle engine, where you have multiple dependencies but you still need it to not catastrophically fail should any of them stop being correct (eg: fuel pump fails, engine management detects lower fuel pressure and cuts ignition, saving the engine).

I clicked this expecting an overly opinionated list on how to do things the right way, but came away agreeing with nearly everything said.

> Writing non-trivial software that is correct (for any meaningful definition of correct) is beyond the current capabilities of the human species.

This is the one point I somewhat disagree with, and it leads to one of the things I believe about SE - it's all about perceived risk. Mission-critical systems work well because the risk is well-defined, and it's usually "people will die". In business, managers are happy to break rules when the perceived risk of it biting them in the ass is low. Small budget? Skip the tests, click around on deploy to see if it works, and ship it. Not enough time? Deliver a minimal product and build the rest later when we have the budget.

There are two examples I often use for this - Panera Bread and Pipdig. The former leaked millions of customer records, ignored the press for a few days, and got off with zero consequences. Pipdig did even worse, they did backdoors and DDoS code to attack competitors in their WP themes/plugins, and when called out they lied, hid the evidence, and then went back to selling themes to unsuspecting bloggers with zero consequences.

Both sides likely knew what they were doing was wrong, but the risk of getting caught was minimal, so why not break the rules? It probably saved them a ton of money in the long run.

> Being aligned with teammates on what you're building is more important than building the right thing.

I've no idea why so many of you are up in arms about this. It isn't about bowing to managers, or being a punching bag for others. It's about making concessions as a group to define what you need to build, and the best way of doing it.

> Peak productivity for most software engineers happens closer to 2 hours a day of work than 8 hours.

I'd stretch this to say that "on average". Some days I'll get 30 minutes of stuff done, some days I'll fly through work for a solid 8 hours.

> Thinking about things is a massively valuable and underutilized skill. Most people are trained to not apply this skill.

This is so true it hurts. I'm currently working on a project in an agile structure, and it's going like many agile projects I've worked on in the past. Agile is used as a buzzword for "fuck planning, just write user stories and be done with it", all while team mates bitch and moan about spending too long in "planning" meetings. The second we took the time to actually have these meetings and plan out our backlog, we made key decisions and discoveries about how things work, what edge cases we need to think about, what doesn't work from a user perspective, etc.

> How kind your teammates are has a larger impact on your effectiveness than the programming language you use.

Over the years, I've always believed that empathy is the best skill you can have in software, and that is often paired together with kindness. An empathetic team is often a kind team, and when empathy is a core part of a team it highlights areas where certain stakeholders don't share that trait.