How often do you get to rewrite and rethink?

From Baldur Bjarnason

One of the benefits of time is perspective. When you’re writing or coding, letting the work rest for a day or two usually lets you review it with a fresh perspective revealing its flaws as obvious. This goes beyond the usual recuperative effect of rest. Just a night’s sleep won’t do the job. You need to let time remove the proximity of what you were working on.

That lands true to me. Whenever I return to some code I wrote six or more months ago, the ways to improve it immediately jump out. Not just little improvements either, vast improvements. I often wonder what I was smoking the first time I wrote it; my new perspective can instantly identify serious flaws.

Bjarnason goes on:

Employers never let you do this, as a rule, but anybody who has either read my book Out of the Software Crisis or my newsletter essays would know that modern software development teams are organised to prioritise control and productivity theatre over quality or genuine effectiveness.

Companies explicitly prefer feature development theatre and vanity metrics over making any of the software usable or reliable.

It shouldn’t come as a surprise that letting a project rest and switch everybody to another for a while—one of the cheapest methods available for increasing the team’s productivity—never happens. Projects, like the Monty Python parrot, rest when they’re dead.

This assertion was interesting because my personal experience at my day job has not reflected this at all. I have a high amount of autonomy and decision-making over my day-to-day activities. If I decide that the benefits of “re-doing” a part of the codebase justifies the time spent on the task, my decision is supported. Over the seven years I’ve been with CodePen, I have entirely rewritten certain features of the product/sections of the website three times over.

This may be a uniquely cultural thing at CodePen. This company has never really been run with the goal of moving fast, scaling up, selling out and riding off into the sunset clutching bags of money - code quality be damned. It’s been kind of the opposite, really, a slow and steady approach. I’m encouraged to think and re-think through how and why I’ve approached a problem any particular way instead of being pressured to finish quickly and move on to the next thing.

This is nothing like my previous experience working in agency environments. Before CodePen, I mostly worked on campaign sites. You built them as quickly as possible, and they were often only live on the internet for three months to a year. But Bjarnason’s words made me wonder if this was also a rarity in a product developer role…

So I’m asking about your job. As a developer¹, do you get the chance to revisit projects and rewrite your code? Or are you constantly pressured to move on to new projects?

Footnotes

1. 🤪 ↩