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.
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?"
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?"
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!
Thanks for reading Register Spill! Subscribe if you want to get these emails every week.
The first type is very common.
They are the reason everything is complex and fragile.
"Easy, let the use edit this config file"
"Just create a docker-compose file with this content"
"Just put the package directory here and the templates directory there"
Death by a thousand cuts. Every cut is just a tiny "just do that" kinda statement.
The result is that to get anything working you have to remember a 100 tiny annoying details with no feedback mechanism to tell you whether you got everything right or forgot something critical.
This is why most programming jobs suck the soul right out of you.
I like the quote, “If you want someone to do something, make it easy for them to do it.”
That seems obvious, but it could press the first type of engineer to think about “them”. That is, who is going to do the thing, and what do they know? Maybe they’re not a programmer who understands the internal model of the system. Maybe they’re someone in a hurry, who is actually trying to do some other job, but needs to use the system to do one part of the job.
Everybody should assume their customer isn’t going to read the manual. All the customers are used to the magic of google where you type something in and get a whole bunch of help in the blink of an eye.