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.
Top comments (11)
Where, specifically does the To-do list live? Who sees it? And what's an example to-do?
Good post, would love some examples.
Good questions! The to-do list should live somewhere that all relevant stakeholders can see it and chime in. That's going to vary based on the team, project, and task, but in general, the more visibility the better.
A to-do should at least have a brief description of the task and some way of tracking who's working on it. As people discuss and begin work on the to-do, it can be helpful to add supporting links, screenshots, demo videos, etc. There are plenty of tools that do this well -- I've enjoyed working with Basecamp and Trello.
I wouldn't worry about trying to conform to any particular format, especially when you're just getting started. I think to-dos should be about getting context out of individual's brains into a shared space rather than adding unnecessary process or bureaucracy.
Thanks!
Teams that are working with Microsoft stack, often use VSTS to manage their backlog. 🙂
"Couldn't you just ..." ha ha. Uuum, how 'bout no?!
But being serious again, something that has worked well for me recently is trying to solve multiple known similar issues/feature request with one over-arching bigger solution, instead of quick fix of very small and specific edge case.
Could be wrong, but I feel I first heard about this approach from Downwell game-dev blog, but also seems to work well for bigger business webapps :)
For sure! It's great when a general solution can address multiple issues at once. I've also found that those types of approaches can lead to more resilient and easier-to-follow applications than a patchwork of quick fixes.
It's of course easy to go crazy and re-write stuff just for the sake of it, but it really feels like good practice, as dev, you're not writing throw-away code and can be proud of your nice neat code, and business also gets a re-usable feature that now can grow and solve even further problems, probably much quicker in the long run than doing 10x quick fixes.
I like the part about easier-to-follow app, I might sneak that into my next board presentation as additional benefit :P
"but through discussing the to-do, I’ve learned that a change wasn’t necessary after all." Chesterton's Fence is a handy principle regarding this.
Great article!
I agree, writing a public to-do really improves the communication inside the team.
Also, that way, if you are stuck - you can get help from team members that saw your code and might have interesting ideas to share.
At my workplace we use github enterprise where we log our TODOs as issues. This kicks off a discussion which may lead to it being worked on.
Nice! I recently moved to a new team that uses GitHub issues heavily. It's been a little painful retraining my muscle memory that's so used to working in Basecamp, but the goal is the same: getting to-dos out in the open.