Wookyoung Kim · May 31, 2026
Fast is better than slow
I think success is the repeated act of using what came before, or what exists now, as leverage to climb higher. That is why the widest range of experience leads to the highest level of success. Success equals as much experience as possible. And to gain as much experience as possible, you need to execute as much as possible.
Success = experience = hypothesis testing x speed, and speed does not belong to an individual. In general, speed is set by the slowest part of the whole. So if you are on a team, you always have to be fast.
Today I translated Patrick Dubroy's Fast Is Better Than Slow.
Do not ask why. Fast is better than slow. That is just how it is. Your job is to do everything you can already do, faster.
If you can accept the idea that fast is better than slow, you are already halfway there. If you can get the whole team to accept it, you will win a lot of games.
All else being equal, if you can move the ball from point A to point B with one touch, that is better than doing it with two. Why? Because one touch is faster than two, and fast is better than slow.
- Dan Blank, Soccer IQ
About ten years ago, I realized that the best programmers I had worked with all had one thing in common: they were fast. By fast, I mean they moved quickly. After we discussed a problem together, an hour or two later they would already have a patch ready or a prototype to show.
It took me a while, but eventually I understood: they were not fast because they were great programmers. They were great programmers because they were fast.
Think about it. If you are fast, you get data sooner. That lets you make better decisions earlier. It also means you learn faster, and over a long enough period, you learn more. Being fast means you can try several approaches to the same problem and choose the best one.
A lot of people push back on this because it sounds like hustle culture. But there are many ways to move faster without working longer hours. Jamie Brandon wrote two excellent posts on this: Speed matters and Moving faster. If you have not read them yet, I recommend them.
I have a few suggestions too. They are less about coding itself and more about the messy reality of working as a software engineer. And, somewhat embarrassingly, unlike Jamie, it took me more than ten years to learn them.
Do not procrastinate. This really matters. I have seen many people who seem to habitually move slowly. They learn about a problem at 4 p.m. and decide to deal with it tomorrow. Or next week. Or next quarter.
I think this is often an attempt to avoid discomfort. Getting started is hard. You often do not know exactly what to do or where to begin. It is comforting to believe that waiting will make things easier, but in my experience, it almost never does.
Take back the scraps of time. Some programmers have convinced themselves that they need long, uninterrupted blocks of work to get anything done. As I wrote in Getting things done (in small increments), I think this is more of a preference than an absolute constraint. Most people can get better at it with effort.
The gains can be surprisingly large. At many companies, you are lucky to get even one uninterrupted three- or four-hour block in a day. Add another hour or two of meetings, and 25 to 35 percent of your time disappears into fragmentation. If you use that time productively instead of reading email or browsing Hacker News, you can get far more done.
Do not worry about looking stupid. You probably already know that you should share your work early and often. But it is uncomfortable, so it is easy to delay while telling yourself a story like, "I just have high quality standards."
If you learn to push through that discomfort, you can get results much faster. Oliver Burkeman talks about the 70 percent rule:
If you are roughly 70 percent satisfied with something you have written, you should publish it. If you are 70 percent satisfied with a product you have built, launch it. [...] Moving forward at 70 percent requires more nerve and stronger character than waiting for 100 percent, because it means moving through uncertainty, anxiety, and the unpleasant feelings that come with putting imperfect work into the world.
The same applies to PRs. Do not waste time polishing your code in the hope that the reviewer will find nothing wrong. Put it up now and accept the feedback. You do not get extra points for getting a PR approved with zero comments.
Another way to move faster, even if it may make you look stupid in the process, is to ask your colleagues for advice. I have seen many developers who seem to believe they have to figure everything out alone. But software development is a team sport. Do not pressure yourself to do it all by yourself.
Pick your battles. In collaboration, do not waste time arguing over trivial things. If a PR reviewer wants you to change something, it is almost always faster to just make the requested change than to fight about it. In 95 percent of cases, the difference is too minor to be worth discussing. Save your time and energy for the 5 percent that truly matters.
The same applies when you are reviewing. Do not waste time on things that do not matter. I am absolutely not saying you should rubber-stamp everything. I often leave comments suggesting a better name or a different approach, but I leave the final decision to the author. At least half of my reviews are probably "LGTM with comments." I think this lets you and your colleagues keep code review from consuming too much time while still getting most of its benefits.
Do only what was asked. During one of my first internships, my team lead gave me this advice: "When someone asks you to do something, do the minimum required. If you can do that consistently, everyone will think you are a genius." At the time I thought it was cynical, but over the years I realized how wise it was.
When you try to "go above and beyond," you are almost always guessing: guessing what someone else wants, or what the system will need in the future. And the less experience you have, the more likely those guesses are to be wrong.
If you want to move faster, do not waste time doing work nobody asked for.
Do not ask why. Fast is better than slow. That is just how it is. Your job is to do everything you can already do, faster.