Being excited about disagreementseven days beforeChatting with colleagues this week, I am recognizing that it might be…
The rewrite count
Build a thing to build the thing2023When building new products, there’s always a weird tension between making something…
Chances to get it right2023In the world of technology, there is this concept of shipping: the…
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.
Crappy and the fear of rejection2021My colleague and I had this observation about companies who are in…
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.
Thinking to write2024I’ve had this realization about myself recently, and it’s been rather useful…
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.
Change2022If you’ve read my stories before, you may recognize the familiar stair-step…
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.
Aircraft Carriers and Zodiac Boats2024An insightful conversation with a colleague inspired me to articulate the distinction…
Cutting or highlighting?2021Talking with one of my wise colleagues, we arrived at this neat…
Questing, Scaling, Keepingthe same day, links hereI’ve written a couple of takes on this before, but they didn’t…
Say it in many different wayslinks here, 2021It took me some time to figure out that for novel ideas…
Cheesecake and Baklavalinks here, 2022I have been reading Alex Komoroske’s Compendium cards on platforms, and there’s…
Stages of the customer-vendor looplinks here, 2022Reflecting on a post from a year ago, this framing might be…
Development environment for rapid experimentationlinks here, 2023Keep the rewrite count high – don’t sweat facing the possibility of…
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.
Show 3 comments
Questing, Scaling, Keeping – Dimitri Glazkov linked here · June 25, 2021
[…] takes on this before, but they didn’t feel quite right, so here’s another iteration. Keep that rewrite count ticking! It seems that there are some distinctions that I can draw when looking at the missions of […]
Cheesecake and Baklava – Dimitri Glazkov linked here · April 5, 2022
[…] There’s one concept that I kept having difficulty articulating for a while, and here’s my Nth attempt at defining it. It’s about the thinness and thickness of […]
Development environment for rapid experimentation – Dimitri Glazkov linked here · June 5, 2023
[…] the rewrite count high – don’t sweat facing the possibility of rewriting the code we’re writing multiple […]