Work Fast, Make Problems

2025/Jan 14

I’m currently developing a text editor, dogfooding¹ it as I go by writing computer code and blog posts².

I found that other programs on my computer would sometimes make changes to the files I had open in Parchment—usually because I’d reverted some changes through Git³—but because the version that was open in Parchment was older, when I would eventually save my work, the changes made by Git would not be present in the version saved by Parchment. This led to a moment of confusion where code I’d thought I’d deleted had suddenly reappeared. It was a simple fix once I’d realized what had happened, but it would have been nice to know ahead of time what I was about to do.

This little incident reminded me of how GNOME’s built-in text editor handles situations like this: When it detects that the current file has been modified by something else, it displays a banner prompting the user to either reload the file from disk—losing the changes that the user made—or to overwrite the file on disk—losing the changes made by the other program. I sought out to implement something similar.

Parchment lacks features which make it easier to write code faster. I find such features are often either an unwanted distraction, or they funnel me into an absentminded development style where I program by auto-completion and inevitably put myself in a situation where I’ve made a mistake because I wasn’t as intentional about what I was writing. I’ve never once felt that lacking has hurt my ability to write code, so I don’t miss them. The major consequence of this choice on how I solve problems is that I work more slowly, and much more considerately.

The magic of this approach emerged once I had reached a point where I was about halfway through implementing the warning banner—I realized that I could solve this problem in another way. This alternative solution would not involve any interruption while the user was busy writing, would involve less code, but it would still solve the problem I was faced with. I quickly pivoted to my other envisioned solution once I made this realization, and soon had a working version of an overwrite warning.

It’s unintuitive, but the result of working slowly is that I can sometimes avoid writing features that would clash with the overall design I have in mind. Instead of piling code on top of code endlessly, my approach involves carefully refining the design I’ve made so that it solves more problems than before.

Instead of needing to rip out the warning banner—or worse, keeping it—giving myself more time to ponder the problem put me in a position where I was able to avoid wasting the time needed to test and debug a worse feature. I saved a lot of time by working slowly. Haste makes waste; The most “agile” way of responding to changing requirements is to avoid making more work for your future self by doing things right the first time.