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

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?

This was the reward for reading through.

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

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.

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

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.

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

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.

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

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.

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.

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.

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.

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.

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

(Like the author, of course, I'm massively hypocritical in this regard).

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.

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

At work though it's much faster to be more methodical writing software. Fewer QA headaches.