I often come across problems that, on the surface, seem like they’d be “quick fixes.” Maybe it’s a bug that could be resolved by tweaking one variable or a new feature that could be added with a change to one branch of a conditional.

When I notice opportunities for quick fixes, I naturally start thinking through the implementation. Popping open my text editor and making the change is tempting. I like coding; it’s a big part of why I’m a developer. Shipping code makes me feel productive. And because I’m almost always working by myself or on a small team with lots of trust and autonomy, nothing’s stopping me from creating a new branch and hacking away.

Most of the time though, resisting the temptation to code the quick fix, and writing a public to-do instead, results in better outcomes.

To-dos take more time upfront but can ultimately lead to less work. A number of times, I’ve shared a to-do and learned that someone else on my team was thinking about a similar problem and addressing both of them at once would be faster and result in a better solution. Other times, I’ve created a to-do about something I think is a problem, but through discussing the to-do, I’ve learned that a change wasn’t necessary after all.

The visibility that creating a to-do brings to a problem extends beyond getting out of extra work. Getting trapped in a cycle of working on quick fixes in a silo can leave me feeling disorganized and others wondering how I’m spending my time. Making a public to-do shows my team where I’m focusing my energy and allows them to contribute when it makes sense.

To-dos move the context of a problem about out of my brain and into a centralized place where others can consider it for their own work. A thoughtful explanation of a problem in prose is more discoverable than a commit message, a comment, or “self-documenting” code. It can also bring more perspectives into the conversation by making the problem accessible to those who otherwise wouldn’t be reviewing a code solution.

Often a “quick” fix isn’t. A few times, I’ve started coding a fix, and as time ticked away, I’ve found myself so deep down a thread in the codebase that I forget about the original problem I set out to solve. The exercise of unpacking a problem in English can shake out nuances about the problem that can prevent journeys down rabbit holes.

To-dos lessen cognitive load, too. While working on one problem, it’s easy to find a handful of other problems, and defaulting to quick fixes would force me to keep all of those in my head. Noting those problems in to-dos along the way and moving back to the original one keeps me focused.

All that said, sometimes, issues pop up that seem like clear candidates for quick fixes. Even though I default to to-dos, sometimes I’ll use my discretion and start by poking at some code. In those cases, timeboxing is helpful. If after 20 to 30 minutes I’m not feeling very close to some sort of resolution, I’ll stop and create a to-do, even if I intend to go right back to working on the same solution.

But most of the time, starting with a public to-do instead of a quick fix turns out better for my code and for the people I work with.

Cover image by Trilok Rangan on Flickr.