Why Speed Matters
lemire.me
lemire.me
"""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...
If you make the same pot 100 times that 100th pot is your best one.
I'd love to know if either are real and verifiable.
The lesson is most likely real and applicable either way.
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?
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.”
“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.")
~
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.
Where's the evidence of improvement?
Maybe it's just a bigger sample, so more chance that some will be good shots?
Does the blogger mean something different than "Plan to throw one away - you will anyway. "
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
It's like people reading Radical Candor (which I quite like) and concluding that being an asshole is ok.
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.
Indiscriminately espousing raw speed for every step is a perfect recipe for burnout.
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.
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.
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.
You presumably mean prioritizing development speed, which is essentially the opposite.
Rather than building on a shaky base, rushing, and getting stuck after a while.
I think there is an Aesop fable for it?
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.
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.
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.
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
(Including the cancelled interventions when the surgeon recognized that surgery was not required.)
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.
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.
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.
https://dictionary.cambridge.org/us/grammar/british-grammar/...
(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'.
(Obviously this advice can easily go horribly wrong in the hands of incompetent leadership, context matters, etc)
Don't add them to current development; add them to future development.
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.