Why Speed Matters(lemire.me)
lemire.me
Why Speed Matters
https://lemire.me/blog/2025/12/05/why-speed-matters/
53 comments
I remember the same anecdote, but about pottery https://austinkleon.com/2020/12/10/quantity-leads-to-quality... https://news.ycombinator.com/item?id=12653203 https://blog.codinghorror.com/quantity-always-trumps-quality...
Yeah I’m pretty sure this was about pottery.
If you make the same pot 100 times that 100th pot is your best one.
If you make the same pot 100 times that 100th pot is your best one.
I found the name of that photographer (RIP), who lives in Florida and who taught. Also has a thing about quantity over quality. But his own site didn't specifically mention this anecdote. I've also read the pottery one.
I'd love to know if either are real and verifiable.
The lesson is most likely real and applicable either way.
I'd love to know if either are real and verifiable.
The lesson is most likely real and applicable either way.
The writers took the photo story and changed the words into a pottery story, to add some variety.
The photo story isn't the whole story.
Did the students know that the professor would also choose which were the best photos ?
The "quality" group were only required to produce one photo, but were they allowed to produce 100 photos?
If so, did the professor include all those photos when they chose which were the best photos ?
If not, did the professor look at a much larger sample of photos from the "quantity" group than the "quality" group to decide which were the best photos?
The photo story isn't the whole story.
Did the students know that the professor would also choose which were the best photos ?
The "quality" group were only required to produce one photo, but were they allowed to produce 100 photos?
If so, did the professor include all those photos when they chose which were the best photos ?
If not, did the professor look at a much larger sample of photos from the "quantity" group than the "quality" group to decide which were the best photos?
My experience with writing, music, and photography is that I get better results trying a bunch of different things rather than focusing on one or a few. The quality is still variable, but the hit rate is much higher. I can then switch to polishing a batch of hits rather than trying to turn a single idea into a hit.
[deleted]
The story about the photography students was conveyed almost verbatim in the book Atomic Habits fwiw.
But I think this type of principle has been relayed through many forms. Even Bruce Lee has the famous quote “I fear not the man who has practiced 10,000 kicks once, but I fear the man who has practiced one kick 10,000 times.”
But I think this type of principle has been relayed through many forms. Even Bruce Lee has the famous quote “I fear not the man who has practiced 10,000 kicks once, but I fear the man who has practiced one kick 10,000 times.”
What seems to be claimed is more like: If you make one single pot and you make 100 pots, at-least one of the 100 pots will be "better" than the single pot. (The 100th pot might be really bad.)
Supposedly —
“Yes, the ‘ceramics story’ in ‘Art & Fear’ is indeed true, allowing for some literary license in the retelling. Its real-world origin was as a gambit employed by photographer Jerry Uelsmann to motivate his Beginning Photography students at the University of Florida.
(See the notes in "Atomic Habits" "The Danger of Aiming for Perfection" — "As retold in ‘Art & Fear’ it faithfully captures the scene … except I replaced photography with ceramics as the medium being explored.")
“Yes, the ‘ceramics story’ in ‘Art & Fear’ is indeed true, allowing for some literary license in the retelling. Its real-world origin was as a gambit employed by photographer Jerry Uelsmann to motivate his Beginning Photography students at the University of Florida.
(See the notes in "Atomic Habits" "The Danger of Aiming for Perfection" — "As retold in ‘Art & Fear’ it faithfully captures the scene … except I replaced photography with ceramics as the medium being explored.")
~
> … these students were busy taking photos, experimenting with composition and lighting, testing out various methods in the darkroom, and learning from their mistakes.
Why?
Supposedly they would be graded A for exposing 100 frames of the lens-cap.
Presumably the "quantity" group were highly self-motivated individuals invested in developing their skills.
Presumably the "quality" group were also highly self-motivated individuals invested in developing their skills.
The difference is that the "quality" group only had once chance to impress the professor.
In contrast, the "quantity" group had at-least 100 chances to impress the professor.
Sampling bias.
Why?
Supposedly they would be graded A for exposing 100 frames of the lens-cap.
Presumably the "quantity" group were highly self-motivated individuals invested in developing their skills.
Presumably the "quality" group were also highly self-motivated individuals invested in developing their skills.
~
The difference is that the "quality" group only had once chance to impress the professor.
In contrast, the "quantity" group had at-least 100 chances to impress the professor.
Sampling bias.
@thehuntingphotographer > "… I’ll often shoot 1,000+ shots a day. Of course only a fraction of those shots are good but the act of repetition leads to perfection."
Where's the evidence of improvement?
Maybe it's just a bigger sample, so more chance that some will be good shots?
Where's the evidence of improvement?
Maybe it's just a bigger sample, so more chance that some will be good shots?
Even in film photography it can be cheap to create alternatives and choose between them. Other things aren't like that.
Does the blogger mean something different than "Plan to throw one away - you will anyway. "
Does the blogger mean something different than "Plan to throw one away - you will anyway. "
> Reminds me of this
There seemed to be a reasonable similarity at-first-glance, but the Art & Fear ceramics teacher / photography professor parable was intended to make a different point.
This point — “to require perfection is to invite paralysis.” Art & Fear page 30
There seemed to be a reasonable similarity at-first-glance, but the Art & Fear ceramics teacher / photography professor parable was intended to make a different point.
This point — “to require perfection is to invite paralysis.” Art & Fear page 30
Oh there you go, that's what I was talking about https://news.ycombinator.com/item?id=46174424
I get what he's trying to say, but the danger is people (especially management) getting the wrong impression. The risk of "move fast is good" is that it becomes hustle culture where people rush under deadlines and eventually burn out. There are plenty of occasions where slowing down and being thoughtful is beneficial. Often stopping focus is what gives eureka moments as the other side of the brain starts churning once new input ceases. There's a reason the cliché story of your best ideas happen on the toilet or in the shower are a thing.
It's like people reading Radical Candor (which I quite like) and concluding that being an asshole is ok.
It's like people reading Radical Candor (which I quite like) and concluding that being an asshole is ok.
I am all in favor of continuous development. Program. Check-In. Build. Test. Merge to dev. Build. Test. Merge to master. Build. Test. Deploy. I have a very fancy Play Button, that does everything automatically.
But it always takes like half an hour. :))
I usually start then something else. I have many projects open. But its like....these context switches, they are draining.
So yeah, i like to go the dangerous part, deploy right away from my dev machine. But i get immediate reaction. I dont have to wait. But my mates dont like it. And so i deal with it.
But it always takes like half an hour. :))
I usually start then something else. I have many projects open. But its like....these context switches, they are draining.
So yeah, i like to go the dangerous part, deploy right away from my dev machine. But i get immediate reaction. I dont have to wait. But my mates dont like it. And so i deal with it.
That half an hour is a perfect argument for why _software_ speed matters too. Without fast software you get stuck being slow at the human parts too, ultimately reducing your potential.
To me, the kind of speed that matters is maximizing the rate that your idea/product/work contacts reality. This is only indirectly explained in point 2 at the bottom of this post.
Indiscriminately espousing raw speed for every step is a perfect recipe for burnout.
Indiscriminately espousing raw speed for every step is a perfect recipe for burnout.
On the other hand, "slow is smooth, smooth is fast". Which strategy is optimal depends on the nature of the product and the cost of iteration.
In software, optimizing for speed works best in cases where architecture has minimal relevance for product outcomes. If I am writing a Python library then I typically iterate very quickly. Swapping out bits of implementation has low cost.
If I am writing a database kernel then designing any part of it poorly has a high chance of permanently crippling the implementation. Iterating is often tantamount to a major rewrite and extremely costly. You can only afford a very small number of rewrites before the iteration time stretches into years, so it is actually faster to spend much more time thinking through details that may seem unimportant.
In software, optimizing for speed works best in cases where architecture has minimal relevance for product outcomes. If I am writing a Python library then I typically iterate very quickly. Swapping out bits of implementation has low cost.
If I am writing a database kernel then designing any part of it poorly has a high chance of permanently crippling the implementation. Iterating is often tantamount to a major rewrite and extremely costly. You can only afford a very small number of rewrites before the iteration time stretches into years, so it is actually faster to spend much more time thinking through details that may seem unimportant.
> In software, optimizing for speed works best in cases where architecture has minimal relevance for product outcomes.
The other consideration is the impact of low quality on the business.
Generally, I find that cleaning up issues in production systems (e.g. transactions all computed incorrectly and flowed to 9 downstream systems, incorrectly) far outweighs the time it takes to get it right.
Even if the issue doesn't involve fixing data all over the place and just involves creating a manual work around, that can still be a huge issue that requires business people and systems people to work out an alternate process that correctly achieves the result and gets the systems into the correct state.
The approach I've seen that seems to work is to reduce scope and never reduce quality. You can still get stuff done rapidly and learn about what functions well for the business and what doesn't, but anything you commit to should work as expected in production.
The other consideration is the impact of low quality on the business.
Generally, I find that cleaning up issues in production systems (e.g. transactions all computed incorrectly and flowed to 9 downstream systems, incorrectly) far outweighs the time it takes to get it right.
Even if the issue doesn't involve fixing data all over the place and just involves creating a manual work around, that can still be a huge issue that requires business people and systems people to work out an alternate process that correctly achieves the result and gets the systems into the correct state.
The approach I've seen that seems to work is to reduce scope and never reduce quality. You can still get stuff done rapidly and learn about what functions well for the business and what doesn't, but anything you commit to should work as expected in production.
For the complex stuff it still holds true.
A lot of times you have the wrong solution and the better use of your time is to do something you can do fast. Then keep coming back to it and usually you come up with an idea that is much simpler and fast to implement.
A lot of times you have the wrong solution and the better use of your time is to do something you can do fast. Then keep coming back to it and usually you come up with an idea that is much simpler and fast to implement.
> optimizing for speed
You presumably mean prioritizing development speed, which is essentially the opposite.
You presumably mean prioritizing development speed, which is essentially the opposite.
Thing is, speed is not linear.
Sometimes, it's better to take the time of building the right foundations in order to propel yourself ahead later.
Rather than building on a shaky base, rushing, and getting stuck after a while.
I think there is an Aesop fable for it?
Rather than building on a shaky base, rushing, and getting stuck after a while.
I think there is an Aesop fable for it?
The point about work becoming irrelevant is especially painful. SaaS faces rising table stakes from competitors. Locally run software is in a race against platform obsolescence. Some times it feels like trying to surf on a never ending wave.
The last bit about the heart surgeon, turns out you actually want the surgeon with the best outcomes not the one who does it the quickest. It seems like we're quibbling over surrogate measures for important outcomes.
Would you rather have a heart surgeon who studied for years, spent years practising and assisting, and took time building up the skills needed; or a heart surgeon who just flipped through a book and watched a video on heart surgery?
Finding the golden middle ground between 'move fast and break things' and 'move slow and fix things' is difficult and as the stakes get higher it's only natural to favour slow, steady, and careful over flying by the seat of your pants.
Finding the golden middle ground between 'move fast and break things' and 'move slow and fix things' is difficult and as the stakes get higher it's only natural to favour slow, steady, and careful over flying by the seat of your pants.
>>golden middle ground
Exactly!
You want the surgeon who took the time to study deeply, then went into practice doing as many surgeries as possible, but then also taking the time to review/debrief/analyze the process and results. So, yes, it is a real mix or "golden middle ground" with excursions to both extremes. The opposite of a one-size-fits-all approach to each step.
Exactly!
You want the surgeon who took the time to study deeply, then went into practice doing as many surgeries as possible, but then also taking the time to review/debrief/analyze the process and results. So, yes, it is a real mix or "golden middle ground" with excursions to both extremes. The opposite of a one-size-fits-all approach to each step.
That metaphor is a bit strained, since in reality, heart surgery is so high stakes that there is no (legal) way to just crank through hundreds of them for the purpose of racking up experience. (You can operate on cadavers, sure, but it's not like the cadaver is going to have a beating heart, nor exhibit the exact medical condition you're practicing for.)
So yeah, it's always better to have lots of experience, and moving fast is indeed great for quickly acquiring experience, But in some fields and situations you can't afford to move fast, you just have to spend the necessary years.
Writing is a much better example - many great writers talk about how they write all the time, every day, but very little of it gets successfully published. But the practice gives them good experience.
So yeah, it's always better to have lots of experience, and moving fast is indeed great for quickly acquiring experience, But in some fields and situations you can't afford to move fast, you just have to spend the necessary years.
Writing is a much better example - many great writers talk about how they write all the time, every day, but very little of it gets successfully published. But the practice gives them good experience.
On the other hand I'd prefer a heart surgeon who performed a hundred low-stakes surgeries and is now on his first heart surgery over the heart surgeon who has done one heart surgery before but has otherwise no surgery experience
As the stakes get higher you have to slow down, but imho the right takeaway from that is that you need to find low-stakes environments where you can move fast, in addition to whatever high-stakes environment you have
As the stakes get higher you have to slow down, but imho the right takeaway from that is that you need to find low-stakes environments where you can move fast, in addition to whatever high-stakes environment you have
Wrong criteria. Evaluate the number of successful outcomes!
(Including the cancelled interventions when the surgeon recognized that surgery was not required.)
(Including the cancelled interventions when the surgeon recognized that surgery was not required.)
Sometimes the perception of speed is just as important as actual speed. No I'm not bitter, why do you ask?
In general, advice like "move faster" is more likely to yield results than "move slower".
The world conspires to prevent action. Humans (like all lifeforms) are naturally lazy. We want to get the biggest benefit for the least expenditure of energy. There's always a voice in the back of our minds saying, "nah, don't bother doing that--it's too much work and it's not worth it."
Everything we see reinforces this voice. When we see hustle culture, we think, "that's cringe--I would never want to do that." And so we don't. When a startup fails, we think, "see, it's not worth it." And when a startup succeeds, we think, "well, they got lucky, and anyway they had rich parents, so they were bound to succeed."
Worse, it's easy to do things that feel like action but are really just time-wasters. Reading one more advice post. Organizing our workspace. Learning one more tool/technology/process.
Moving faster means don't wait. Act now.
"But I don't want to move fast and break things!" That's the voice again, preventing you from acting. Yes, moving too fast absolutely has risks, but not as many risks as moving too slow.
The only guarantee in life is that we'll be dead one day, and I for one want to get as much out of my limited time as I can. I'm not going to waste it waiting.
The world conspires to prevent action. Humans (like all lifeforms) are naturally lazy. We want to get the biggest benefit for the least expenditure of energy. There's always a voice in the back of our minds saying, "nah, don't bother doing that--it's too much work and it's not worth it."
Everything we see reinforces this voice. When we see hustle culture, we think, "that's cringe--I would never want to do that." And so we don't. When a startup fails, we think, "see, it's not worth it." And when a startup succeeds, we think, "well, they got lucky, and anyway they had rich parents, so they were bound to succeed."
Worse, it's easy to do things that feel like action but are really just time-wasters. Reading one more advice post. Organizing our workspace. Learning one more tool/technology/process.
Moving faster means don't wait. Act now.
"But I don't want to move fast and break things!" That's the voice again, preventing you from acting. Yes, moving too fast absolutely has risks, but not as many risks as moving too slow.
The only guarantee in life is that we'll be dead one day, and I for one want to get as much out of my limited time as I can. I'm not going to waste it waiting.
I once read an essay on how people often believe that to be good at something you have to spend a lot of time theorizing about it. I think the example they used was painting or pottery or something: someone who spends 1 year thinking about the perfect pot and then makes it, vs someone who spends 1 year making pots. I was convinced and kept in mind ever since.
But I hadn't until now seen the connection to speed spelled out. Of course, to try a lot you have to be fast at each attemp.
But I hadn't until now seen the connection to speed spelled out. Of course, to try a lot you have to be fast at each attemp.
It is even more true with startups and business. Super rushed is bad, but doing for too long decreases quality.
Moving fast should not mean reducing quality.
The real skill is to know when speed is the way to go and when taking your time is the better strategy.
Goldilocks — not actionable.
>> Nevertheless, you should move as fast as you can.
For one thing, try defining what you mean by "fast". and what you mean by "move". And why this expectation should be correct for generic cases from any location, time and context.
For one thing, try defining what you mean by "fast". and what you mean by "move". And why this expectation should be correct for generic cases from any location, time and context.
Yeah, he should also define "you". Is he talking about me, you or himself?
"We can use one, you, we and they to refer to ‘people in general’."
https://dictionary.cambridge.org/us/grammar/british-grammar/...
https://dictionary.cambridge.org/us/grammar/british-grammar/...
The author recognizes that they need to clarify what they don't mean -- "Moving fast does not mean …" but seemingly fails to say what they do mean.
You can only move fast without crashing all the time if you've already developed expert-level skills, and that takes time. Two examples come to mind: Albert Einstein's work on special vs. general relativity, and Adrej Karpathy's ML tutorials. Now, if you want to explore this in more detail, here are two prompts I wrote myself that you can use to get the full argument:
(1) As an expert in scientific discovery in the 19th and 20th century, let's disassemble a general claim using the specific example of Einstein's work on special relativity and general relativity. First, here is the claim: "If I give you two PhD students, one who completed their thesis in two years and one who took eight years… you can be almost certain that the two-year thesis will be much better." Things to keep in mind: (1) special relativity was baked into Maxwell's electromagnetism and should have been discovered years before Einstein, and (2) general relativity was a novel application of non-Euclidean geometry and mathematics to the gravity problem, that is the acceleration problem, and was quite a unique accomplishment. Discuss the 'amount of research' that went into each development by Einstein and lay out the argument that this disproves our claim, with any caveats you think appropriate.
(2) In general, it seems to take about ten years of diligent focused effort for a person to develop their skill levels to the point where they can make meaningful contributions to any science, engineering, or even artistic field. Einstein seems to follow this trend, if we start counting from his teenage fascination with physics. Another example is the very popular instructional videos on machine learning by Andrej Karpathy, eg "The spelled out intro to neural networks and backpropagation: building micrograd" in which he begins by stating he's been programming neural nets for ten years. Thus, it seems fair to conclude that 'move fast' only makes sense after 'develop the required expertise to know how to move fast'.
(1) As an expert in scientific discovery in the 19th and 20th century, let's disassemble a general claim using the specific example of Einstein's work on special relativity and general relativity. First, here is the claim: "If I give you two PhD students, one who completed their thesis in two years and one who took eight years… you can be almost certain that the two-year thesis will be much better." Things to keep in mind: (1) special relativity was baked into Maxwell's electromagnetism and should have been discovered years before Einstein, and (2) general relativity was a novel application of non-Euclidean geometry and mathematics to the gravity problem, that is the acceleration problem, and was quite a unique accomplishment. Discuss the 'amount of research' that went into each development by Einstein and lay out the argument that this disproves our claim, with any caveats you think appropriate.
(2) In general, it seems to take about ten years of diligent focused effort for a person to develop their skill levels to the point where they can make meaningful contributions to any science, engineering, or even artistic field. Einstein seems to follow this trend, if we start counting from his teenage fascination with physics. Another example is the very popular instructional videos on machine learning by Andrej Karpathy, eg "The spelled out intro to neural networks and backpropagation: building micrograd" in which he begins by stating he's been programming neural nets for ten years. Thus, it seems fair to conclude that 'move fast' only makes sense after 'develop the required expertise to know how to move fast'.
Follow-up prompt, as the original author claims to be a computer science professor:
(3) Are there any examples in software development -- I'm thinking about the development of the early yield management applications in the airline industry (e.g. SABRE), for example.
expected this to be about cpu cycles, given the author's works :D
Reminded me of this: https://jsomers.net/blog/speed-matters
I've always disliked this advice because it's trite. It's often true at an individual level, yet in practice, I've never seen this work once more people are added to the equation.
That’s funny because I have seen this advice most needed in large projects, where things drag out because people keep having new ideas that they think will make it better. The insidious part is that certainly some ideas are good, the issue is that identifying the most critical changes is never definitive until you ship and see if it works.
(Obviously this advice can easily go horribly wrong in the hands of incompetent leadership, context matters, etc)
(Obviously this advice can easily go horribly wrong in the hands of incompetent leadership, context matters, etc)
> new ideas
Don't add them to current development; add them to future development.
Don't add them to current development; add them to future development.
External pressure forces me to focus. It requires you to identify ambiguity, and make a choice, vs solving for both branches.
The problem is that now with the giant amount of code that is generated we are seeing that management is really happy with those people who are getting feature after feature released.
But... as a team we're not allowed to say no to this slop. Nor are we allowed to point fingers to it when at 2AM code falls over because of some edge-case that wasn't considered.
The sheer volume removes 2 people from the equation. The developer who doesn't think line by line, and the reviewer who is overwhelmed by the amount of code.
And no, saying no is not an option. Because then you're the person with high quality standards.
Speed matters, but only if we all obey the same bar of quality.
The problem is that now with the giant amount of code that is generated we are seeing that management is really happy with those people who are getting feature after feature released.
But... as a team we're not allowed to say no to this slop. Nor are we allowed to point fingers to it when at 2AM code falls over because of some edge-case that wasn't considered.
The sheer volume removes 2 people from the equation. The developer who doesn't think line by line, and the reviewer who is overwhelmed by the amount of code.
And no, saying no is not an option. Because then you're the person with high quality standards.
Speed matters, but only if we all obey the same bar of quality.
[flagged]
Please stop wasting your time with this dreck from multiple different accounts. It doesn't get seen by more than a handful of people. Life is short. Use it well.
"""On the first day of class, Jerry Uelsmann, a professor at the University of Florida, divided his film photography students into two groups.
Everyone on the left side of the classroom, he explained, would be in the “quantity” group. They would be graded solely on the amount of work they produced. On the final day of class, he would tally the number of photos submitted by each student. One hundred photos would rate an A, ninety photos a B, eighty photos a C, and so on.
Meanwhile, everyone on the right side of the room would be in the “quality” group. They would be graded only on the excellence of their work. They would only need to produce one photo during the semester, but to get an A, it had to be a nearly perfect image.
At the end of the term, he was surprised to find that all the best photos were produced by the quantity group. During the semester, these students were busy taking photos, experimenting with composition and lighting, testing out various methods in the darkroom, and learning from their mistakes. In the process of creating hundreds of photos, they honed their skills. Meanwhile, the quality group sat around speculating about perfection. In the end, they had little to show for their efforts other than unverified theories and one mediocre photo."""
from https://www.thehuntingphotographer.com/blog/qualityvsquantit...