Aaahahaha I've never seen a more toxic advice. Go faster! The world will be more alive! It's like putting yourself on cocaine. Grow expectations from you into people, that you'll never be able to sustain! Burn yourself on the altar of productivity! People will like you more at work! When you will die you will be remembered as the fastest guy in the office! The one who made a lot of mistakes but kept the company afloat by doing so much unpaid overwork that capital could flow free to the owner of the business! For no gain than self validation!
I used to share a similar sentiment about speed, especially after having burned out hard around 30. But after recovering, I think I may have overcorrected. Momentum is very powerful, and it's hard to gain momentum at low speed.
Speed is important but going fast doesn't mean going as fast as possible. It's about going fast sustainably. Work speed isn't binary. You can be fast without being the fastest.
Who says that burning more fuel is a good goal? Productivity is a tool for people in charge to make you feel like you lack something and you have to burn to be valued. Get some therapy instead: all that stuff is toxic and unneeded. Feel free to burn your lives to capitalism and big tech, for no gain
You have to look a level deeper. Life has always been productive, it’s the only way you maintain negative entropy and thus life itself. If you found a species that stopped being biologically productive, you would recognize that as a maladaptive deviation from the norm (and that species would quickly go extinct).
You should work hard to be productive for humanity, not owners, who themselves are also subject to their own biological drives and pressures that channel them just like these same drives channel others.
If you feel exploited, then be productive in ways that circumvent your exploitation. Working hard and being productive is far older and more fundamental that capitalism though, and for your own sake and humanity’s sake you should embrace it.
Your definition of good doesn't apply to me. The more "productive ways" are to me, actually non-factive. Like, contemplation, art for art sake, playing, meditating. And this comes from reduced time spent on producing material things. So going faster and doing more to me is a dis-value. Life is not measured with negative entropy. Life is not measured, not quantitative.
Another point is that the world is always changing. If you work slowly, you are at much greater risk of having an end result that isn't useful anymore.
(Like the author, of course, I'm massively hypocritical in this regard).
Executing fast is important, but practice slowly. It is frustrating as heck to admit it, but forcing your body to do something slowly is very effective at learning to do it at speed.
This is something I’ve been learning in the completely different context of bouldering since I took it up a few months ago. When you start out you instinctively move slowly, so you can be sure of your footing and won’t fall off, but somewhat counterintuitively it’s better to move as quickly as you can. This has two advantages - firstly the quicker you move the less time you’re on the wall, and the less energy it takes, just staying in place takes energy when you’re dangling off a wall by your fingertips. Secondly you can use momentum to your advantage, instead of stopping and then having to get yourself going every move you just bounce from hold to hold.
I have no pithy summary of how this applies to the world of business or software development. It just reminded me of that.
This is along the lines of "If it hurts, do it more often.” Where the general idea is that you will work out ways to make it not hurt if you regularly have to do something.
However, you must be aware that speed is an outcome, not a strategy. Speed for the sake of speed is often extremely slow and wastes months or years, and billions in investment: https://dilemmaworks.com/on-china-speed
It works somewhat better at the national level than the company level. By encouraging companies to move fast, some will fail but the employees will have gained experience that gets carried into other companies in the industry. At the company level billions were wasted, but at the national level billions were invested in practical on-the-job training.
When it comes to programming I find speed is of dubious value.
It comes when you already know what you’re doing. Which, if you’re an engineer, you should know what you’re doing according to Hamming.
But then you may not be tackling innovative or interesting problems. Much of software development is research: understanding customers, patterns, systems and so on. You do not know what you are doing, it’s more akin to science.
Then in order to go fast you must sacrifice something. Most people lose the ability to spot details or consider edge cases. They make fast and loose assumptions. And these trade offs blow up much later when the system experiences pressure.
It’s good to iterate and throw out bad ideas quickly for sure. You just have to know what area you’re in. Are you at the stage where you’re an engineer or are you doing more science related work?
Time to the result is important, not speed of working. Thinking hard, getting enough (and more than enough) information before committing to work may be more important, because this allows to do a better work, and less of it. Which brings the end result faster.
I like to say that you can either learn to be fast at doing low quality work, or learn to be fast at doing high quality work. It’s your choice really. But the only way to learn the latter is to start by prioritizing quality over speed.
This article reminds me of an old longitudinal study that analyzed various metabolites from people and found that those with higher creatinine levels in urine early in life had overall higher income across their life. Creatinine as a marker indicates energy production and expenditure, and higher creatinine levels are correlated with higher energy levels.
Now I'm not arguing for biological determinism, but atleast some of the working style individuals have comes down to individual bio-psycho-social factors. Many people here have ADHD or other neurodivergence and will struggle with any kind of prescriptive - 'just work faster outputting higher quality work'. If only it were that easy.
This is cliché, but I really liked, “Slow is Smooth, Smooth is Fast.”[1] I keep saying this to my daughters. Sometimes, when I asked them to “do it faster,” they would respond with “What happened to Slow is Smooth?”
I’ve explained a few times that the idea is to practice deliberately, slowly, and take time to learn things, so when you do it next, you can do it smoothly and become faster.
That saying about ducks gliding across the water in perfect calm, while beneath the surface, their feet work furiously, unseen. Yesterday, I stumbled upon the terminology, in Italian, Sprezzatura.[2] Do difficult things while making it appear effortless, the art of making something difficult look easy, or maintaining a nonchalant demeanor while performing complex tasks.
To do Sprezzatura, one has to Slow is Smooth, Smooth is Fast.
This is one thing I definitely find with AI coding. I'm building all kinds of software not that I couldn't have built before, but I couldn't justify the effort before.
The article fails to explore that accomplishing more is orthogonal to working quickly. That distinction is the greatest difference between typical developers and top tier developers.
More still is that most developers fail to measure things and thus are incapable of distinguishing between faster work versus increased accomplishment. As a result many developers strive to accomplish tasks more frequently without ever recognizing that perhaps many of those efforts are completely unnecessary.
Your point was thought provoking.
In problem solving the "what" and the "how" are orthogonal since the method doesn't dictate the goal. However, if it takes a long time to do something (how: working slowly eg. because you're coding on a very slow, old machine) it tends to predict that there's less accomplished (what). That suggests that this isn't 'fully' orthogonal.
Someone else raised a good point that if we're working on the wrong thing, it doesn't matter how fast we are. However, I think a more subtle interpretation is more helpful here. I think that we need to be clearer about the consequences of the outcomes: what's the value add. The way I often reason about that is whether the outcome is 'Long-term greedy' or whether the outcome is going to make us a million dollars now. I find the latter really helpful, because if we're going to make a million dollars now but it costs us 100K in tech debt, then (provided there's not a better use of the resources) that is likely a good cost-benefit outcome.
Quality vs quantity of course depends on the nature of work. If you are employee and all the working infrastructure is ready there to be used, you can "just" focus on doing something, what ever it is. If you are employer, you can't "just" even go to the work, because you have to use unpredicted amount of time to figure out what you even need to do or have and why.
Whether you are employee or employer, make sure you feel the practical progress, that is, e.g. once a week you can have status session, where you can show that now you have something that you didn't have at last session, and that it is important step for the end goal.
56 comments
[ 4.9 ms ] story [ 76.0 ms ] threadSpeed is important but going fast doesn't mean going as fast as possible. It's about going fast sustainably. Work speed isn't binary. You can be fast without being the fastest.
If we’re all just particles and fields, we might as well be as thermodynamically productive as possible
You should work hard to be productive for humanity, not owners, who themselves are also subject to their own biological drives and pressures that channel them just like these same drives channel others.
If you feel exploited, then be productive in ways that circumvent your exploitation. Working hard and being productive is far older and more fundamental that capitalism though, and for your own sake and humanity’s sake you should embrace it.
This was the reward for reading through.
(Like the author, of course, I'm massively hypocritical in this regard).
https://news.ycombinator.com/item?id=20611539
I have no pithy summary of how this applies to the world of business or software development. It just reminded me of that.
It comes when you already know what you’re doing. Which, if you’re an engineer, you should know what you’re doing according to Hamming.
But then you may not be tackling innovative or interesting problems. Much of software development is research: understanding customers, patterns, systems and so on. You do not know what you are doing, it’s more akin to science.
Then in order to go fast you must sacrifice something. Most people lose the ability to spot details or consider edge cases. They make fast and loose assumptions. And these trade offs blow up much later when the system experiences pressure.
It’s good to iterate and throw out bad ideas quickly for sure. You just have to know what area you’re in. Are you at the stage where you’re an engineer or are you doing more science related work?
Now I'm not arguing for biological determinism, but atleast some of the working style individuals have comes down to individual bio-psycho-social factors. Many people here have ADHD or other neurodivergence and will struggle with any kind of prescriptive - 'just work faster outputting higher quality work'. If only it were that easy.
I’ve explained a few times that the idea is to practice deliberately, slowly, and take time to learn things, so when you do it next, you can do it smoothly and become faster.
That saying about ducks gliding across the water in perfect calm, while beneath the surface, their feet work furiously, unseen. Yesterday, I stumbled upon the terminology, in Italian, Sprezzatura.[2] Do difficult things while making it appear effortless, the art of making something difficult look easy, or maintaining a nonchalant demeanor while performing complex tasks.
To do Sprezzatura, one has to Slow is Smooth, Smooth is Fast.
1. https://brajeshwar.com/2025/slow-is-smooth-smooth-is-fast/
2. https://brajeshwar.com/2026/sprezzatura/
An alternative solution is to grossly underestimate the amount of work
But the screenshot says the md file was created in 2009, so that would be 16 years?
More still is that most developers fail to measure things and thus are incapable of distinguishing between faster work versus increased accomplishment. As a result many developers strive to accomplish tasks more frequently without ever recognizing that perhaps many of those efforts are completely unnecessary.
Someone else raised a good point that if we're working on the wrong thing, it doesn't matter how fast we are. However, I think a more subtle interpretation is more helpful here. I think that we need to be clearer about the consequences of the outcomes: what's the value add. The way I often reason about that is whether the outcome is 'Long-term greedy' or whether the outcome is going to make us a million dollars now. I find the latter really helpful, because if we're going to make a million dollars now but it costs us 100K in tech debt, then (provided there's not a better use of the resources) that is likely a good cost-benefit outcome.
Quality vs quantity of course depends on the nature of work. If you are employee and all the working infrastructure is ready there to be used, you can "just" focus on doing something, what ever it is. If you are employer, you can't "just" even go to the work, because you have to use unpredicted amount of time to figure out what you even need to do or have and why.
Whether you are employee or employer, make sure you feel the practical progress, that is, e.g. once a week you can have status session, where you can show that now you have something that you didn't have at last session, and that it is important step for the end goal.