[HN Gopher] Why Speed Matters
___________________________________________________________________
Why Speed Matters
Author : gsky
Score : 110 points
Date : 2025-12-06 12:46 UTC (10 hours ago)
(HTM) web link (lemire.me)
(TXT) w3m dump (lemire.me)
| paulryanrogers wrote:
| 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.
| hylaride wrote:
| 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 cliche 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.
| okr wrote:
| 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.
| hansvm wrote:
| 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.
| jakozaur wrote:
| It is even more true with startups and business. Super rushed is
| bad, but doing for too long decreases quality.
| thunderbong wrote:
| Moving fast should not mean reducing quality.
| tmtvl wrote:
| 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.
| toss1 wrote:
| >>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.
| wongarsu wrote:
| 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
| igouy wrote:
| Wrong criteria. Evaluate the number of successful outcomes!
|
| (Including the cancelled interventions when the surgeon
| recognized that surgery was not required.)
| wavemode wrote:
| 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.
| zkmon wrote:
| >> 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.
| not-so-darkstar wrote:
| Yeah, he should also define "you". Is he talking about me, you
| or himself?
| igouy wrote:
| "We can use one, you, we and they to refer to 'people in
| general'."
|
| https://dictionary.cambridge.org/us/grammar/british-
| grammar/...
| igouy wrote:
| 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.
| vanschelven wrote:
| 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...
| gus_massa wrote:
| 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...
| kimos wrote:
| Yeah I'm pretty sure this was about pottery.
|
| If you make the same pot 100 times that 100th pot is your
| best one.
| neogodless wrote:
| 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.
| Kye wrote:
| 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.
| brandall10 wrote:
| 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."
| ekjhgkejhgk wrote:
| Oh there you go, that's what I was talking about
| https://news.ycombinator.com/item?id=46174424
| igouy wrote:
| 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. "
| igouy wrote:
| > ... 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.
| ~
|
| Presumably the "quality" group were free to produce as many
| photos as they wished.
|
| 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.
| andrewrn wrote:
| 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.
| photochemsyn wrote:
| 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'.
| charlie0 wrote:
| 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.
| dasil003 wrote:
| 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)
| Herring wrote:
| Sometimes the perception of speed is just as important as actual
| speed. No I'm not bitter, why do you ask?
| leeoniya wrote:
| expected this to be about cpu cycles, given the author's works :D
| GMoromisato wrote:
| 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.
| rubatuga wrote:
| 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.
| ekjhgkejhgk wrote:
| 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.
| aatd86 wrote:
| 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?
| jandrewrogers wrote:
| 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.
| MaxBarraclough wrote:
| > optimizing for speed
|
| You presumably mean _prioritizing development speed_ , which is
| essentially the opposite.
| RaftPeople wrote:
| > _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.
| cellis wrote:
| Reminded me of this: https://jsomers.net/blog/speed-matters
| morgengold wrote:
| The real skill is to know when speed is the way to go and when
| taking your time is the better strategy.
| OptionOfT wrote:
| 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.
___________________________________________________________________
(page generated 2025-12-06 23:02 UTC)