"""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."""
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.
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.
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.
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.
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.
Think 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?
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.
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.
Sometimes the perception of speed is just as important as actual speed. No I'm not bitter, why do you ask?
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.
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.
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.
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
>>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.
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.
expected this to be about cpu cycles, given the author's works :D
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)
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.
>> 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.
Yeah, he should also define "you". Is he talking about me, you or himself?
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'.
Reminds me of this:
"""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...
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.
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.
Oh there you go, that's what I was talking about https://news.ycombinator.com/item?id=46174424
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.
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.
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.
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.
Think 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?
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.
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.
Sometimes the perception of speed is just as important as actual speed. No I'm not bitter, why do you ask?
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.
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.
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.
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
>>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.
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.
expected this to be about cpu cycles, given the author's works :D
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)
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.
>> 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.
Yeah, he should also define "you". Is he talking about me, you or himself?
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'.