Open any app on your phone. Before a single pixel reaches the screen, a dozen protocols have already done their job — quietly, perfectly, and without anyone thanking them. The people who designed those rules are some of the most consequential engineers alive. Most of them you will never hear about.
We celebrate the visible layer of software: the slick interface, the clever feature, the viral app. But every one of those things rides on a foundation of agreements about how machines talk to each other. TCP decides how a stream of bytes survives a noisy network. TLS decides how two strangers establish trust without ever having met. HTTP decides how a request becomes a response. These are not laws of nature — they are decisions, made by people, that the entire digital world now depends on.
The work nobody sees
A protocol is invisible when it works. That is precisely the problem for the people who build them. A great UI gets a screenshot on social media; a great congestion-control algorithm gets silence. The reward for a perfectly designed protocol is that nobody ever notices it exists.
And yet the leverage is staggering. A single line in a specification can shape the behaviour of billions of devices for decades. The protocols below were designed once and have been running, almost unchanged at their core, for a generation:
Why it's the hardest kind of engineering
Most software has a luxury that protocol design does not: you can ship, watch it break, and patch it next week. A protocol cannot work that way. Once it is deployed across millions of independent implementations — written by different teams, in different languages, on hardware you will never see — you can no longer change it. You have to get it right before the world adopts it, because after that, backward compatibility becomes a permanent constraint.
That forces a rare way of thinking. You have to reason about failure modes that haven't happened yet, adversaries who haven't shown up yet, and scale you can't test for. You are not designing for the happy path — you are designing for the network at 3 a.m. when half the packets are lost and someone is actively trying to break you.
A protocol is a promise you make to strangers you'll never meet, written in a language that can never be ambiguous, that has to hold for thirty years.
What it actually demands
The deeper I look, the clearer it becomes that this discipline asks for a specific blend of skills — and it's the blend that drew me in:
- Precision in language. Specifications live or die on whether two engineers read the same sentence the same way. Ambiguity is a bug that ships.
- Adversarial imagination. Every assumption is a door, and security comes from asking who walks through it when you're not looking.
- Respect for constraints. Latency, packet loss, byte budgets, and ten-year-old clients that will never update. Elegance here means working within limits, not ignoring them.
- Patience. The feedback loop is measured in years, not sprints. You optimise for the long game or you don't belong here.
Why I'm choosing this path
I came to this from the bottom up. Writing OpenGL by hand taught me to respect the machine. Building full-stack apps taught me how fragile the layers above really are. Somewhere in between, I realised that the part of the stack I kept being drawn to was the part everyone else treated as a black box — the wire, the handshake, the agreement.
There's something honest about work whose only reward is that it never fails loudly. It can't be faked, it can't be rushed, and it doesn't care about hype. For an engineer who wants their work to outlast them, I'm not sure there's a better place to stand than at the foundation everyone else builds on.
The silent architects don't get the credit. But they get something better: their decisions are still running, right now, in the device in your hand. That's the kind of impact I want to spend my career chasing.