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
> 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?
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)
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].
> 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.
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.
One could argue that learned speed has the hours of practice "baked in" so it's actually much slower. And that's not a bad thing IMO.
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.
> the exact same things the sloppy player is doing, but you do it in time and in tune.
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.
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?
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.
> People who build houses don't obsess over this shit
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.
I've definitely built the same piece of software hundreds of times over, probably thousands. I've even set up CI to automate the build process.
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.
Yeah, this is very real, and I think it can inflict paralysis on programmers with a certain level of experience and 'i know better' syndrome. Or even a 'it _might_ be better' type syndrome.
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.
This is why I love the bootstrapping stories here on HN.
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.
It's totally fine to prototype, but you need to take care when you try to morph a prototype into a real product.
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.
Not just speed, but cutting costs. Same issue is popping up globally.
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.
There's a thing on YouTube these days where house inspectors basically shame builders. There's one guy who says "I can't tell you who the builder is" while walking past the builder's sign then proceeds to show how the house is completely fucked. Real sloppy work. Brick wall with no concrete so you can literally push it over with one hand. Tiles with voids underneath. Door and window frames cracked. Shower leaking water. Roof tiles broken. Roof vents loose, some times already blown away by the wind. Missing/sloppy insulation. Broken roof trusses.
Maybe the people who build houses should obsess a bit more over this shit.
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.
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.
As my guitar teacher used to say, “Slow is fast”. Mastering the techniques slowly and increasing speed until you’re “at speed” is the way to go.
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.
Shame you can't do this with something like juggling. :D
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 can practice with two balls, sound the same motions you would with three. And if you really want to focus you can practice making a consistent toss with one ball. Two is probably better bang for the buck.
Right, I was just pushing the idea that you can't always literally slow things down. That said, no reason you couldn't pantomime juggling really slowly. To be honest, I wouldn't be surprised if that is a legit path to getting going?
Even dumber, for me, is that I can easily juggle two in either hand. Try to do the same in both hands at the same time? Brain basically recoils in horror.
The metronome of music practice is the idea, here. You don't just do something slowly. You deliberately constrain yourself to a controlled speed and ratchet it up as you go.
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.
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.
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.
> 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.
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 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.
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 think this is one of the biggest reasons why USA has so many succesful companies. People in there are taught from birth that America is the greatest country and they are great and everything is fabulous and everything is possible.
They are delusional about their capabilities and sometimes that's the magic sauce you need to succeed - infinite confidence.
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.
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.
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.
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.
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).
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.
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.
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
> 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 latter is not working fast, it's learning.
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].
[0]: https://www.youtube.com/watch?v=craA3CLqvkM
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.
This was the reward for reading through.
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.
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!
4? My brain revolts.
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.
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.
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.
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’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/
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.
I have no pithy summary of how this applies to the world of business or software development. It just reminded me of that.
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.
https://news.ycombinator.com/item?id=20611539
(Like the author, of course, I'm massively hypocritical in this regard).
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