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 took this to mean, in the first case "I write an article every six months" and in the second "I work on each article for six months, but I work on multiple in parallel so I post them very frequently".
The first is being blocked/out of inspiration, the second is being meticulous.
Someone had the bright idea to post another point of view at the same time, so they're both on the front page right now:
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.
The second article is here: https://jsomers.net/blog/the-mcphee-method
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.
What's the difference between a blog post and an article these days? Some of my favourite reporting is a "blog post".
I'm not looking to draw a general distinction between the terms, but rather just saying that there's a qualitative difference between a thing you write and publish in a single afternoon (or even a single lunch break), and something you research and prepare over 6 months. Many people routinely do both and are good at both; neither is inherently better, but they are different things.
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)
I don't think this is true at all.
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 was how my daughter’s virtuoso violin instructor taught, after a lifetime of teaching.
His method was to play alongside the student at 100x their skill level, pushing against their idea that it was too difficult.
But they’d play it, at tempo, horribly, from beginning to end. And then zoom in to a section and begin improving a few phrases at a time.
It was wild to watch, because after months of this, my 11yo could do something that seemed impossible.
Depends on the instrument. For wind instruments, the motions basically don’t change, and your focus is on synchronizing your mouth with your hands. Tonguing technique is different at high speed but you would typically practice with the same technique at low speed when learning a fast piece.
> 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.
Great suggestion of a video, I’ll check it out.
Same applies for martial arts, weightlifting, motorsports, even target shooting..
Touch typing too.
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.
I don’t thinking applies at all.
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.
> 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.
I'm not sure that the analogy strictly holds either (though that wasn't the point), but this isn't a great rebuttal either.
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.
I think Demming never put this between his famous phrases, but if Lean carries any lesson is that high-quality work tends to be faster than fast work.
Slow is steady, steady os smooth, smooth is fast
Fast is cheap, and cheap is good.
I like to break a big task into small tasks, then do each small task fast. I don't worry about how long the big task takes. I'll get there in the end.
If you do that you basically reduce cognitive load and you may end up doing it faster indeed :)
Same here.
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
In poorly thought out analysis, outcomes often become goals because cause and effect are not properly understood.
It works somewhat better at the national level than the company level. By encouraging companies to move fast, some will fail but the employees will have gained experience that gets carried into other companies in the industry. At the company level billions were wasted, but at the national level billions were invested in practical on-the-job training.
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.
> The folks who urge haste occasionally need to be reminded that there is nothing faster than doing it right the first time.
Hence the military axiom: “Slow is smooth, smooth is fast.”
> “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.
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.
TBH I just use AI to do the needful as much as possible and spend my time in other ways.
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.
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.
> 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.
> People who build houses don't obsess over this shit, they just build a house
Quality of new builds is not that great (at least in the UK) because the speed is the main focus.
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.
> 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.
It was a fun sigh of relief after feeling guilty the whole article for not blogging fast enough.
I’ve felt that as a general rule, every social media or blog post is a rule-for-self by its author
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.
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?
> Shame you can't do this with something like juggling
You need not limit yourself to a single gravitational constant.
I look forward to video clips of Elon juggling on Mars!
You can also use light handkerchiefs that fall slower to the ground than balls, pins, or flaming chainsaws.
I forgot about the handkerchief trick to slow things down.
Funny. I can do 3 balls. I can do 3 clubs. I can do 3.
4? My brain revolts.
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.
Slow is smooth and smooth is fast.
As the Romans said, festina lente.
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.
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
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).
Very Interesting.
Would you mind posting links to Chris Palmer's books/talks/videos?
I searched him up briefly, he's an advocate for the ketogenic diet for neural health. It's not surprising because medical grade keto can solve various nerve related issues such as epilepsy and may even be beneficial for childhood ADHD and Autism. He also advocates abstaining from substances which may harm brain and nervous system health, such as marijuana and alcohol. He also advocates for a holistic program of stress management, sleep and nutrient optimization.
Yep, i looked him up too. He has books and YouTube channel/videos on "Brain Energy" theory and "Metabolic Theory of Mental Illness" which seem to make a lot of sense.
The fundamental problem is that the "Modern World/Economy" has forced us to orient our Circadian Rhythms, Diet, Lifestyle etc. around its needs rather than the other way around. This makes absolutely no sense. We are what we Eat and are affected by our immediate Environment (both Natural and Societal). Thus the Organism cannot be separated from its Environment and all problems both Mental and Physical must have its roots in maladaptation. So any solution would have to be holistic starting with diet and lifestyle changes. This has been the basis for ancient systems of medicine like Ayurveda, Yoga etc. and yet most of us have forgotten these holistic approaches but instead look only at symptomatic treatment i.e. "popping pills" when things go wrong.
Chris Palmer YouTube channel - https://www.youtube.com/@ChrisPalmerMD
His testimony at the Senate roundtable - https://www.youtube.com/watch?v=6KskcoSkmjI
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.
But it is good for Just World arguments.
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 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.
Failing upwards would be a good one.
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/
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.
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...
> 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
There's a meme pic I saw on reddit: "We do this not because it is easy, but because we thought it would be easy."
Like Scott Adams says:
> What if laziness is just a habit of thinking about the work instead of the payoff?
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.
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.
Your point was thought provoking. In problem solving the "what" and the "how" are orthogonal since the method doesn't dictate the goal. However, if it takes a long time to do something (how: working slowly eg. because you're coding on a very slow, old machine) it tends to predict that there's less accomplished (what). That suggests that this isn't 'fully' orthogonal.
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.
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.
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.
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.
Wow I was excited to see the TextMate icon in the screenshot at the end. Good memories.
(2015). Previous discussion (172 comments):
The thesis is interesting and convincing, but the article is beautifully delivered with a wry touch of paradox to humanise it.
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.
Yes, this, 100%. Take your pick: "Haste makes waste", "Measure twice, cut once", "Slow is smooth, smooth is fast", etc.
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.
I'm not convinced. This strikes me as a work harder, not smarter. Good judgment is required here.
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.
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).
BuSab would like to have a word with you.
The easiest way to do something is the first time.
> . 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?
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 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.
"Working" is doing the important work in "working quickly."
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".
Communicate, communicate, communicate.
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.
The speed that's between "slow" and "fast" is called normal, and far too many companies, people and leaders deeply believe normal counts as slow.
This one's almost as good as "why don't we try paying software engineers by the line?"
Yes. It's a brillant [1] idea to apply metrics like that to people with university level training in optimization!
[1] https://thedailywtf.com/articles/The_Brillant_Paula_Bean
If your alternative meaning of life is harnessing as many feel good chemicals in your brain as possible, that’s an objectively pointless existence
If we’re all just particles and fields, we might as well be as thermodynamically productive as possible
Who says that burning more fuel is a good goal? Productivity is a tool for people in charge to make you feel like you lack something and you have to burn to be valued. Get some therapy instead: all that stuff is toxic and unneeded. Feel free to burn your lives to capitalism and big tech, for no gain