> 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?
The first is being blocked/out of inspiration, the second is being meticulous.
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.
At slow, manageable tempos, you can afford to use motions that don't scale to fast tempos. If you only ever play "what you can manage" with meticulous, tiny BPM increments, you'll never have to take the leap of faith and most likely will hit a wall, never getting past like 120-130 BPM 16ths comfortably. Don't ask how I know this.
What got me past that point was short bursts at BPMs way past my comfort zone and building synchrony _after_ I stumbled upon more efficient motions that scaled. IIRC, this is what Shawn Lane advocated as well.
I recommend checking out Troy Grady's (Cracking The Code) videos on YouTube if you're interested in guitar speed picking. Troy's content has cleared up many myths with an evidence-based approach and helped me get past the invisible wall. He recently uploaded a video pertaining to this very topic[0].
I guess I'm agreeing while also saying that you can get there by failing a lot at full speed first. Maybe he practiced at half-speed when he was alone and I never saw that part.
I think this post only covers one side of the coin. Sure, getting things done fast achieves the outcome, but in the long run you retain and learn less. Learning new stuff takes time and effort.
When you practice your instrument you get better att doing the exact same things the sloppy player is doing, but you do it in time and in tune.
When you get faster at building software by (ostensibly) focusing on quality you do not do the same thing as someone that focuses on quick results.
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?
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.
Sometimes, you might really know better, and it doesn't matter. You build the thing with the wrong tools, with a crummy framework, with a product at the end that will probably not succeed. But that is okay, hopefully you learn something and your team and your org learn something.
And if not, that is okay, sometimes its just a job and you need a paycheck and a place to be from 9 to 5.
It's so much more rewarding to get that one stupid extra parameter added to an API + unit tested in 30 minutes rather than 3 hours.
Not every simple thing needs to be handcrafted to perfection.
Because they have built the same house 20 times already. And this exact house has been built 2 million times before. They know the requirements and how to do it, they know what can go wrong and how, and know how long it will take.
It makes a lot of sense to build the same physical house again and again, but if you are doing the same for software, you are definitely doing it wrong. Thus, typically each software development project is bespoke and has a lot of unknowns.
Maybe the people who build houses should obsess a bit more over this shit.
Quality of new builds is not that great (at least in the UK) because the speed is the main focus.
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
Like riding a bike, you start slow with training wheels (or a helicopter parent) and work your way up to Yolo no-hander off that kicker ramp at 40 kph.
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.
Hence the military axiom: “Slow is smooth, smooth is fast.”
Such a great axiom.
I had a mentor/colleague give me a piece of advice that is somewhat related:
"People will remember the quality of your work far longer than the time it took".
I've found it to be true through my experience. I will admit though, I generally do not get tapped to do the quick hacks when in a pinch, but that's a feature, not a bug, in my opinion.
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.
- 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).
Would you mind posting links to Chris Palmer's books/talks/videos?
I have no pithy summary of how this applies to the world of business or software development. It just reminded me of that.
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 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/
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.
An alternative solution is to grossly underestimate the amount of work
> What if laziness is just a habit of thinking about the work instead of the payoff?
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.
They are delusional about their capabilities and sometimes that's the magic sauce you need to succeed - infinite confidence.
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.
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.
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.
At work though it's much faster to be more methodical writing software. Fewer QA headaches.
The latter is not working fast, it's learning.
(Like the author, of course, I'm massively hypocritical in this regard).
And why exactly is this desirable?
But the screenshot says the md file was created in 2009, so that would be 16 years?
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 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.
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.
[1] https://thedailywtf.com/articles/The_Brillant_Paula_Bean
If we’re all just particles and fields, we might as well be as thermodynamically productive as possible
