In the realm of software development, there’s a peculiar phenomenon that Baldur Bjarnason aptly describes as the “benefits of time.”
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.
This sentiment is echoed by Rach Smith, who works on CodePen.
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.
Refactoring is an art all on its own. Revising existing code to make it more efficient, readable, or understandable without changing its external behavior is the equivalent of an artist stepping back, looking at their painting, and realizing that a few strokes here and there could turn it into a masterpiece. But companies don’t usually reward this. Why? Because it doesn’t directly translate into a new feature, a bug fix, or any other tangible metric that can be paraded in front of stakeholders.
This is a glaring oversight. Refactoring is not just about cleaning up; it’s about future-proofing the codebase. It’s about making it easier for the next developer (or even future you) to understand what’s happening. It’s about reducing the cost of future changes and minimizing the risk of introducing new bugs. Yet, the corporate mindset often boils down to: “If it ain’t broke, don’t fix it.” This approach ignores that while the code might not be “broken,” it could be far from optimal.
Rach Smith’s experience at CodePen is a breath of fresh air in this context. She describes a work environment where the benefits of revisiting and refactoring code are recognized and even encouraged. This is in stark contrast to the “move fast and break things” culture that dominates much of the tech industry. At CodePen, the focus is on “slow and steady,” on quality over quantity. It’s a reminder that the race to churn out features should not come at the expense of code quality.