> If every time you write a blog post it takes you six months, and you're sitting around your apartment on a Sunday afternoon thinking of stuff to do, you're probably not going to think of starting a blog post, because it'll feel too expensive.
Author in 2025:
> This is why it’s so useful to work on an article for a long time. If you’re reporting on something for six months, even if the really concentrated part, the key visit, is only a week or two of that, you have time for notes to accumulate.
What a difference 10 years of experience makes eh?
I took this to mean, in the first case "I write an article every six months" and in the second "I work on each article for six months, but I work on multiple in parallel so I post them very frequently".
The first is being blocked/out of inspiration, the second is being meticulous.
But then the "blog post" in the old example and the "article" in the new one belong to a different type of artifact, right? It's a bit like the distinction between "programming in the small" and "programming in the large".
While belonging to the same medium and often done by the same people, they prioritize very different aspects.
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.
Funny how this exactly applies to instrument playing. Unearned speed only begets sloppiness. The only way to go past a certain velocity is to do meticulous metronome work from a perfectly manageable pace and build up with intention and synchrony. And even then it is not a linear increase, you will need to slow back down to integrate every now and then. (Stetina's "Speed Mechanics for Lead Guitar"; 8 bpm up, 4 bpm down)
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?
You're not always doing something groundbreaking. Sometimes you're just building a thing that needs to exist. People who build houses don't obsess over this shit, they just build a house and then someone moves into it.
I wage a constant battle of motivating myself because my neurology craves novel sources of dopamine but my job is doing the needful 90% of the time.
In my opinion author fails to make distinction between small tasks (atomic tasks) and complicated tasks. Also misses to mention 2 important concepts: flow state and friction.
For small tasks you should absolutely strive to remove any friction (examples: editor undo, dictionary lookup, make a note).
Complicated tasks (writing a blog post) are a different beast:
- needs to be broken down in small tasks
- while carving out small tasks needs finesse and fluency
- small tasks need to be frictionless
But, principal difference is you need to load your working memory (small but fast (RAM)) (e.g. read documentation, browse a repo, connect to your work from yesterday, ...). Loading your 'RAM' is an investment. And your ROI shrinks if you need to collect the threads from scratch again and again. So, IMO it's not about moving fast but moving uninterrupted. Moving uninterrupted produces flow state and gives you the impression of moving fast (despite your moving only slowly but steadily). Speed becomes irrelevant if you're moving steadily forward.
The blog post shows another problem if your working 'too long' on something: you need to reconnect from scratch to your original idea/intention, which might change. So your creation may become an incoherent medley, you begin to miss the forest for the trees, or worse: you begin to doubt yourself.
I like to think about the mind as an extensible limb that can extend in the direction of a distant goal, but can only span small distances. It's literally like the mind walking. Making steps too big is like moving trying not to touch the floor. It needs unreasonably more effort and is long-term exhausting. You may even break down and think you're a failure. But standing on one leg for too long is exhausting too.
You may laugh about the author who had this post 6 years in the making, but it's extremely important to work by a mental model that doesn't exhaust you, but works FOR you.
"I never understand anything until I have written about it."
– Horace Walpole
"If you’re thinking without writing, you only think you’re thinking."
– Leslie Lamport
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.
I think ideally you need to practice both slow AND fast. You need to practice slow so you can notice and work on small details that can be skipped over with speed, and you need to practice fast because some things are legitimately different at speed and you won't learn how to deal with them only going slow.
The folks who urge haste occasionally need to be reminded that there is nothing faster than doing it right the first time.
That said, finishing (not just working) quickly is very important. You will never get good if you do not finish a lot of things. If you need to iterate to a solution, you will never finish if you do not iterate quickly.
My corollary to "good, fast, cheap: pick two" is that there's no such thing as good, slow, and cheap, and if there were, it's booked for the next 30 years anyway.
As an aside, most of us, when watching a video of ourselves, may notice how slow our movements actually are. I had the subjective impression that I was fast and agile when practicing jiu jitsu, judo, or team sports, yet when I watched some of my videos, I couldn’t help but feel disappointed by how slow I appeared to move. The answer was to accept that what I subjectively perceived as fast was actually slow and thus trying to go faster, while not being sloppy or "spazzy".
Although we all know that too fast often means sloppy, if only because of the modifier too, our brains can easily deceive us into believing that we are fast when, in reality, we are moving at a glacial pace.
There is a clear parallel here with what happens when we trust our subjective experience too much instead of relying on objective assessments of ourselves and our skills, whether that means watching a video of ourselves in which we appear goofy or slow when we thought we were as elegant as Baryshnikov and as quick as Ma Long, or when we decide to measure ourselves against the best, and not the average/median competition, and realize how slow we are when operating.
Assuming that standards of quality or comprehension are maintained, it would do good for many, myself included, not to think in terms of "it will take as long as needed (to learn French, jiu jitsu, Python, violin)", but in terms of "how fast I can reach the goal?". And not because of some modern productivity bias, but for reason of speed in reaching the level we are aiming at: the faster we get there, the better our performance will be.
And certainly, many should have the goal of moving faster when doing sports (accounting for age, background, injuries, etc., but not excuses). Speed, more often than not, is the ultimate skill.
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 consideration reminds me of two other lines of research:
- Producing organisms with capable, healthy mitochondria requires mitonuclear compatibility (mitochondrial genome is from mother, nuclear genome is from both parents, energetic capacity and regulation requires both genomes to coordinate) and evidence is that organisms select highly for offspring that have higher mitonuclear compatibility and more capable mitochondria. Offspring that don't have capable enough mitochondria don't make it to term. For example, mammals are more permissive about mitonuclear compatibility than birds (who have extremely high energetic requirements) so mammals are more fecund, but we're also more likely to get cancer from inefficient mitochondria throwing off reactive oxygen species.
- Chris Palmer, a Harvard medical school MD psychiatrist, put out a book a few years ago hypothesizing most mental disorders as brain metabolic disorders — brain mitochondria problems. I've seen mixed reviews on the hypothesis (which I like) but it sure is interesting.
Taken together these imply: 1) some people get more energy than others at a biological level, 2) that impacts mental health, 3) there are interventions that can improve the energy baseline we each were given (as discussed in Palmer's book/talks).
Creatinine as a marker also indicates more abundant early-life nutrition, and subsequently a healthier starting environment and socioeconomic status.
That's a much better explainer of higher incomes than any kind of armchair biological determinism.
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.
> Part of the activation energy required to start any task comes from the picture you get in your head when you imagine doing it. It may not be that going for a run is actually costly; but if it feels costly, if the picture in your head looks like a slog, then you will need a bigger expenditure of will to lace up.
I have found AI to help me with overcoming that activation energy. I am re-learning to code, writing articles, learning aspects of marketing that I wanted to do, but it felt too hard. Having AI as a step by step tutor overcomes that activation energy for me.
I've gone in a bit of the opposite direction in that I've basically abandoned my phone and youtube and social media, and now... life is so silent a lot of times... that I just start doing things when I get tired of staring at the wall.
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.
Apropos of "Sprezzatura"; you will find plenty of worldly wisdom in The Pocket Oracle and the Art of Prudence by Baltasar Gracian translated by Jeremy Robbins.
Two aphorisms of relevance to this thread are;
-- Aphorism 174:
Don’t live in a hurry. To know how to parcel things out is to know how to enjoy them. With many people their happiness is all over with life still to spare. They waste happy moments, which they don’t enjoy, and then want to go back later when they find themselves so far down the road. They are life’s postilions, adding their own headlong rush to time’s inexorable march. They want to devour in a day what could barely be digested in a lifetime. They anticipate
every happiness, bolt down the years still to come, and since they’re always in such a rush, quickly finish everything. Moderation is necessary even in our desire for knowledge so as not to know things badly. There are more days than joys to fill them. Take enjoyment slowly and tasks quickly. It’s good when tasks are completed, but bad when happiness is over.
-- Aphorism 221:
Don’t be annoyingly impetuous – committing yourself or others. Some people are stumbling blocks to their own dignity and to someone else’s, and are always on the point of doing something stupid. You’ll come across them easily and get rid of them with difficulty. They don’t mind causing a hundred annoyances a day. They are quarrelsome by nature and so contradict everyone and everything. Their judgement is always back to front, and so they disapprove of everything. But the people who most try good sense are those who do nothing well and speak ill of everything. For there are many monsters in incongruity’s vast territory.
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.
I feel like this relates a bit to a quote from Kevin Smith (silent bob)
To paraphrase, you have to be a little bit delusional to think you will succeed, otherwise you won't get started. You won't make the big risky decisions that bring you to success.
Which I relate to a second thought of my own which is, what will I regret if I hadn't at least tried?
Which together, help motivate me to continue game development. There is just so much work to be done, and you have to just assume you'll be good and succeed at half a dozen different disciplines to bring it all together.
I very much agree. Doesn't need to be taken to extreme though.
BTW, for me this is the best use for AI: it's so much lower effort to type some sentences for AI to create a rough plan for me to engage with, and improve iteratively, then start implementing it, than doing this myself from scratch. Essentially anti-procrastination breaker.
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.
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.
During my freelancer-time one of the things my clients valued most was (A) my speed and (B) how precisely I could give them a timeline ahead of time and keep it (aside from the occasional client-induced change).
I am convinced you recognize real pros from their ability to tell you how long things will take (provided they know the details of the project of course). Beginners are struggling to even accomplish the task, so they can't give you any timeline.
I am aware that there are projects that are even hard to predict for the expert, especially if there are many moving parts and unknowns. But then the answer should be a pessimistic guess.
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.
I think, unfortunately, this is something which requires the development of good taste: the ability to distinguish good abstractions and clean implementations in advance of their creation, to direct it. There is little replacement of experience in this endeavour, and most time people spend learning to do software engineering pays no attention to it.
Intentional analysis of existing projects and developing your own new things is incredibly helpful for this, and the sort of development we recognise in the workplace we may recognise but fail to prioritise and reward appropriately.
As a long time HN reader, I'm well acquainted with this article and every time I read it again, I'm reminded of these 2 famous sayings, which seem amusing in this context:
1. "Do as the priest says not as he does"
2. "It is far easier for me to teach twenty what were right to be done, than be one of the twenty to follow mine own teaching."
So now that you know what must be done, go out and do it, if you can. If not, teach it to others.
I generally go very quickly when doing personal programming projects since I'm usually the only user of my software, but I always end up shooting myself in the foot and have to rewrite sloppy code, which ends up taking more time. Which is fine, since I have no timeline.
At work though it's much faster to be more methodical writing software. Fewer QA headaches.
This post reminds me of some cognitive biases: That you spend two years on a software project that you wrote from scratch and are now at an abstraction level where you can implement new major features in hours. You now look at popular apps and think that you could probably replicate them in a weekend or so.
An obvious corollary is that you must get yourself a fast computer to work on. Nothing more disincentivizing than the thought of VS Code taking 5 whole minutes before it's ready to go...
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.
Conversely, slowing down an adversarial email conversation can lead to better outcomes. A rapid or delayed response signals your position and priority on the topic.
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).
> I’ll add that there’s also a massive habits and culture problem with shipping slop that is very hard to eradicate later.
> It’s like a sports team, losing on purpose so they can get better draft picks for the next year. It rarely works well because that loser mentality infects the whole organization.
> You have to slow down, do it right, and then you can speed up with that foundation in place.
Slow, steady, progress can appear quick when the alternative is no progress at all. Or, alternatively: avoid "dead air".
I think I generally identify with what the article is saying - but I think it's more about responsiveness and predictability than pure speed. I've always been a pretty quick worker, but more importantly I've been responsive. It's better to reply back in 5 seconds with an "I don't know; you might want to talk to Susan about this instead" than to spend an hour researching on your own and give them the answer yourself. You can even say "If Susie is too busy, I can look into it myself, but it might take an hour or two".
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.
EdwardDiego|2 months ago
> If every time you write a blog post it takes you six months, and you're sitting around your apartment on a Sunday afternoon thinking of stuff to do, you're probably not going to think of starting a blog post, because it'll feel too expensive.
Author in 2025:
> This is why it’s so useful to work on an article for a long time. If you’re reporting on something for six months, even if the really concentrated part, the key visit, is only a week or two of that, you have time for notes to accumulate.
What a difference 10 years of experience makes eh?
stavros|2 months ago
The first is being blocked/out of inspiration, the second is being meticulous.
indigoabstract|2 months ago
https://news.ycombinator.com/item?id=46311092
I take this to mean: look at how others do it, find what works for you and then do that.
ostacke|2 months ago
falcor84|2 months ago
hakunin|2 months ago
acituan|2 months ago
marcosdumay|2 months ago
chairmansteve|2 months ago
dworks|2 months ago
N_Lens|2 months ago
tlb|2 months ago
agentultra|2 months ago
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?
onoesworkacct|2 months ago
I wage a constant battle of motivating myself because my neurology craves novel sources of dopamine but my job is doing the needful 90% of the time.
mlhpdx|2 months ago
This was the reward for reading through.
vikboyechko|2 months ago
nashadelic|2 months ago
nakedneuron|2 months ago
For small tasks you should absolutely strive to remove any friction (examples: editor undo, dictionary lookup, make a note).
Complicated tasks (writing a blog post) are a different beast: - needs to be broken down in small tasks - while carving out small tasks needs finesse and fluency - small tasks need to be frictionless
But, principal difference is you need to load your working memory (small but fast (RAM)) (e.g. read documentation, browse a repo, connect to your work from yesterday, ...). Loading your 'RAM' is an investment. And your ROI shrinks if you need to collect the threads from scratch again and again. So, IMO it's not about moving fast but moving uninterrupted. Moving uninterrupted produces flow state and gives you the impression of moving fast (despite your moving only slowly but steadily). Speed becomes irrelevant if you're moving steadily forward.
The blog post shows another problem if your working 'too long' on something: you need to reconnect from scratch to your original idea/intention, which might change. So your creation may become an incoherent medley, you begin to miss the forest for the trees, or worse: you begin to doubt yourself.
I like to think about the mind as an extensible limb that can extend in the direction of a distant goal, but can only span small distances. It's literally like the mind walking. Making steps too big is like moving trying not to touch the floor. It needs unreasonably more effort and is long-term exhausting. You may even break down and think you're a failure. But standing on one leg for too long is exhausting too.
You may laugh about the author who had this post 6 years in the making, but it's extremely important to work by a mental model that doesn't exhaust you, but works FOR you.
"I never understand anything until I have written about it." – Horace Walpole
"If you’re thinking without writing, you only think you’re thinking." – Leslie Lamport
taeric|2 months ago
Turskarama|2 months ago
Swizec|2 months ago
cwnyth|2 months ago
buescher|2 months ago
That said, finishing (not just working) quickly is very important. You will never get good if you do not finish a lot of things. If you need to iterate to a solution, you will never finish if you do not iterate quickly.
My corollary to "good, fast, cheap: pick two" is that there's no such thing as good, slow, and cheap, and if there were, it's booked for the next 30 years anyway.
cainxinth|2 months ago
Hence the military axiom: “Slow is smooth, smooth is fast.”
anticorporate|2 months ago
Many of us have noticed this; it's why we're intentionally slow to respond.
borroka|2 months ago
Although we all know that too fast often means sloppy, if only because of the modifier too, our brains can easily deceive us into believing that we are fast when, in reality, we are moving at a glacial pace.
There is a clear parallel here with what happens when we trust our subjective experience too much instead of relying on objective assessments of ourselves and our skills, whether that means watching a video of ourselves in which we appear goofy or slow when we thought we were as elegant as Baryshnikov and as quick as Ma Long, or when we decide to measure ourselves against the best, and not the average/median competition, and realize how slow we are when operating.
Assuming that standards of quality or comprehension are maintained, it would do good for many, myself included, not to think in terms of "it will take as long as needed (to learn French, jiu jitsu, Python, violin)", but in terms of "how fast I can reach the goal?". And not because of some modern productivity bias, but for reason of speed in reaching the level we are aiming at: the faster we get there, the better our performance will be.
And certainly, many should have the goal of moving faster when doing sports (accounting for age, background, injuries, etc., but not excuses). Speed, more often than not, is the ultimate skill.
N_Lens|2 months ago
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.
code_biologist|2 months ago
- Producing organisms with capable, healthy mitochondria requires mitonuclear compatibility (mitochondrial genome is from mother, nuclear genome is from both parents, energetic capacity and regulation requires both genomes to coordinate) and evidence is that organisms select highly for offspring that have higher mitonuclear compatibility and more capable mitochondria. Offspring that don't have capable enough mitochondria don't make it to term. For example, mammals are more permissive about mitonuclear compatibility than birds (who have extremely high energetic requirements) so mammals are more fecund, but we're also more likely to get cancer from inefficient mitochondria throwing off reactive oxygen species.
- Chris Palmer, a Harvard medical school MD psychiatrist, put out a book a few years ago hypothesizing most mental disorders as brain metabolic disorders — brain mitochondria problems. I've seen mixed reviews on the hypothesis (which I like) but it sure is interesting.
Taken together these imply: 1) some people get more energy than others at a biological level, 2) that impacts mental health, 3) there are interventions that can improve the energy baseline we each were given (as discussed in Palmer's book/talks).
dartharva|2 months ago
mitchbob|2 months ago
https://news.ycombinator.com/item?id=20611539
jon-wood|2 months ago
I have no pithy summary of how this applies to the world of business or software development. It just reminded me of that.
reactordev|2 months ago
wek|2 months ago
I have found AI to help me with overcoming that activation energy. I am re-learning to code, writing articles, learning aspects of marketing that I wanted to do, but it felt too hard. Having AI as a step by step tutor overcomes that activation energy for me.
codyb|2 months ago
Brajeshwar|2 months ago
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/
rramadass|2 months ago
Two aphorisms of relevance to this thread are;
-- Aphorism 174:
Don’t live in a hurry. To know how to parcel things out is to know how to enjoy them. With many people their happiness is all over with life still to spare. They waste happy moments, which they don’t enjoy, and then want to go back later when they find themselves so far down the road. They are life’s postilions, adding their own headlong rush to time’s inexorable march. They want to devour in a day what could barely be digested in a lifetime. They anticipate every happiness, bolt down the years still to come, and since they’re always in such a rush, quickly finish everything. Moderation is necessary even in our desire for knowledge so as not to know things badly. There are more days than joys to fill them. Take enjoyment slowly and tasks quickly. It’s good when tasks are completed, but bad when happiness is over.
-- Aphorism 221:
Don’t be annoyingly impetuous – committing yourself or others. Some people are stumbling blocks to their own dignity and to someone else’s, and are always on the point of doing something stupid. You’ll come across them easily and get rid of them with difficulty. They don’t mind causing a hundred annoyances a day. They are quarrelsome by nature and so contradict everyone and everything. Their judgement is always back to front, and so they disapprove of everything. But the people who most try good sense are those who do nothing well and speak ill of everything. For there are many monsters in incongruity’s vast territory.
keithnz|2 months ago
ivw|2 months ago
An alternative solution is to grossly underestimate the amount of work
code_biologist|2 months ago
sebmellen|2 months ago
> What if laziness is just a habit of thinking about the work instead of the payoff?
ehnto|2 months ago
To paraphrase, you have to be a little bit delusional to think you will succeed, otherwise you won't get started. You won't make the big risky decisions that bring you to success.
Which I relate to a second thought of my own which is, what will I regret if I hadn't at least tried?
Which together, help motivate me to continue game development. There is just so much work to be done, and you have to just assume you'll be good and succeed at half a dozen different disciplines to bring it all together.
daniel_grady|2 months ago
KptMarchewa|2 months ago
BTW, for me this is the best use for AI: it's so much lower effort to type some sentences for AI to create a rough plan for me to engage with, and improve iteratively, then start implementing it, than doing this myself from scratch. Essentially anti-procrastination breaker.
nine_k|2 months ago
chrisweekly|2 months ago
0xCE0|2 months ago
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.
atoav|2 months ago
I am convinced you recognize real pros from their ability to tell you how long things will take (provided they know the details of the project of course). Beginners are struggling to even accomplish the task, so they can't give you any timeline.
I am aware that there are projects that are even hard to predict for the expert, especially if there are many moving parts and unknowns. But then the answer should be a pessimistic guess.
austin-cheney|2 months ago
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.
egwor|2 months ago
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.
etherus|2 months ago
indigoabstract|2 months ago
1. "Do as the priest says not as he does"
2. "It is far easier for me to teach twenty what were right to be done, than be one of the twenty to follow mine own teaching."
So now that you know what must be done, go out and do it, if you can. If not, teach it to others.
65|2 months ago
At work though it's much faster to be more methodical writing software. Fewer QA headaches.
hardlianotion|2 months ago
z3t4|2 months ago
unknown|2 months ago
[deleted]
jdthedisciple|2 months ago
ponker|2 months ago
cromulent|2 months ago
danielovichdk|2 months ago
The latter is not working fast, it's learning.
jkaptur|2 months ago
(Like the author, of course, I'm massively hypocritical in this regard).
roncesvalles|2 months ago
And why exactly is this desirable?
charlie0|2 months ago
vonnik|2 months ago
horizion2025|2 months ago
But the screenshot says the md file was created in 2009, so that would be 16 years?
delifue|2 months ago
The first is what to optimize. The second "being pushed to work faster" often produce bad results.
https://x.com/jamonholmgren/status/1994816282781519888
> I’ll add that there’s also a massive habits and culture problem with shipping slop that is very hard to eradicate later.
> It’s like a sports team, losing on purpose so they can get better draft picks for the next year. It rarely works well because that loser mentality infects the whole organization.
> You have to slow down, do it right, and then you can speed up with that foundation in place.
nottorp|2 months ago
bilater|2 months ago
brudgers|2 months ago
QuercusMax|2 months ago
I think I generally identify with what the article is saying - but I think it's more about responsiveness and predictability than pure speed. I've always been a pretty quick worker, but more importantly I've been responsive. It's better to reply back in 5 seconds with an "I don't know; you might want to talk to Susan about this instead" than to spend an hour researching on your own and give them the answer yourself. You can even say "If Susie is too busy, I can look into it myself, but it might take an hour or two".
Communicate, communicate, communicate.
khana|2 months ago
[deleted]
lordkrandel|2 months ago
dexwiz|2 months ago
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.
xtajv|2 months ago
4er_transform|2 months ago
If we’re all just particles and fields, we might as well be as thermodynamically productive as possible