Execution: The Idea Is the Easy Part

This is the second of three posts on the pillars of research. The first was taste, and it argued that having a good idea is hard—rare, the tail of a distribution, the slow fruit of trained judgment. So the title of this post is going to sound like a contradiction: the idea is the easy part. It isn’t a contradiction. It’s a change of frame. Conceiving the idea is hard; but once taste has handed you an idea worth a year, making it true is usually where the whole thing lives or dies—and that is the part people wave away as “just engineering.” That dismissal is the mistake this post is about.

Because a great idea with bad execution isn’t a great idea with an asterisk. It’s nothing. An idea is only a multiplier; it’s worth nothing until something executes it. Multiply your brilliant idea by zero execution and you know what you get.

The clearest example of the multiplier is the most painful one in our field. Through the 1970s, Xerox PARC built the graphical interface, Ethernet, the laser printer, and the Alto that tied them together—a strikingly large fraction of the modern personal computer. (The mouse came from Engelbart’s lab at SRI; PARC made it usable.) Xerox cashed in on some of this—laser printing became a real business—but it fumbled the computer itself: the Alto never shipped as a product and the 1981 Star flopped. Apple and Microsoft executed on the interface and took the industry. The hard ideas had been sitting there, invented, for years. Or Friendster: it had the social network before Facebook and a multi-million-user head start, and a big part of why it lost was unglamorous engineering—its pages were notoriously slow, reportedly taking many seconds to load, and the scaling problem never got fixed. Same idea. Different execution. Different history. Execution is not the part that comes after the important work. Frequently it is the important work.

Three things that aren’t the same: coding, programming, hacking

The first thing I want a student to be able to do is notice which of these they’re doing, because the words get used interchangeably and they are not the same activity.

Coding is writing the code—the local act of turning a known solution into syntax. It’s the smallest of the three and the one people overweight, probably because it’s the most visible.

Programming is solving a problem from a clean slate—designing the solution, choosing the structure, deciding what the thing is before it’s anything. This is where most of the actual thinking lives.

Hacking—and I mean this as a compliment, in the old sense—is solving a problem inside a gazillion lines of code you didn’t write. Finding the three places in a kernel where you need to intervene. Bending an enormous existing system to do something it was never meant to do. This is, honestly, most of what real systems research demands, and it’s the skill schools teach least.

The reason to keep these separate in your head is that research almost never happens at the coding level. If you find yourself stuck, the question “am I stuck on coding, programming, or hacking?” usually dissolves it. Stuck on coding is a syntax or API problem—trivial, look it up. Stuck on programming means you haven’t actually decided what you’re building—go back to the design. Stuck on hacking means you don’t understand the system you’re inside of yet—go read it. Different diagnoses, different cures.

There’s a deeper version of this distinction that’s worth internalizing early: software engineering is really just programming integrated over time. A throwaway script and a system that ten people will maintain for ten years are not the same kind of object, even if they do the same thing today. Fred Brooks made this point decades ago and put a number on it: turning a quick program into a polished product other people can use is roughly 3× the work, and turning it into a component of a larger system is another 3×—so the full “programming systems product” costs about nine times the garage version. Most of the surprise and pain in a student’s first big project is discovering that 9×. Know it’s coming.

What you need to be able to do

Here’s the concrete checklist I’d hand someone. Over a PhD you should, at least once:

Master one programming language completely—not “can write it,” but know it in your bones, the way you know a spoken language you dream in.
Hack one large-scale system—really get inside something huge and unfamiliar and make it do your bidding.
Build one system from scratch, so that you lose the fear of systems. This is the one that changes people. Once you’ve built a database, a kernel, a compiler from nothing, no codebase intimidates you again, because you know there’s no magic in there—just decisions, some good, some you’d make differently.
Have one good visualization/tooling habit. When you can see what your system is doing, debugging stops being archaeology.

And in your own area specifically: you need to be able to prototype fast, and you need to truly understand the layers beneath you—the OS, the hardware, the network—well enough that they can’t fool you. The general principle: the hardware cannot work optimally without help from the programmer, and you cannot give that help if the layer below you is a black box. Most subtle systems bugs and most surprising performance results live exactly at the seam where your mental model of the layer below diverges from what it actually does. Go down a level. It’s almost always worth it.

On the “don’t fear systems” point, one practical note about reading code, since diving into huge codebases scares people. You don’t really read code, you decode it: a piece of code is not literature, it’s a specimen. You don’t read a million-line system front to back like a novel. You find a thread—one request, one syscall, one function—and you pull it, and you follow it down, and you ignore the other 999,000 lines until you need them. Reading code is an active, surgical act, not a passive one. Once you believe that, large systems stop being walls and start being mazes, which at least have a path through.

Deliberate practice, not ten thousand hours

People love the “10,000-hour rule.” It’s wrong, or at least badly mangled—there is nothing magical about ten thousand hours, and the researcher whose work the rule was built on spent years saying so. The hours aren’t the mechanism. What builds skill is deliberate practice: working at the edge of your ability, on something just past what you can comfortably do, with feedback that tells you specifically what was wrong. Ten thousand hours of comfortable repetition makes you exactly as good as you were at hour one. An hour of the uncomfortable kind, with real feedback, moves you.

For us, the uncomfortable kind looks like: writing the part you’re avoiding because you’re not sure you can; profiling the system you assume you understand and being wrong; submitting the paper and reading every brutal review instead of flinching away. The feedback is the whole point—which is, not coincidentally, another argument for the apprenticeship, because a good advisor is a feedback machine calibrated to your specific weaknesses.

Build a system for yourself

Here’s a strange blind spot: systems people almost never build a system for their own work. Look at what your research life actually is—a stream of inputs arriving faster than you can process them (papers, ideas, deadlines, threads, half-thoughts), hard latency requirements, and a tiny leaky cache called your memory. You would never run a service this way. Yet most students try to hold it all in their heads, drop things, and—worse—burn the attention they needed for thinking on the holding. The principle is one sentence: your mind is for having ideas, not holding them. Get the open loops out of your head and into something you trust, and treat your own workflow as a system to be engineered, not a fixed trait of your personality.

Two parts of that system aren’t optional. The first is note-taking that is actually thinking, not transcription. Your notes aren’t a record of the work; done right, they are the work—the place where the thinking actually happens. Note-taking done well is generating and judging on paper, the taste loop from the last post externalized and made durable.

The second is the discipline to actually run the system, which is harder than picking one. Here’s the line worth tattooing on every first-year: you do not rise to the level of your goals, you fall to the level of your systems. Everyone wants to do great research; the wanting is uniform and useless. What differs between people is the boring daily machinery—when they read, how they capture, whether the deadline gets respected. So if you adopt a system, give it a fair trial: run it strictly for at least two weeks before you judge it. Most people quit a good system in three days because it feels awkward, which is just the cost of any new skill and tells you nothing.

Ship: deadlines, estimation, and what to cut

Last, the part that separates research that exists from research that almost existed: finishing. Three things to know.

You are bad at estimating, and not randomly—predictably bad, in one direction. It’s called the planning fallacy: we systematically underestimate how long our own tasks will take, even when we have mountains of evidence that we always run long. The fix isn’t optimism or willpower; it’s taking the outside view—ask how long things like this have actually taken you before, and trust that number over the story in your head.

Given that everything takes longer than you think, you will not finish everything, which means knowing what to cut is an execution skill, not a failure of one. Herbert Simon’s word for the right behavior is satisficing: don’t optimize every component, get each one good enough and move on. The Pareto split is brutally real in systems work—something like 20% of the effort gets you 80% of the result. Find that 20% for each piece, ship it, and spend your remaining time only on the parts where excellence actually changes the contribution.

And iterate fast. Make it work, then make it right, then make it fast—in that order, never reversed. Design your whole setup around an immediate connection between what you change and what you see: the shorter the loop between changing something and seeing what changed, the more times you can run it, and execution—like idea generation—rewards more turns of the loop. Tight loop, many iterations, finished system.

Underneath all of it—the three kinds of building, the layers, the tooling, the deadlines—execution is one thing: building an accurate enough model of the machine that it does what you intend instead of what you assumed. The bugs live exactly where your model and the machine disagree. That’s the second system you learn to model. The third pushes back hardest of all, because it has a mind of its own: other people.

Next: Communication—getting the finished thing out of your head and into everyone else’s.