Not speed but smoothness
The rushed work is a shame for the craftsman
In Bulgaria, we have a saying that goes something in the lines of:
“The rushed work is a shame for the craftsman”
You use it when someone does something sloppily in a rush just so they can get the task off their hands. Fix a sink, paint a wall, build a backoffice application.
That kind of thing.
My grandmother has repeated this so many times when I wanted to rush through my chores. Her generation insisted on doing things right the first time, so she’d get me to tidy the desk drawers after I had stashed all my stuff in them just so I could go out and play.
“The rushed work is a shame for the craftsman”
We are obsessed with speed because quickness translates to profit for a business. But I’ve never seen someone who is focused solely on speed do great work.
I have it nailed in my head that speed on its own is not a virtue. Everybody on this Earth knows it as well, yet we still try to turn every job into a Doom speedrun.
Yeah, the best people I’ve worked with have always been fast.
But not because they’re rushing.
It was because their movements don’t have fat in them. They work deliberately, they don’t take unnecessary actions, they know what they’re aiming for.
It’s not speed but smoothness.
That smoothness comes predominantly from knowing what you want. Knowing what you need to do on the first try. That’s where the taste everyone is talking about comes in.
Teams are slow because they need more time to think, to try out approaches, to test. Thinking of the correct solution requires contact with reality, and some builders are slow because they make it infrequently.
If you don’t read the code, you’ll be a lot quicker.
But one of these things Rauch posted about will also be true:
The other day I asked Claude to create a shape for a subtle background accent on some pages, and it created an svg with polygons. Good if you’re in a rush and you don’t care, but when I started tweaking the shape to make it perfect, I found out how difficult it is to move polygons based on points.
Had I known what I wanted, I could’ve told it to use divs with a border and rotate them.
I meditate on this because I think you only become good by doing homework, by studying the tape. It’s easy to lie to yourself. I could’ve complained about the model not being good enough after the tenth polygon change, but the reality is that I didn’t know what I wanted.
I’m the slowest when I haven’t done my homework.
I’m quick when I’ve done some work beforehand. I’ve followed my curiosity, gone down rabbit holes without a need.
I’m fast when I have taste.
Otherwise, I stumble through an implementation like a pinball ball, bouncing from one solution to the next. That’s not necessarily bad. But I recognize it, and I don’t expect speed or smoothness. I expect iterations and learnings.
Try to be fast without knowing what you want and you’ll produce garbage.
“The rushed work is a shame for the craftsman”




