Speed matters (2021)

This is one of those instances where I’m simply baffled after reading the first few paragraphs and have to express that immediately.

The author did the same thing twice and he didn’t consider as the most important factor that the second time around he already knew how to do it?

He trimmed down the infinite space of possibilities to a single solution and learned the lessons? And had the neurons connected already in his head?

That’s what made him faster. There was a lot of work that he didn’t need to do anymore. Learning always takes time.

Maybe it’s an overreaction to a blog post, but still…

I agree with this article, however I think it misses the most valuable aspect of speed: compounded returns on experience.

Experience isn't 1:1 with time spent. It's easy to spend a lot of time on something but learn very little. Conversely, its possible to gain a large amount of experience in a short period of time.

By being able to develop faster, you become able to accumulate more experience in a smaller amount of time. This experience then enables you to develop faster, kicking off a virtuous cycle of growth.

Following this thought provides clarity on what action you should take immediately: do anything as long as its something. Through doing something, you will become more experienced and that experience will enable you to do something else even faster.

This is why you end up with so many aphorism in the industry promoting rapid action over inaction:

- Move fast and break things

- Worse is better

- Fail fast

- Hacker mentality

- "Action oriented"

See also: https://danluu.com/productivity-velocity/ and https://patrickcollison.com/fast

Impatience is one of those selfish virtues.

Most of everything in the article is about the speed at which a human moves.

This is not about the machine, but it is indirectly about it - if I hit a sub-optimal build step, I will spend time speeding it up because the difference between a 45s build and a 90s build is that I will start typing a comment on HN instead of seeing if it worked.

In the real world, usually faster is better, because the world we operate in keeps changing - the decisions you made have a shelf life and your execution speed limits how often you deliver what is right or what would have been great six months ago.

So, I do everything in my power so that I can do things faster.

Lastly, I only have a fixed number of hours left on the planet - going faster is better than going longer at a task, because my goal is not to work 8 hours & go home, it is to finish my work and get back to my life.

Oddly enough, sometimes going faster can look paradoxical. I work only about 6 hours a day, but they are placed in such a way that I am at maximum velocity & flow during those hours.

I cannot keep that up beyond a couple of hours, so I work 10 AM to 12, eat a long lunch & get back to work at 2. Work from 2 through 4, go chase kids from 4:30 to about 9:30 PM. Work another 2 hours from 9:30 to 11:30, to be in bed fast asleep before midnight.

This means the hours I work are the fastest times of my day, while about 3 days a week 9 AM to 10, I am at a coffee shop reading a book.

I might be finishing lunch & then playing pool from 1 to 2 PM, so it does look to a lot of people that I am moving in a leisurely speed at work, but the only speed that matters is when you actually sit down and start thinking/typing.

On the way, whatever tool or processes I use that are slow or repetitive gets improved or automated, because again I want to be done at 4:30 before my brain goes into "driving in traffic" readiness.

The "make sharp tools" is a side-effect, not the core process which drives productivity.

> Another common objection is that any given tweak to the work process might only be a tiny improvement in speed. But little tweaks are cheap and they add up over time. … If you can find a 0.1% improvement each day, that adds up to getting 2x faster every two years (1.001^(365*2) == 2.07).

Little tweaks are also not cheap - they’re cheap to write but a) you have to run a potentially expensive test suite / add more tests to verify you haven’t broken anything b) you have to understand and measure the problem in the first place which itself could easily take days. So actually, after those 2 years you’ve probably only landed a 1.6x improvement (1.001^5 days/week * 50 weeks/year * 2 years). Oh and your 0.1% improvement could be a win in 1 use case but a loss in others so your 1.6x improvement in one narrow benchmark could end up being a 3x slowdown in a different benchmark.

It’s basically impossible to find a pure 0.1% improvement every single day non stop for 2 years. It might amortize to that and it also depends on the maturity of the codebase (e.g. a rearchitecture might cost less and deliver more gains).

I agree fully. Speed matters. Too many people consider CPU time too cheap to consider. I still marvel at how fast and efficient could Symbian OS be on a 190 MHz Nokia. (Though the API was hell.)

That said, it is also true that premature optimization is the root of all evil.

I suspect programming wisdom hides somewhere in between those two hills, neither of which is worth dying on.

Discussed at the time:

Speed Matters - https://news.ycombinator.com/item?id=28879240 - Oct 2021 (159 comments)

What I am starting to internalize nowadays is that working faster is useful, but what can really change one's life is learning faster.

Planet. Gun. Always has.