[HN Gopher] Speed matters (2021)
___________________________________________________________________
Speed matters (2021)
Author : mefengl
Score : 62 points
Date : 2025-02-16 08:20 UTC (4 days ago)
(HTM) web link (www.scattered-thoughts.net)
(TXT) w3m dump (www.scattered-thoughts.net)
| inglor_cz wrote:
| 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.
| rockwotj wrote:
| 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)
| hansvm wrote:
| 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?
| inglor_cz wrote:
| 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.
| Aurornis wrote:
| 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.
| inglor_cz wrote:
| 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.
| branko_d wrote:
| 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.
| whstl wrote:
| Yep, same experience. "Some of the biggest performance
| wins" in both developer speed and processing speed.
| tmtvl wrote:
| > _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%.
| vlovich123 wrote:
| > 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).
| gopalv wrote:
| 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.
| dailykoder wrote:
| > 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
| procaryote wrote:
| 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.
| DanielHB wrote:
| 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.
| Timwi wrote:
| 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.
| I_dream_of_Geni wrote:
| Pretty much this...
| dang wrote:
| Discussed at the time:
|
| _Speed Matters_ - https://news.ycombinator.com/item?id=28879240
| - Oct 2021 (159 comments)
| aqueueaqueue wrote:
| Planet. Gun. Always has.
| kubb wrote:
| 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...
| keybored wrote:
| I found the train station 10X faster than the first time. (The
| first time I got lost)
| cxr wrote:
| > 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.
| nadam wrote:
| What I am starting to internalize nowadays is that working faster
| is useful, but what can really change one's life is _learning_
| faster.
| InkCanon wrote:
| 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.
| acegod wrote:
| 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
| osullivj wrote:
| Yes; failures generate data. But you need devs who can
| understand why something fails....
___________________________________________________________________
(page generated 2025-02-20 23:02 UTC)