> 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:
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).
I second this. Time spend is Pareto distributed, and you spend most of your time doing something because you don't know something. Research, homework, coding, you spend the most time caught in a loop for something you don't know.
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.
That's an interesting point as well, but the entire article seems to me to be focused on programmer speed rather than program speed. What about it spoke to the latter rather than the former for you?
Specifically the SQLite release statement. Quite recently, I did the same in my code, fishing for many micro-optimizations that sped up the execution by 1 per cent or so. These added up nicely.
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.
On the other hand, some of the biggest performance wins come from the architectural choices, and those are often done before most of the code is written.
Writing for PHP, I used to spend a lot of time waiting for Xdebug to trigger. Once the author released version 3.3, the improvement was so big that my own productivity went visibly up.
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…
> 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 found the train station 10X faster than the first time. (The first time I got lost)
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
Yes; failures generate data. But you need devs who can understand why something fails....
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.
It's because when you're working for an employer, you're doing what someone else wants. Living my life means doing what I want.
Pretty much this...
> 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)
What I am starting to internalize nowadays is that working faster is useful, but what can really change one's life is learning faster.
I second this. Time spend is Pareto distributed, and you spend most of your time doing something because you don't know something. Research, homework, coding, you spend the most time caught in a loop for something you don't know.
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.
That's an interesting point as well, but the entire article seems to me to be focused on programmer speed rather than program speed. What about it spoke to the latter rather than the former for you?
Specifically the SQLite release statement. Quite recently, I did the same in my code, fishing for many micro-optimizations that sped up the execution by 1 per cent or so. These added up nicely.
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.
On the other hand, some of the biggest performance wins come from the architectural choices, and those are often done before most of the code is written.
Yep, same experience. "Some of the biggest performance wins" in both developer speed and processing speed.
There is an overlap.
Writing for PHP, I used to spend a lot of time waiting for Xdebug to trigger. Once the author released version 3.3, the improvement was so big that my own productivity went visibly up.
> premature optimization is the root of all evil.
Yeah, we should forget about small efficiencies, say about 97% of the time. Yet we should not pass up our opportunities in that critical 3%.
Yeah be data driven and optimize the hot data path, the other code paths optimize for simplicity (and the majority of a system is the latter)
Planet. Gun. Always has.