style: more LLM cleanup

Author: MyNameIsTrez

_posts/2026-05-22-slow-is-smooth-smooth-is-fast.md

@@ -4,15 +4,14 @@ title: "slow is smooth, smooth is fast"
 date: 2026-05-21 12:00:00 +0100
 ---
 
-I think a lot of low quality code gets written when programmers rush themselves, rather than taking plenty of time to consider all options. I personally think programmers often feel more rushed than they actually are, because they feel embarrassed if they spend more time on something than they would like.
+I think a lot of low quality code gets written when programmers rush themselves, rather than taking plenty of time to consider all options. And I think the rush is mostly self-imposed, driven by a kind of hidden embarrassment at spending longer than expected on something.
 
-In a decade of reading programming blogs and watching videos, I've almost never seen anyone specifically call out this hidden personal embarrassment factor. It seems to be the elephant in the room that everyone talks around.
+In a decade of reading programming blogs and watching videos, I've almost never seen anyone specifically call out this embarrassment factor. Everyone talks about external pressure: deadlines, sprint velocity, manager expectations. The internal pressure gets ignored.
 
-A cynic might say it comes from a mix of impostor syndrome and social comparison: you see a colleague close tickets quickly and assume speed is what competence looks like, so you start optimising for looking fast rather than being good. But personally I just get a lot of satisfaction from finishing a hard job.
+It works like this: you see a colleague close tickets quickly and assume that speed is what competence looks like, so you start optimising for looking fast rather than being good. The time estimates almost every company demands from programmers make this worse, reinforcing the idea that how long you spend on something is a measure of your ability.
 
-The expectation at almost any company to estimate how long something will take also heavily reinforces the idea that it matters how much time a person spends on something.
+This is mostly an illusion. In my own experience, not that much total time is lost when I slow down: reviewers can review it quicker, we have fewer back-and-forths, and barely any bugs get introduced that have to be fixed later. A codebase with one superbly polished feature a week is often worth more than three mediocre ones.
 
-I know that companies have to turn a profit, but a lot of codebases would be better off with one superbly polished feature a year rather than three mediocre ones. In my own experience, not that much total time is lost when I slow down: reviewers can review it quicker, we have fewer back-and-forths, and barely any bugs get introduced that have to be fixed later.
+So when you next feel yourself rushing, ask whether the deadline is real or imagined. And if you're in a position to set estimates or review work, stop treating speed as a measure of ability.
 
-The only thing we can do is tell our colleagues and people online not to feel embarrassed for taking their sweet-ass time:
 > [slow is smooth, smooth is fast](https://en.wiktionary.org/wiki/slow_is_smooth,_smooth_is_fast)