I'm addicted to being useful
When I get together with my friends in the industry, I feel a little guilty about how much I love my job. This is a tough time to be a software engineer. The job was less stressful in the late 2010s than it is now, and I sympathize with anyone who is upset about the change. There are a lot of objective reasons to feel bad about work. But despite all that, I’m still having a blast. I enjoy pulling together projects, figuring out difficult bugs, and writing code in general. I like spending time with computers. But what I really love is being useful.
The main character in Gogol’s short story The Overcoat is a man called Akaky Akaievich1. Akaky’s job is objectively terrible: he’s stuck in a dead-end copyist role, being paid very little, with colleagues who don’t respect him. Still, he loves his work, to the point that if he has no work to take home with him, he does some recreational copying just for his own sake. Akaky is a dysfunctional person. But his dysfunction makes him a perfect fit for his job2.
It’s hard for me to see a problem and not solve it. This is especially true if I’m the only person (or one of a very few people) who could solve it, or if somebody is asking for my help. I feel an almost physical discomfort about it, and a corresponding relief and satisfaction when I do go and solve the problem. The work of a software engineer - or at least my work as a staff software engineer - is perfectly tailored to this tendency. Every day people rely on me to solve a series of technical problems3.
In other words, like Akaky Akaievich, I don’t mind the ways in which my job is dysfunctional, because it matches the ways in which I myself am dysfunctional: specifically, my addiction to being useful. (Of course, it helps that my working conditions are overall much better than Akaky’s). I’m kind of like a working dog, in a way. Working dogs get rewarded with treats4, but they don’t do it for the treats. They do it for the work itself, which is inherently satisfying.
This isn’t true of all software engineers. But it’s certainly true of many I’ve met: if not an addiction to being useful, then they’re driven by an addiction to solving puzzles, or to the complete control over your work product that you only really get in software or mathematics. If they weren’t working as a software engineer, they would be getting really into Factorio, or crosswords, or tyrannically moderating some internet community.
A lot of the advice I give about working a software engineering job is really about how I’ve shaped my need to be useful in a way that delivers material rewards, and how I try to avoid the pitfalls of such a need. For instance, Protecting your time from predators in large tech companies is about how some people in tech companies will identify people like me and wring us out in ways that only benefit them. Crushing JIRA tickets is a party trick, not a path to impact is about how I need to be useful to my management chain, not to the ticket queue. Trying to impress people you don’t respect is about how I cope with the fact that I’m compelled to be useful to some people who I may not respect or even like.
There’s a lot of discussion on the internet about what ought to motivate software engineers: money and power, producing real value, ushering in the AI machine god, and so on. But what actually does motivate software engineers is often more of an internal compulsion. If you’re in that category - as I suspect most of us are - then it’s worth figuring out how you can harness that compulsion most effectively.
-
I think in Russian this is supposed to be an obviously silly name, like “Poop Poopson”.
↩ -
Unfortunately, his low status and low pay catches up with Akaky in the end. His financial difficulty acquiring a new coat for the cold Russian winter (and his lack of backbone) end up doing him in, at which point the story becomes a ghost story.
↩ -
I interpret “technical problem” quite broadly here: answering questions, explaining things, and bug-fixing all count.
↩ -
Or toys, or playtime, or whatever.
↩
If you liked this post, consider subscribing to email updates about my new posts, or sharing it on Hacker News. Here's a preview of a related post that shares tags with this one.
Nobody knows how large software products work
Large, rapidly-moving tech companies are constantly operating in the “fog of war” about their own systems. Simple questions like “can users of type Y access feature X?”, “what happens when you perform action Z in this situation?”, or even “how many different plans do we offer” often can only be answered by a handful of people in the organization. Sometimes there are zero people at the organization who can answer them, and somebody has to be tasked with digging in like a researcher to figure it out.
Continue reading...