You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: _posts/2026-05-22-slow-is-smooth-smooth-is-fast.md
+4-8Lines changed: 4 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,14 +4,10 @@ title: "slow is smooth, smooth is fast"
4
4
date: 2026-05-21 12:00:00 +0100
5
5
---
6
6
7
-
I think a lot of low quality code gets written when programmers rush themselves, and I think the rush is mostly self-imposed, driven by a kind of hidden embarrassment at spending longer than expected on something.
7
+
[Slow is smooth, smooth is fast](https://en.wiktionary.org/wiki/slow_is_smooth,_smooth_is_fast) is a phrase that stuck with me, but I think the reason it's true is rarely spelled out.
8
8
9
-
In a decade of reading programming blogs, I've rarely seen this embarrassment factor named. Everyone talks about external pressure: deadlines, sprint velocity, manager expectations. The internal pressure gets ignored.
9
+
A lot of low quality code gets written when programmers rush themselves, and 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, I've rarely seen this named. Everyone talks about external pressure: deadlines, sprint velocity, manager expectations. The internal pressure gets ignored.
10
10
11
-
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. Time estimates make this worse, reinforcing the idea that how long you spend on something is a measure of your ability.
11
+
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 for craft. Time estimates make this worse, reinforcing the idea that how long you spend on something is a measure of your ability rather than a property of the problem.
12
12
13
-
Slowing down saves time overall. Reviewers can review it quicker, there are fewer back-and-forths, and barely any bugs get introduced that have to be fixed later.
14
-
15
-
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, it's worth asking whether you're accidentally rewarding speed over craft.
16
-
17
-
> [slow is smooth, smooth is fast](https://en.wiktionary.org/wiki/slow_is_smooth,_smooth_is_fast)
13
+
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, ask whether you're accidentally rewarding speed over craft.
0 commit comments