The rewrite count

As a software engineer, I often see a struggle that both teams and individuals experience: overcoming the anxiety to “get it right” the first time. And it makes sense! We want to make sure that when our software ships, it does what we want it to do and doesn’t cause harm. 

However, there’s something curious that happens along the way: somehow, this desire morphs into a self-judgement, detaching from the original purpose. If we don’t get right, does that make us good engineers? It’s no longer about the criticality of getting the code right, but rather about protecting ourselves from the possibility of appearing incompetent. Most commonly, I’ve seen this affect the productivity of team newcomers, who agonize over their first patches, and react in anguish when given feedback. It also affects teams who missed their deadlines and/or tackling problems that are much larger in scope than they previously realized. I am speaking from experience here. /me raises hand. Yes, I was–and sometimes still am–one of those people.

A technique that helps me here is to frame my work in terms of the “rewrite count.” I tell myself: “you won’t get it right the first time, so maybe give yourself a number of times that you’re expecting to rewrite this code/doc/deck from scratch. What’s the rewrite count here?” For easy ones, like this article, it’s one. I might finish this or I might let it go and come back to the topic some other time. For more complex bits, I give myself some “ambiguity slack,” setting the rewrite count higher. Sometimes, I set the rewrite count so high, it’s like telling myself: “you’ll probably never get it right.” Doesn’t mean it’s not worth trying, but hey — it probably won’t work.

One way to visualize the rewrite count is with an evolutionary process. In a complex space, to find a new maxima, I need to allocate some time for the churn. I need to walk around, explore the evolutionary landscape, rather than anxiously hold what I have now as the “right thing.” Incrementing the rewrite count is a way to let go, and allow myself to start from a new angle. And most importantly, see all that I made before as a learning experience that prepared me for this new start.

Practicing rewrite counts can feel rather challenging in organizations that value impact as only the code that’s shipped. Yet, this could be the key to effectiveness in these settings. Just like leaning in the opposite direction while steering a racing sailboat, learning to let go of the objective in the objective-driven world might give you that extra flexibility and peace to do amazing things.