HN Reader

Author in 2015:

> 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 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.

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

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?

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

> As for writing, well, I have been working on this little blog post, on and off, no joke, for six years.

This was the reward for reading through.

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.

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 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.

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.

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.

(2015). Previous discussion (172 comments):

https://news.ycombinator.com/item?id=20611539

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.

> 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 noticed that if I respond to people's emails quickly, they send me more emails.

Many of us have noticed this; it's why we're intentionally slow to respond.

The thesis is interesting and convincing, but the article is beautifully delivered with a wry touch of paradox to humanise it.

Slowly, but hurry, is my take.

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.

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.

1. https://brajeshwar.com/2025/slow-is-smooth-smooth-is-fast/

2. https://brajeshwar.com/2026/sprezzatura/

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.

> if the picture in your head looks like a slog, then you will need a bigger expenditure of will to lace up

An alternative solution is to grossly underestimate the amount of work

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.

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.

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.

BuSab would like to have a word with you.

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.

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...

> . As for writing, well, I have been working on this little blog post, on and off, no joke, for six years.

But the screenshot says the md file was created in 2009, so that would be 16 years?

Wow I was excited to see the TextMate icon in the screenshot at the end. Good memories.

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.

"Working" is doing the important work in "working quickly."

There is nuance distinction between "fundamentally work faster" and "being pushed to work faster".

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.

I'm not convinced. This strikes me as a work harder, not smarter. Good judgment is required here.

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).

There is no "work quickly" without a previous period of either slow thought or "I have no clue what I am doing".

The latter is not working fast, it's learning.

The easiest way to do something is the first time.

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.

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.

I like how this is trending with another post called 'Slowness is a Virtue'

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!