I doubled my output as an engineer last year. Not by working more hours — I actually worked slightly fewer. Not by learning a hot new framework. Not by buying a faster laptop.
It came down to one boring, unglamorous habit that I resisted for years because it felt like it would slow me down. It did the opposite.
I'll tell you what it is in a second, but I want to be honest about why it took me so long to adopt: it looks like procrastination dressed up as work. It isn't. It's the highest-leverage thing I do all day.
The habit that doubled my output: I think on paper before I touch the keyboard. Before writing any non-trivial code, I spend 10 to 20 minutes writing out, in plain language, what I'm building, the edge cases, and the approach. That small upfront cost eliminates the expensive thrashing — the false starts, the half-built wrong solutions, the rewrites — that used to eat most of my day invisibly. Slow is smooth, and smooth is fast.
For most of my career, my process was: read the ticket, feel a vague sense of the solution, and start typing.
It felt productive. Hands on keyboard, code appearing, momentum. But here's what was actually happening underneath: I'd write for an hour, hit a case I hadn't considered, realize my approach didn't handle it, and partially rewrite. Then again. Then a third time.
The visible part — typing code — looked like progress. The invisible part — discovering the real problem while coding and paying to redo work — was where my time went. Martin Fowler has written for years about how the expensive part of software is rework born of poorly understood design, and that's exactly the bill I was quietly paying every day.
I was confusing motion with progress. Classic.
It's not elaborate. I open a plain text file or grab a notebook, and before any real code I write out:
Ten to twenty minutes. That's it. Then I code, and the code goes fast, because all the thinking already happened and I'm just transcribing a plan instead of discovering one mid-flight.
The cheapest place to fix a mistake is in a sentence, before it ever becomes a line of code.
The math is unintuitive until you've felt it.
Twenty minutes of planning feels like twenty minutes lost. But it prevents the two or three hours of thrashing that thinking-while-coding causes. You're trading a small, visible cost for a large, invisible saving.
Here's the rough before-and-after of a typical non-trivial task for me:
| Phase | Old way | New way |
|---|---|---|
| Planning | 0 min | 15 min |
| First coding pass | 90 min | 60 min |
| Rewrites from missed cases | 120 min | 15 min |
| Debugging surprises | 60 min | 20 min |
| Total | ~4.5 hrs | ~1.8 hrs |
The rewrites row is where it all hides. The old me thought I was bad at debugging. I wasn't. I was bad at thinking before building, and paying for it during.
Two side effects I didn't see coming.
First, code review got easier. When I've thought the problem through, my code is more coherent — one clear approach instead of three half-merged ones. Reviewers spend less time confused. My software engineering quality went up alongside the speed.
Second, AI tools got more useful. When I hand an AI assistant a clear plan instead of a vague "build me X," its output is dramatically better. My thinking-on-paper notes basically are a great prompt. The habit made me better at directing automation, not just at coding myself — which is the same lesson I took from the two weeks I coded with only AI: the clearer the plan in my head, the better the machine performed.
The hard part isn't understanding this. It's doing it when every instinct screams "just start coding." Here's what made it stick for me:
Give it a week of honest effort. The first day feels slow. By day three you'll feel the thrashing disappear, and you won't want to go back.
Here's what bugs me about how rare this habit is. It's not a secret. Every senior engineer half-knows it. Yet it's almost never taught, and most of us learn it late if at all. Why?
Partly because it's invisible. You can't see someone thinking on paper the way you can see them typing fast. Our whole industry visually rewards output — lines committed, pull requests opened, the appearance of motion. A person staring at a notebook for fifteen minutes looks like they're doing nothing, even though it's the most productive quarter-hour of their day.
Partly because it feels counterintuitive. "Slow down to go faster" is true but unbelievable until you've felt it. Every instinct under deadline pressure screams to start coding now. The discipline is resisting that scream, and discipline is hard to put in a tutorial.
We reward the look of busyness over the fact of progress, and thinking on paper has no look. That's the only reason it stays rare.
The habit scales, which surprised me. For a single ticket, fifteen minutes on paper is plenty. For something larger — a new service, a tricky migration, a feature touching many systems — I extend the same instinct.
I write a slightly longer plan: the goal, the pieces, how they connect, the riskiest assumption, and what I'd do if that assumption is wrong. Still plain language, still ugly, just longer. An hour of this on a two-week project routinely saves me days, because the expensive mistakes on big work are architectural — the kind you can only cheaply fix while it's still a paragraph.
Same principle at every scale: the cheapest place to be wrong is in a sentence. The most expensive place is in production. Thinking on paper just moves more of your wrongness to the cheap end.
There's a side effect I didn't expect and now value almost as much as the speed: this habit made the job less stressful.
The old way — start coding, discover problems mid-build, scramble to rework — kept me in a low-grade state of anxiety. I never quite knew if my approach would survive contact with the next edge case. Every ticket carried a faint dread that I'd be three hours in before realizing I'd built the wrong thing. That uncertainty is exhausting in a way that's hard to name until it's gone.
Thinking on paper front-loads the hard part. By the time I start coding, the scary unknowns have already been faced, on paper, where facing them costs nothing. The actual building becomes almost relaxing — I'm executing a plan I trust, not improvising over a cliff. The work got faster and it stopped grinding me down.
A plan isn't just faster. It's calmer. You can't feel flow while quietly bracing for the next nasty surprise.
I think this is why senior engineers often seem unhurried even under pressure. It's not that they're naturally serene. It's that they've front-loaded the thinking, so by the time their hands hit the keyboard, the genuinely hard part is already behind them. Calm under pressure is mostly preparation that happened earlier, out of sight.
If you want the bigger arc this habit fits into, the brutal truth about becoming a senior developer is the piece I keep handing to engineers who feel busy but stuck.
Q: Isn't this just "write a design doc"? It's a lighter, personal cousin of that. Design docs are for the team and big projects. This is fifteen private minutes for a single task. Same principle, way less ceremony, done far more often.
Q: Doesn't planning kill the flow of just coding? The opposite, for me. Flow comes from knowing where you're going. Coding without a plan isn't flow — it's the stop-start of discovering the problem mid-build. Planning creates the conditions for flow.
Q: What about exploratory work where you don't know the answer yet? Then your plan is "spike to learn X, then plan for real." Even exploration benefits from naming what you're trying to learn. The habit flexes; it doesn't demand certainty you don't have.
Q: Does this work with AI coding tools? Better than without. A clear written plan is a great prompt. The engineers getting the most from AI assistants are usually the ones who can articulate the problem clearly first — which is exactly this habit.
I didn't double my output with a tool, a framework, or more hours. I did it by spending fifteen unglamorous minutes thinking on paper before touching the keyboard — trading a small visible cost for hours of invisible thrashing I used to pay every single day.
The fastest engineers I know aren't the fastest typists. They're the ones who figured out the problem before they started solving it.
So here's the honest question: how much of your day goes to writing code, and how much goes to rewriting code you started before you understood the problem?
I spent years saving the hardest task for when I 'felt ready.' Doing it first instead quietly fixed my focus, my dread, and my output.
Leaving my job wasn't a leap of faith. It was a spreadsheet. Here's the runway math that turned a terrifying gamble into a boring, calculate…
I tracked every distraction for a week and was horrified by what I found. Then I fixed the three that mattered most.
Comments
Sign in to join the conversation
No comments yet. Be the first to share your thoughts!