Fast is better than slow
May 23, 2026Don’t question why. Fast is better than slow. That’s just how it is. Your job is to take everything you can already do and do it faster.
If you can embrace the idea that fast is intrinsically better than slow, you’re halfway home. If you can get an entire team of players to embrace that idea, you’re going to win a lot of games.
All other things being equal, if I can get the ball from Point A to Point B with one touch, it is better than getting it there in two touches. Why? Because one touch is faster than two touches, and fast is better than slow.
— Dan Blank, Soccer IQ
About 10 years ago, I realized all the best programmers I had worked with had something in common: they were fast. By that I mean that they moved quickly: we’d discuss a problem and an hour or two later they’d already have a patch ready or a prototype to show off.
It took me a while, but eventually I realized: they weren’t fast because they were great programmers, they were great programmers because they were fast.
Think about it — if you’re fast, you get data more quickly. That helps you make better decisions, sooner. It also means you learn faster, and over longer periods it means you learn more. Being fast also means you can try out multiple approaches to a problem and pick the best one.
A lot of people push back on this because it sounds like hustle culture. But there are lots of ways to move faster that don’t involve working long hours. Jamie Brandon has written a pair of excellent posts on this: Speed matters and Moving faster. You should go and read those if you haven’t already.
I have a few suggestions of my own — things that are a bit more about the messy reality of working as a software engineer than they are about coding per se. And I’m slightly embarrassed to admit that, unlike Jamie, they took me more than a decade to learn.
Don’t delay. This is a big one. I’ve worked with many people who seem to move slowly out of habit. They learn about a problem at 4pm, and decide to tackle it tomorrow. Or next week, or next quarter.
I think this is often about avoiding discomfort. Getting started is hard: you often don’t know exactly what needs to be done, or where to begin. It’s comforting to believe that waiting will make it easier, but in my experience it rarely does.
Reclaim the small chunks. Some programmers have convinced themselves that they need long, interrupted work periods to get anything done. As I wrote in Getting things done (in small increments), I think this is more of a preference than a hard constraint. Most people could get better at this if they tried.
The wins can be surprisingly big. At many companies, you might be lucky to have a single uninterrupted block of 3–4 hours each day. Say you have another hour or two of meetings — that’s still 25–35% of your time lost to fragmentation. You can get a lot more done if you spend that time being productive rather than reading email or browsing Hacker News.
Don’t worry about looking dumb. You probably already know that you should share your work early and often. But it’s uncomfortable, so it’s easy to put it off while telling yourself a story like “I have a high bar for quality.”
You’ll get results much faster if you learn to push through that discomfort. Oliver Burkeman talks about the 70% rule:
If you’re roughly 70% happy with a piece of writing you’ve produced, you’ll should publish it. If you’re 70% satisfied with a product you’ve created, launch it.
[…]
Moving forward at 70% takes more guts, more strength of character, than holding out for 100%, because it entails moving forward amid uncertainty, anxiety, and the disagreeable feeling that comes with putting less-than-perfect work into the world.
The same goes for PRs. Don’t waste time polishing your code in hopes that your reviewer will find nothing wrong — push it now and accept the feedback. There are no points for getting your PR approved without comments.
Another way to move more quickly (and potentially look dumb in the process) is to ask your colleagues for advice. I’ve seen many developers who seem to think they’re required to come up with everything themselves. But software development is a team sport — don’t force yourself to go it alone.
Pick your battles. When it comes to collaboration, don’t waste time bikeshedding. If your PR reviewer wants you to change something, it’s almost always faster to do what they’re asking than to argue about it. 95% of the time, the differences are so minor that it’s barely worth discussing. Save your time and energy for the 5% that matter.
The same thing applies when you’re reviewing — don’t waste your time on inconsequential things. I’m definitely not saying you should rubber stamp everything; I often leave comments suggesting better names, or other ways to do things, but leave the final decision up to the author. I think at least 50% of my reviews are “LGTM with comments” — in my opinion, this gives you most of the benefits of code review without letting it suck up too much time (for you or your teammates).
Do only what’s required. In one of my first internships, the team lead gave me some advice: “When someone asks you to do something, do the absolute minimum that’s required. If you can do that consistently, everyone will think you’re a genius.” At the time, I thought it was cynical; but over the years, I’ve come to realize how wise it is.
If you try to go “above and beyond”, you’re almost always guessing — about what someone else wants, or what the system will require in the future. And the more inexperienced you are, the greater the chance that your guess is wrong.
To move faster, don’t waste time doing things that nobody asked for.
Don’t question why. Fast is better than slow. That’s just how it is. Your job is to take everything you can already do and do it faster.