> 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.
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].
This is actually pretty close to what Stetina says. I just probably didn’t do a good job expressing it.
You’re oscillating above and below the comfort zone and that iteration like you say affords insights from both sides, and eventually the threshold grows.
Great suggestion of a video, I’ll check it out.
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 depends on the level we look at it, but I think there is fundamental difference in what excellent (professional grade?)players are doing compared to "sloppy" ones.
It is not just done with more precision and care, they will usually have a different mental model of what they're doing, and the means to achieve the better result is also not linear. Good form will give good results, but it won't lead to a professional level result. You'll need to reinvent how you apply the theory to your exact body, the exact instrument in your hand, what you can do and can't and adjust from there.
That's where veteran players are still stellar while you'd assume they don't have the muscle and precision a younger player obviously has.
PS: I left aside the obvious: playing in time and in tune is one thing, conveying an emotion is another. It is considerably hard to move from the former to the latter.
After a certain, moderate level of skill, all musicians hit the notes. That's not what differentiates them, and they're not playing the same way.
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.
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.
The problem is that the construction equivalent of a software developer is not a tradesman but an architect. Programs are just blueprints that tell the compiler what to build.
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.
Like one anecdote where they were building an "app" for automatic hotel reservations IIRC.
The "app" was a form that fed into a Google Sheet, where the founders themselves took the data and called the hotels.
When they got some income, they automated small bits of the process one by one.
Sometimes it's good to just have _something_ out there and see if there's a market for it before carefully crafting a beautiful piece of software nobody will ever use. It all depends on whether you're doing it to solve a problem for someone or for the process of writing code. Both are perfectly valid reasons.
Very often people just take the shortest path from a to b, every single time. So you start with a reasonably shoddy prototype, but then you add some small feature, repeat 1000 times and now you still have a shoddy prototype but it's actually a pretty big project and it's all completely cursed because at no point did anyone do any actual software engineering. And of course now it's too big to rewrite or fix so the only way forward is to keep building on this completely broken mess.
At some point you need to scrap the prototype and replace it with something proper, or at least have a solid plan for how you're going to morph the prototype into something proper. This is often challenging and time consuming work, so a lot of developers tend to never really do it. They just execute the shortest path to get each new feature implemented over and over for years while number of bugs keeps increasing and velocity keeps decreasing because nothing makes sense, everything is more difficult than it should be etc.
Quality of new builds is not that great (at least in the UK) because the speed is the main focus.
In Finland (smart) people are buying older houses where they still used good old methods to build them. They are easier to maintain and the failure points are known.
New builds have the weirdest basic issues because of cost cutting, sound carries way too much, the air quality is shit because nobody knows or bothers to do the design for moving the air properly etc.
Maybe the people who build houses should obsess a bit more over this shit.
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
This was the reward for reading through.
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.
I suppose you can somewhat metaphorically replace speed with numbers there. In that juggling four balls is a lot like three, but faster. Getting the initial three going, though... Grrr.
You need not limit yourself to a single gravitational constant.
I look forward to video clips of Elon juggling on Mars!
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.
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?
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.
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.
The latter is not working fast, it's learning.
I have no pithy summary of how this applies to the world of business or software development. It just reminded me of that.
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.
(Like the author, of course, I'm massively hypocritical in this regard).
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.
But the screenshot says the md file was created in 2009, so that would be 16 years?
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