Why being fast is important

About 10 years ago, I realized all the best programmers I had worked with had something in common: they were fast. By that I mean that they moved quickly: we’d discuss a problem and an hour or two later they’d already have a patch ready or a prototype to show off.

It took me a while, but eventually I realized: they weren’t fast because they were great programmers, they were great programmers because they were fast.

Patrick Dubroy touched on a topic I fully agree with, but I couldn't find the right words yet.

I think the important part is this:

Being fast at coding enables being fast at getting feedback. Being fast at getting feedback enables being fast at shipping value.

And "fast at coding" means not only actually developing stuff quickly, but creating and sharing a small merge request, a small spec, a small prototype, which others can react to.

I've seen engineers work for days and days with their heads down on their task, then finally open a huge merge request. And then the feedback comes in

• Do we even need this abstraction?
• Does this even make sense?
• This approach doesn't really fit?

And then changing stuff becomes expensive. You thought you were done, but actually you didn't cover this edge case or you picked the wrong approach and you have to go back to the drawing board and start from the beginning.

The same thing happens outside of code.

A UX designer can spend weeks polishing the perfect flow. Then, when the design is handed over, engineering says: we actually do not have the data to build it like this. Or the backend does not support that state. Or the edge cases are completely different from what everyone assumed.

(Whether that handoff process is ideal is a story for another time.)

The point is: by the time the feedback arrives, the work has already become expensive to change. So the goal should be to ship something small to make it cheap to change.

And almost always, while building, you discover something you did not know at the start.

• The data we have is slightly different or doesn't actually exist
• The existing abstraction is worse than expected.
• The business rule has an exception.
• The "simple" part is not simple to build
• The thing you thought existed already actually doesn't exist
• The user does not actually need the thing you thought they needed.

If you discover that after two hours, great.

If you discover it after two weeks, not great.

So maybe the goal is not just to be faster at finishing work, but faster at getting feedback.