Speed matters (2021)
(scattered-thoughts.net)65 points by mefengl 5 days ago
65 points by mefengl 5 days ago
> he didn’t consider as the most important factor that the second time around he already knew how to do it
How'd you get that idea? Being faster because of something you "already know how to do" is like half the point of the post. The author even includes an anecdote that serves as an extreme example about how slow they were at working out code when they first started programming because they had to stop and think about loops.
It would be one thing if he'd written a post that includes the first few paragraphs here about writing <this> utility and then later writing <that> utility, then concluded, "… and that's why language X is better than language Y" or something. But he didn't. Which leaves me baffled by your comment.
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.
> my goal is not to work 8 hours & go home, it is to finish my work and get back to my life.
I am always wondering why people don't consider work as part of their lifes. It always has been. People always worked. Back in the day they went hunting all day to not die. Now we write code to not die. So what's the difference? Work and life have the same meaning to me
It is because there is a disassociation between earning money and living. You eat what you hunt, you eat what you farm, you live the house you build, you trade your crops for other crops.
Today we work for money and spend money to live, the two are linked but also disassociated. I find it that the most successful people are the ones who find joy in seeing "number go up" (money go up) as their work and life. The people who want to use money are the ones who find the least joy in getting more of it.
I imagine it's because a lot of people work with things they don't like.
In many cases it's just an unfortunate reality of poverty. In some cases this is because of bad life choices making people choose ever more expensive life-styles that require ever more money-focused job choices.
> 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).
Discussed at the time:
Speed Matters - https://news.ycombinator.com/item?id=28879240 - Oct 2021 (159 comments)
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.
Well the article is about speed of development, not the speed at which the code runs.
Over the years I’ve come to embrace moving fast and writing code quickly, even if it’s not the fastest. The faster I get the big things done, the more time I can spend optimizing what matters after I’ve identified it and determined it’s valuable.
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…