The Hard Parts – Somewhere Within BoredomSkip to content
The best advice I ever got was from some random guy I worked with. He said<br>Always do the hard parts. Only we can do them. Anyone can do the easy parts.
This has stuck with me since 2006 … literally 20 years. And you know what? It’s true.<br>It sounds incredibly cliché. I’ll be completely honest.<br>Back then, I took it literally. “The hard parts” meant code: the race condition nobody could reproduce, the module<br>everyone was afraid to touch, the bug that only showed up on the third Thursday of a full moon. So I volunteered for the<br>haunted parts of every codebase I worked in. It worked, too. You do that for a few years, and you become “the person who<br>can do things.” People start bringing you the impossible stuff, and the impossible stuff is where all the learning is.<br>Then I became a team lead, and something weird happened. The code got easier. Not because I suddenly got that much<br>better, but because it stopped being the thing I was challenging myself with. The hard part became sitting across from a<br>developer I genuinely liked and telling them they weren’t good enough. The hard part became the conversation, not the<br>diff. Nobody warns you about that promotion… you go home exhausted … and you haven’t written a line all day.<br>Then I became an engineering manager, managing team leads, and the hard parts moved again. Now it was paperwork.<br>One-on-ones and making sure my leads were actually communicating. Watching a lead quietly grade their people on<br>“lines shipped” and having to slowly, carefully bend their definition of performance into something that wouldn’t burn a<br>team down in eighteen months. Managing people is one thing. Managing how other people see their people is a different<br>sport entirely.<br>Do you see the pattern? I didn’t. Not for years. Every time I levelled up, the code got easier, something else got<br>harder, and every single time I told myself the new thing was a distraction from the real work.<br>The hard parts were never the code. The hard parts are whatever’s left over once you get comfortable.<br>Starting a company made that impossible to ignore. I built a distributed, leaderless cache from scratch that guarantees<br>exactly-once, formally verified in TLA+, beaten half to death by Jepsen until it stopped having bugs to find. That<br>sounds like the hard part. Damn, it should be the hard part. It’s the kind of thing that takes years of accumulated<br>experience to even attempt.<br>It was the easy part.<br>Not easy like trivial. Easy like comfortable. I would do that work for free. (Technically, I did — for months.) When<br>I’m deep in a consistency proof or chasing a heisenbug through causally induced shenanigans, I know exactly who I am.<br>There’s a problem, there’s me, and one of us is going to win. I always win.<br>The hard parts, it turns out, are everything else:<br>Asking someone you love for money. Not pitching a VC. I mean sitting across<br>from a person who trusts you and saying, “I believe in this enough that I’m asking you to risk something for it.”<br>Publishing. Not the mechanics because anyone can hit a button. This thing lived in my head for years, and<br>inside my head it was perfect. Putting it out there means handing it to strangers to judge … and they will judge it.<br>Some of them in one sentence, from a throwaway account, vanished before you finish reading. Overcoming that fear is<br>surprisingly hard, mostly because it doesn’t feel like fear. It feels like “one more week of polish.”<br>And last but surely not least: turning it off. I poured my nights and weekends into this for years. Hours after<br>work, half a Saturday here and there…<br>Now it’s my full-time job, and my body hasn’t caught up.<br>Putting the laptop down in the evening to do something else (literally anything else) is genuinely hard.<br>Swytch used to be my escape. But once you’re in paradise, where do you go for vacation?<br>Don’t get me wrong, some code really is hard. Distributed systems will humble anyone, and I don’t believe the technical<br>hard parts ever fully go away. But for most of us, past a certain point, the code stops being the challenge and starts<br>being the comfort zone. And “hard” — the kind that guy meant, whether he knew it or not — is just a fancy word for the<br>thing we’re avoiding.<br>So why did the advice stick for twenty years? Why does it still feel true when the definition of “hard” has moved<br>underneath it?<br>Because the advice was never about code either. “Anyone can do the easy parts” — sure. But the real insight is hiding in<br>the middle sentence, the one I skipped past for two decades: only we can do them. When I was an engineer, “we” was a<br>fuzzy thing. A department plus a codebase plus a few hundred people, any one of whom might pick up the hard part if you<br>left it...