Fast is better than slow
15 points by judson
15 points by judson
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.
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.
What's "fast" though?
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.
Hopefully that makes sense.
“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.
a slowly built compiler of fast code is FAST.
The proper football quote would be this one:
Speed is often confused with insight. When I start running earlier than the others, I appear faster.
Which is attributed to (who else?) Cruyff.
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.
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.
Don’t worry about looking dumb.
I think when you are new to a place that is kind of a hassle - as often the first impression lasts often.
I fully agree with this, it matches my experience. Of course the counterpoint is "don't get attached".