Nah. Slow is smooth, smooth is fast. We increasingly live in a culture that doesn't care what you're doing or building as long as you're doing it as fast as possible. But that's dumb nonsense. Even the soccer example in the article is dumb; you can't score goals if you're not in control of the ball, and the way you get in control of the ball is with two touches. Build the right things. Solve the right problems. Do it slowly. The problems will still be there tomorrow.
Also I'm not going to listen to any quote that says "don't ask why, that's just how it is." That sounds like a cult to me.
Counterpoint: You can't balance on a bicycle if you go too slow.
Relevant quote (not from the original article):
The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality.
His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: fifty pound of pots rated an “A”, forty pounds a “B”, and so on. Those being graded on “quality”, however, needed to produce only one pot – albeit a perfect one – to get an “A”.
Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the “quantity” group was busily churning out piles of work – and learning from their mistakes – the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.
Source: Art and Fear by David Bayles and Ted Orland (I haven't read the book, just this quote)
Going fast is important, but the way to get fast is not to try to be fast.
The way to go fast is to go slow. By going slow you minimize wasted effort. You don't run in the wrong direction. You don't spend months creating thousands of lines of code building the wrong thing.
This is a lesson I have learned from drumming. How do you get fast? You get fast by slowing down. You slow down until you can play perfectly relaxed, in time, with minimal motion. Then you build up speed from there. If you focus on going fast, you will waste energy. To go fast you go slow and focus on getting it right.
I think the same applies to coding. You get fast by slowing down. Typing accurately. Thinking clearly. Building small iterations to verify the mental model of what needs to be done. By moving purposefully and deliberately, you will move faster than the LLM-equipped caffeine junkie building a copy of GCC only to throw it away.
The way to go fast is to go slow. By going slow you minimize wasted effort. You don't run in the wrong direction. You don't spend months creating thousands of lines of code building the wrong thing.
The way I work, is to be very fast, make a prototype, validate an idea (even if it's feature-sized), then, find out what I like the least about it, and do another fast iteration removing that. Repeat until there are no parts I don't like.
This means each iteration is fast, at each iteration point I can decide that it's going in the wrong direction and abort.
I've seen pretty large differences, when compared to someone who would think and plan for a long time, then when they finish their well-thought implementation, they realize that it's not the thing we need.
(Obviously this is biased, surely I've also spent time iterating on garbage where a well thought solution would've worked first-try, but it feels like that's not frequent)
I don't think our statements are in opposition. Another aspect of slowing down to move fast is practice. To just plan for a long time is not the approach I advocate. But, crucially, to try to deliver a finished product as quickly as possible is not it either. To try to move fast is the wrong path.
By practicing the fundamentals carefully in small iterations like you say, with the key being the deliberate learning loop to get more honed in on the correct solution. Someone trying to move fast doesn't have time for prototypes.
Over time, you get more practiced at prototyping, more accurate, more familiar with your tools - and you become faster and faster.
“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.”
I'm thinking of one particular ex-coworker dev who would consistently return work that was just that little bit below minimum viable product and externalise as hard as possible onto everyone around him. Smart and insightful (he did a great API redesign that was just the right level of minimal), but this was a clearly chosen working strategy. "Genius" was not his internal reputation.
This reminds me of a scene from Shirobako, the anime about anime production. A new animator keeps spending too long trying to make every key frame come out right. Her senior's advice is basically: don't optimize for perfect drawings yet. Draw faster.
The point isn't that rough work is better. It's that drawing faster means drawing more cuts, getting corrected more often, and building taste against real output instead of against the version in your head.
I think programming has the same shape. Speed isn't valuable because rushing is virtuous; it's valuable because it gives you more chances to be wrong, notice it, and adjust.
I used to be fast.
Writing scripts at godspeed to automate redundant tasks I was given to, and was considered a genius.
Now I'm just sitting on a huge pile of scripts nobody can use (not even me, because API change and lack of docs). Our team has grown and when people ask me how I used to do something I'm like "Oh yeah I have a script for that... There. It probably doesn't work anymore though".
And now we're back to doing things "slowly", but at least we can hire more people to be slow in parallel, and get things done quicker.
I still write scripts at godspeed. But when I do, I pretend to be slow to get the time to document it, and put it in the orchestrator so that everyone ELSE can be fast.
there is a cult of volume and there is a culture of quality. both have their place and should be kept wisely ballanced.
and then, sometimes slow moving yields faster results. Maradona was probably pretty slow compared to other players and yet he managed to be where it mattered and to dribble everyone and score.
There is a difference between being fast and being hurried. If you already are faster than others, an earlier deadline doesn't put you in as much of a hurry, and you can still do good, thorough work. But if going faster becomes the focus, there's no one that won't stress out and compromise.
I think that the actual advice presented in this article is decent-to-mediocre, it is just framed in a terrible, techbro, move-fast-and-break-things Silicon Valley esque manner. Part of the introduction contradicts the title: trying different approaches before moving forward actually sacrifices productivity in favor of correctness instead of just shipping a hacky or partially-working solution.
Also, hustle culture isn't just about working long hours, it's also about breaking things in the process of moving fast and adding hacks and technical debt to the codebase.
Don't delay.
Taking time to think about things or prioritizing other things is valid actually. However, it is true that just staring at a problem won't fix it.
Reclaim the small chunks.
Can't say much about this one as I don't have experience working and managing my time at an actual company.
Don't worry about looking dumb.
Agreed for the most part. Avoiding perfectionism is good as long as you don't publish entirely broken code.
Pick your battles.
Ehhhh. IMO, this sections leans too much toward just blindly agreeing with others without critical thought but isn't outright wrong.
Do only what’s required.
I agree with this to an extent. This is in a similar vein to avoiding perfectionism above. I certainly don't advocate for going above and beyond at work for no reason. However, it is important to not ship hacky or shoddy work that barely fulfills the requirements for the task.
Can't say much about this one as I don't have experience working and managing my time at an actual company.
What he's saying is: do more work under the conditions of fragmented attention and context-switching. This virtually guarantees that you will make dumb mistakes and cost yourself more time in the long run.
I always thought that the Agile Manifesto was obfuscated crap. And it is. But what I found recently is that in the same site they publish the "principles" which for me are pretty good!
Specifically:
Simplicity--the art of maximizing the amount of work not done--is essential.
Because everything takes longer than what we think. And thus if we want to get to building the right thing, the less distractions we have, the more likely we will get there sooner.
Once you're not wasting your time on things that don't matter, then you're good.
A completely different thing is that there's a problem of incentives that incentivizes crap. But that I don't know how to solve :(
I remember the other saying though that I need to be slow in order to be fast or the slow is smooth, and smooth is fast. Both very much applicable in order to learn to be fast in soccer.
I had to read through this twice to be comfortable sharing it with some teammates. The catchy title of course invites contrarian engagement. But the bullet points are all solid stuff. The part that I think is missing from the encouragement is the countering need to be thorough. Going fast never means be sloppy. I worry many who would justify their sloppy speed with an article like this. Computers (LLMs aside) don't do sloppy. They do reproducibly consistent. So by all means, go fast, but DO NOT BE SLOPPY. Period. And More periods.
We are what we consistently do. Practice being sloppy, and you'll get faster at being sloppy. Practice doing things right, and you'll get faster- and better- at doing them right. If you don't practice at all, you'll get better at making excuses for not practicing...
drmorr | 13 hours ago
Nah. Slow is smooth, smooth is fast. We increasingly live in a culture that doesn't care what you're doing or building as long as you're doing it as fast as possible. But that's dumb nonsense. Even the soccer example in the article is dumb; you can't score goals if you're not in control of the ball, and the way you get in control of the ball is with two touches. Build the right things. Solve the right problems. Do it slowly. The problems will still be there tomorrow.
Also I'm not going to listen to any quote that says "don't ask why, that's just how it is." That sounds like a cult to me.
bjeanes | 10 hours ago
Took the words right out of my mouth.
coolshaurya | an hour ago
Counterpoint: You can't balance on a bicycle if you go too slow.
Relevant quote (not from the original article):
Source: Art and Fear by David Bayles and Ted Orland (I haven't read the book, just this quote)
I also recommend this good take on the "slow is smooth, smooth is fast" principle: https://brendonakay.github.io/posts/2025-12-02-slow-is-steady.html
krig | 9 hours ago
Going fast is important, but the way to get fast is not to try to be fast.
The way to go fast is to go slow. By going slow you minimize wasted effort. You don't run in the wrong direction. You don't spend months creating thousands of lines of code building the wrong thing.
This is a lesson I have learned from drumming. How do you get fast? You get fast by slowing down. You slow down until you can play perfectly relaxed, in time, with minimal motion. Then you build up speed from there. If you focus on going fast, you will waste energy. To go fast you go slow and focus on getting it right.
I think the same applies to coding. You get fast by slowing down. Typing accurately. Thinking clearly. Building small iterations to verify the mental model of what needs to be done. By moving purposefully and deliberately, you will move faster than the LLM-equipped caffeine junkie building a copy of GCC only to throw it away.
deivid | 4 hours ago
What's "fast" though?
The way I work, is to be very fast, make a prototype, validate an idea (even if it's feature-sized), then, find out what I like the least about it, and do another fast iteration removing that. Repeat until there are no parts I don't like.
This means each iteration is fast, at each iteration point I can decide that it's going in the wrong direction and abort.
I've seen pretty large differences, when compared to someone who would think and plan for a long time, then when they finish their well-thought implementation, they realize that it's not the thing we need.
(Obviously this is biased, surely I've also spent time iterating on garbage where a well thought solution would've worked first-try, but it feels like that's not frequent)
krig | 4 hours ago
I don't think our statements are in opposition. Another aspect of slowing down to move fast is practice. To just plan for a long time is not the approach I advocate. But, crucially, to try to deliver a finished product as quickly as possible is not it either. To try to move fast is the wrong path.
By practicing the fundamentals carefully in small iterations like you say, with the key being the deliberate learning loop to get more honed in on the correct solution. Someone trying to move fast doesn't have time for prototypes.
Over time, you get more practiced at prototyping, more accurate, more familiar with your tools - and you become faster and faster.
Hopefully that makes sense.
David_Gerard | 8 hours ago
I'm thinking of one particular ex-coworker dev who would consistently return work that was just that little bit below minimum viable product and externalise as hard as possible onto everyone around him. Smart and insightful (he did a great API redesign that was just the right level of minimal), but this was a clearly chosen working strategy. "Genius" was not his internal reputation.
scubbo | an hour ago
I wonder what his reputation was with those who set his salary, rather than among his peers? I wonder which of those he valued more-highly?
(Note - this observation should not be taken as approval!)
hongminhee | 14 hours ago
This reminds me of a scene from Shirobako, the anime about anime production. A new animator keeps spending too long trying to make every key frame come out right. Her senior's advice is basically: don't optimize for perfect drawings yet. Draw faster.
The point isn't that rough work is better. It's that drawing faster means drawing more cuts, getting corrected more often, and building taste against real output instead of against the version in your head.
I think programming has the same shape. Speed isn't valuable because rushing is virtuous; it's valuable because it gives you more chances to be wrong, notice it, and adjust.
z3bra | 11 hours ago
I used to be fast. Writing scripts at godspeed to automate redundant tasks I was given to, and was considered a genius.
Now I'm just sitting on a huge pile of scripts nobody can use (not even me, because API change and lack of docs). Our team has grown and when people ask me how I used to do something I'm like "Oh yeah I have a script for that... There. It probably doesn't work anymore though".
And now we're back to doing things "slowly", but at least we can hire more people to be slow in parallel, and get things done quicker.
I still write scripts at godspeed. But when I do, I pretend to be slow to get the time to document it, and put it in the orchestrator so that everyone ELSE can be fast.
carlomonte | 12 hours ago
there is a cult of volume and there is a culture of quality. both have their place and should be kept wisely ballanced.
and then, sometimes slow moving yields faster results. Maradona was probably pretty slow compared to other players and yet he managed to be where it mattered and to dribble everyone and score.
a slowly built compiler of fast code is FAST.
koala | 11 hours ago
The proper football quote would be this one:
Which is attributed to (who else?) Cruyff.
kevinc | 3 hours ago
There is a difference between being fast and being hurried. If you already are faster than others, an earlier deadline doesn't put you in as much of a hurry, and you can still do good, thorough work. But if going faster becomes the focus, there's no one that won't stress out and compromise.
coolshaurya | an hour ago
I think that the actual advice presented in this article is decent-to-mediocre, it is just framed in a terrible, techbro, move-fast-and-break-things Silicon Valley esque manner. Part of the introduction contradicts the title: trying different approaches before moving forward actually sacrifices productivity in favor of correctness instead of just shipping a hacky or partially-working solution.
Also, hustle culture isn't just about working long hours, it's also about breaking things in the process of moving fast and adding hacks and technical debt to the codebase.
Taking time to think about things or prioritizing other things is valid actually. However, it is true that just staring at a problem won't fix it.
Can't say much about this one as I don't have experience working and managing my time at an actual company.
Agreed for the most part. Avoiding perfectionism is good as long as you don't publish entirely broken code.
Ehhhh. IMO, this sections leans too much toward just blindly agreeing with others without critical thought but isn't outright wrong.
I agree with this to an extent. This is in a similar vein to avoiding perfectionism above. I certainly don't advocate for going above and beyond at work for no reason. However, it is important to not ship hacky or shoddy work that barely fulfills the requirements for the task.
colonelpanic | 15 minutes ago
What he's saying is: do more work under the conditions of fragmented attention and context-switching. This virtually guarantees that you will make dumb mistakes and cost yourself more time in the long run.
xilef | 16 hours ago
"Fast"? or just pragmatic?
koala | 11 hours ago
I always thought that the Agile Manifesto was obfuscated crap. And it is. But what I found recently is that in the same site they publish the "principles" which for me are pretty good!
Specifically:
Because everything takes longer than what we think. And thus if we want to get to building the right thing, the less distractions we have, the more likely we will get there sooner.
Once you're not wasting your time on things that don't matter, then you're good.
A completely different thing is that there's a problem of incentives that incentivizes crap. But that I don't know how to solve :(
adamo | 9 hours ago
I remember the other saying though that I need to be slow in order to be fast or the slow is smooth, and smooth is fast. Both very much applicable in order to learn to be fast in soccer.
travisgriggs | an hour ago
I had to read through this twice to be comfortable sharing it with some teammates. The catchy title of course invites contrarian engagement. But the bullet points are all solid stuff. The part that I think is missing from the encouragement is the countering need to be thorough. Going fast never means be sloppy. I worry many who would justify their sloppy speed with an article like this. Computers (LLMs aside) don't do sloppy. They do reproducibly consistent. So by all means, go fast, but DO NOT BE SLOPPY. Period. And More periods.
Internet_Janitor | 44 minutes ago
We are what we consistently do. Practice being sloppy, and you'll get faster at being sloppy. Practice doing things right, and you'll get faster- and better- at doing them right. If you don't practice at all, you'll get better at making excuses for not practicing...
dhruvp | 12 hours ago
I think when you are new to a place that is kind of a hassle - as often the first impression lasts often.
FeepingCreature | 8 hours ago
I fully agree with this, it matches my experience. Of course the counterpoint is "don't get attached".