Two types of software engineers

One assumes it's easy because it's a non-technical problem, the other assumes that's why it's hard

Here's something I've been kicking around in my head for a few weeks, a tiny theory I have of how people think about software engineering.

According to my theory, there are two types of software engineers:

Type 1, when presented with a problem, thinks: "easy, people can just do X."

Type 2, when presented with the same problem, thinks: "very hard, because it requires people to do X."

Type 1 assumes something's easy if it's not a technical problem, because "we can just ask people to do X." Type 2 thinks it's hard because it is not technical.

Example:

Type 1: "easy, we can just ask people not to deploy at this time"

Type 2: "wait, but what do we do _when_ people deploy at this time?"

Another example:

Type 1: "easy, we just document this new process and ask people to follow it"

Type 2: "how do we ensure people even read this?"

Another one:

Type 1: "easy, we just build a system that these 4 parties will use and that ensures that no one cheats on the other one"

Type 2: "this is really hard because we need to get 4 parties to use the same system"

I'm not entirely sure yet on where exactly to draw the line between type 1 and 2 or how to define them precisely. I told you: tiny theory.

Painting in really broad strokes, though, I'd say that type 1 doesn't take people into account and type 2 knows that at the heart of all of their engineering work (and problems) are people.

Type 1 believes in capital E Engineering, where there are cold, hard truths; there's math & physics; it's applied science. It's what you see in The Martian.

Type 2 would probably ask: "yeah, but what if the guy in The Martian didn't have to build this stuff for himself but for others?"

Now, as you might have noticed, I'm not-so-subtly hinting at the fact that the type 2 engineer knows a bit more but maybe you also wonder whether you can’t smell a hint of cynicism in there and think that it's me admitting defeat — we can't build nice things because it all becomes a mess as soon as people are involved.

Here's the kicker though: it's the opposite! It's not cynicism, type 2 engineering is embracing the fact that we build with and for people and taking on an even bigger challenge of doing work despite the chaos this produces.

Because, see, when it gets messy, that's where it gets real; that’s where the actual work begins, when you go from drawing board to actually shipping something of value and with impact to someone.

It's embracing the fact that people are not machines and no matter how often they say they're rational thinkers, you still know that even the strongest choose-the-best-tool-for-the-job advocates will sometimes choose a tool because, well, the GIF in the README was cooler. It's knowing that no one will read your documentation if you don't make it entertaining and easy to read. It's leveraging the fact that people will install security updates to get new emojis. It's anticipating that, no, not everybody will follow the best practice because everybody has a Thursday afternoon that feels like it should be Friday evening.

Let me add one more on top: I'd argue that it's precisely because of how messy it can get do the things we build become beautiful.

Until next week!