Assumed audience: People thinking about career decisions, especially (though not necessarily only) in software development. And writers thinking about how to give advice.
Should you study non-“standard” programming languages (Clojure, Elm, etc.) as a way of growing your way of thinking about things? I can think of multiple blog posts arguing either direction. Should you seek out hard problems to solve? Yes, but also no, depending on who you ask. Should you go for a big company, or a small startup, if you want to really grow in your career? Both! Or maybe neither! Where will your financial outcomes be largest? Big Tech, probably; but if you happen to catch the right rocket ship maybe not.
All of these have a common theme running through them: most of the advice you’ll find on the internet about what you should do in your career as a software engineer1 is actually a statement of what the person writing the post experienced in his or her own career. This trend goes back a long time, but here I’m going to pick on a piece from a writer I really like, precisely because I really like and respect his work from what I see of it: Ben Kuhn’s You don’t need to work on hard problems.
First: go read the post, and think on it. There are some really important points in there, and I actually agree with the major point he makes in the little essay. Really: go read it!
Okay, now that you’re back and you’ve presumably thought about it at least a little, I want to draw your attention to something Ben made explicit in that post, and which most other writing of this sort doesn’t: he’s talking, quite directly, about his own experience. The first chunk of the piece is literally a timeline of the latter bits of Ben’s time in college and the early bits of his career!2 This is actually basically always true of these kinds of posts when you poke at them.
So far as it goes, this is totally fine! We all only have the experiences we have, and sharing those can be genuinely valuable. Ben’s post, for example, challenges a widely-shared belief in engineering circles that what makes for a satisfying career is “hard problems,” and his challenge to that belief is born out of his own real experience. What’s more, he was able to look beyond his own direct experience to the reason for his own direct experience and articulate how that belief can be so compelling to people like him.
The not-so-great bit is that, like any good piece of short and snappy writing, the post overly-generalizes. It successfully pushes back against that norm to at least get people to consider that there are other ways to satisfy the desire represented by “solving hard problems” in their mental landscape. It is successful in part because Ben doesn’t qualify his assertions in the piece: it’s not “Maybe you don’t need to work on hard problems.” But it’s also an overgeneralization, a universalization of his own experience.
In fact, the only thing we should reasonably conclude from Ben’s experiences is that for some people — the kind like Ben who end up in CTO/managerial roles — the product itself is more engaging than the problem details. That is not true of everyone, though. Product work bores me and sometimes enrages me. Not as in I get a little bored after a long while; as in I will quit my job and go find another one immediately if you assign me to a product team.
Now, Ben might say it is because I have not found the right product, but I don’t think so. I have spent a lot of time introspecting about what motivates me over the past half decade, and it turns out that the answer is neither “hard technical problems” as people normally conceive it nor “any old problem at all as long as it is moving things a direction I value on a project that is meaningful” but a specific combination of technical depth with impact on developer outcomes. To put it in terms of Ben’s essay: doing analysis in a spreadsheet is something I will do under duress and with gritted teeth for a project I really care about, but if I had to do it consistently I would quit and find another job.
From this, I could conclude that what you, the developer out there reading this, need isn’t “hard problems” or “the right product” but something which happens to be merging the two in just the right way. I do not conclude that, though. I conclude, instead, that this is one possible path for engineers to be satisfied in, and that it’s probably worth publicizing and teaching and modeling for other engineers. It’s increasingly important to me to show people that there is business value in the kind of work I do, even if that value is delivered in ways that are hard to connect directly to dollars, and tends to play out on the scale of years (or more!) rather than months. But I also don’t think for a second that the things which motivate me are the things which do or should motivate everyone. I just want to carve out room for this kind of work alongside all the others. I don’t want to generate universal advice from my own experience or my own interests — and as the title of this post suggests, I don’t think you (or Ben, or anyone else) ought to do so either.
As I admitted above: Ben’s post is snappy writing, and adding too many qualifications and nuance can undermine the effect of a piece like that. “You don’t need to work on hard problems” is way likely to catch someone’s attention and make them reconsider their priorities than “You might not need to work on hard computer science problems to find your job satisfying, and in fact depending on your temperament other parts of work in software may even satisfy you more than that.” (I suspect, from what I’ve read of his work more generally, that Ben groks these dynamics; again, I felt free to pick on this post because Ben is a good writer and thinker.)
The challenge here is the challenge for any writer: on the one hand, we want our words to be read and to have the effect we’re aiming for in our readers. That often means dropping nuance in favor of making the point clear and strong while maintaining brevity (rather unlike this sentence!). On the other hand, we want our words — or at least, I want my words — to stand up to the test of time, as people reflect on the things we’ve written years along the way. That requires facing up to all the gnarly details and complications of the thing we are addressing. My favorite writers are the ones who somehow manage to capture an appropriate degree of nuance without losing their audience — who can pull your attention along for enough words to say something complicated.
So: maybe you shouldn’t universalize from your own experiences.
Notes
I would assume that the same kinds of things show up, mutatis mutandis, in other fields — but I haven’t looked. ↩︎
There’s a completely separate, but also very important, point about how much weight we ought to put, and how much weight we do put, on the advice of people depending on the state of their careers. Ben is, from all I can tell, very sharp and I think the work he and the rest of the folks at Wave are doing is incredibly important. But also: Ben wrote the post we’re talking about here a little over half a decade out of college, and was, as far as I can tell, in his late 20’s at the time.
Now, to be clear, plenty of people can be very insightful and even wise in their late 20’s, and there are an incredible number of people with decades of experience who don’t seem to have learned from any of it. Even so: it’s a bit odd to think that someone with less than a decade of experience is in a spot to see clearly about the ramifications of their choices, including on their own happiness, in the long term. (To be clear, that applies more or less equally to someone like me, compared to someone who has been doing this for thirty years! So take the takeaways from this post of mine from a couple years ago with a correspondingly large grain of salt!) The perspective is valuable. But we should take the details of that perspective into account when weighting it, and when feeding it back into our own decision-making process.
Again, none of this is a knock on Ben. I have benefited a great deal from his writing! It’s simply a plea to think about how and when those kinds of posts apply to our own lives — as, for example, his post on his weekly review habit, which I like the idea of and which has been a non-starter for me for a decade: because I am a dad with kids running around! Quiet weekend morning weekly reviews for
3 – 4 hours are a genuinely great idea, and they are not workable at all for someone who has kids to take care of and play with. ↩︎