The Hard Parts

The best advice I ever got was from some random guy I worked with. He said

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.

It sounds incredibly cliché. I’ll be completely honest.

Back then, I took it literally. “The hard parts” meant code: the race condition nobody could reproduce, the module everyone was afraid to touch, the bug that only showed up on the third Thursday of a full moon. So I volunteered for the haunted parts of every codebase I worked in. It worked, too. You do that for a few years, and you become “the person who can do things.” People start bringing you the impossible stuff, and the impossible stuff is where all the learning is.

Then I became a team lead, and something weird happened. The code got easier. Not because I suddenly got that much better, but because it stopped being the thing I was challenging myself with. The hard part became sitting across from a developer I genuinely liked and telling them they weren’t good enough. The hard part became the conversation, not the diff. Nobody warns you about that promotion… you go home exhausted … and you haven’t written a line all day.

Then I became an engineering manager, managing team leads, and the hard parts moved again. Now it was paperwork. One-on-ones and making sure my leads were actually communicating. Watching a lead quietly grade their people on “lines shipped” and having to slowly, carefully bend their definition of performance into something that wouldn’t burn a team down in eighteen months. Managing people is one thing. Managing how other people see their people is a different sport entirely.

Do you see the pattern? I didn’t. Not for years. Every time I levelled up, the code got easier, something else got harder, and every single time I told myself the new thing was a distraction from the real work.

The hard parts were never the code. The hard parts are whatever’s left over once you get comfortable.

Starting a company made that impossible to ignore. I built a distributed, leaderless cache from scratch that guarantees exactly-once, formally verified in TLA+, beaten half to death by Jepsen until it stopped having bugs to find. That sounds like the hard part. Damn, it should be the hard part. It’s the kind of thing that takes years of accumulated experience to even attempt.

It was the easy part.

Not easy like trivial. Easy like comfortable. I would do that work for free. (Technically, I did — for months.) When I’m deep in a consistency proof or chasing a heisenbug through causally induced shenanigans, I know exactly who I am. There’s a problem, there’s me, and one of us is going to win. I always win.

The hard parts, it turns out, are everything else:

Asking someone you love for money. Not pitching a VC. I mean sitting across from a person who trusts you and saying, “I believe in this enough that I’m asking you to risk something for it.”

Publishing. Not the mechanics because anyone can hit a button. This thing lived in my head for years, and inside my head it was perfect. Putting it out there means handing it to strangers to judge … and they will judge it. Some of them in one sentence, from a throwaway account, vanished before you finish reading. Overcoming that fear is surprisingly hard, mostly because it doesn’t feel like fear. It feels like “one more week of polish.”

And last but surely not least: turning it off. I poured my nights and weekends into this for years. Hours after work, half a Saturday here and there…

Now it’s my full-time job, and my body hasn’t caught up.

Putting the laptop down in the evening to do something else (literally anything else) is genuinely hard.

Swytch used to be my escape. But once you’re in paradise, where do you go for vacation?

Don’t get me wrong, some code really is hard. Distributed systems will humble anyone, and I don’t believe the technical hard parts ever fully go away. But for most of us, past a certain point, the code stops being the challenge and starts being the comfort zone. And “hard” — the kind that guy meant, whether he knew it or not — is just a fancy word for the thing we’re avoiding.

So why did the advice stick for twenty years? Why does it still feel true when the definition of “hard” has moved underneath it?

Because the advice was never about code either. “Anyone can do the easy parts” — sure. But the real insight is hiding in the middle sentence, the one I skipped past for two decades: only we can do them. When I was an engineer, “we” was a fuzzy thing. A department plus a codebase plus a few hundred people, any one of whom might pick up the hard part if you left it long enough.

Now “we” fits at one table. Every hard part has a name on it, and the name is one of ours. Nobody is coming to ask our friends for money for us. Nobody is coming to hit publish for us. Nobody is coming to do the parts that make our hands sweat.

And here’s the part that took me by surprise: it’s the fun part. When the “we” is small enough that every hard part lands on someone you chose to work with, the hard parts stop being the things you avoid. They become the things you get to do. Scary and electric at the same time, like the first time you push a boat away from the dock and realise the boat is yours; and you only need the wind to cooperate.

We’re building something real, with a real team, and all the hard parts are ours.

Come see what we’re building .