Introduction

You might be working in a feature factory. Or you’re a consultant that has to juggle multiple projects at once. Just when you’re in the middle of doing something important, something else suddenly needs immediate attention. And once you’re back, you have no clue what you’ve been up to - the context switching has screwed you up once again. Couple of those in a short timeframe, and you start questioning the life itself. (by you I mean me)

And what you’ve been doing was a no easy task - you were adding features to the worst codebase that you’ve ever seen. Many moving parts, many things to keep in your head. As if getting into it once wasn’t big enough of a curse, you have to do it multiple times a day. But you’re a professional and an adult, so you will deliver.

You’re also expected to provide a detailed changelist of the things you did, so that they could be reviewed easier.

“Now where was I…”"

Every time you get back to what you’ve been doing, you have to go through the most of the code changes made previously, so you’d get the idea where the things are standing. And if you write your changelist after the coding is done, you’ll have to go through the changes once again in order to provide some meaningful list of descriptions.

Wouldn’t it be more helpful if at least some of those descriptions were already there every time you get back to the task?

TLC - Think it, Log it, Change it

It ain’t a method if it doesn’t have an acronym, amirite?

Thinking upfront isn’t an easy thing, especially when there’s a lot to do, or you aren’t sure where to start. Jumping right into coding makes you feel that you aren’t procrastinating on the work, but it’s easy to lose focus once you realize that you’ve taken on too many things at once and now have to manage contexts within contexts in your head. This is a state of mind where shattering of a thougth process with a benign question over Slack can feel so irritating that you could just punch the other person right in their stupid face if they happened to be sitting right next to you (or that’s just me again lol).

Giving some thought upfront and writing down your next steps will help you to maintain focus. But it’s easy to forget about writing things down, or to neglect the value of doing it. So it’s a discipline that has to be learned and maintained. An “acquired taste” so to speak. And you don’t need to get things right the first time you write them down. You’re free to change the text as you progress, nothing was carved in stone (or in a commit message).

As a bonus, your notes will be waiting for you to skim trough them when you get back to the task after a while, like a to-do list. And chances are, they’ll be much shorter and concise compared to going trough the code all over again.

But it’s a chore

Unless you’re really organized and maintain your notes in a clean and accessible way, finding and then editing a correct to-do list could become a chore, especially if you need to do it quickly. This is where the general purpose (usually web based) to-do software falls short. There are also CLI apps, but they are also general purposed most of the time, and may not be easy to use.

Maintaining a text file or a spreadsheet per project, split into sections that represent feature branches, is probably the easiest way to put this into practice, though it’s not ideal if you’d like to get some more insight into the work done.

I’ve took all of the above into account when I’ve decided to create gitodo as a dedicated tool to help me maintain my focus at work.

gitodo?

I know, I know, yet another to-do list app… And to make things worse, I used it as an excuse to finally put Go and SQLite into practice.

But it does address some unique concerns that I wasn’t able to address with the text files or existing to-do apps:

• I want to be able to retrieve my to-do list for my feature branch anywhere within the git repository without having to type a lot, or having to scroll trough a document in another window
• No special tags or queries, just a dumb list that is easy to manipulate via TUI screen
• Nothing beats a proper editor for editing text (well, obviously), so it has to invoke an editor when items have to be added or edited rather than me creating some crippled version of nano (vim users may find this rather appealing). It should use the same one that is configured for git
• I also want to be able to use my completed items when crafting a commit message. It should also take into account of what was already committed, so it doesn’t offer the same items again
• Stash management. Ability to link a stash to a to-do item as a form of “checkpoint”
• I’d also like to see a report on what I’ve been working on recently, so I could quickly glance over it when interrupted with a (daily) meeting. Or have some way to automatically export that data and push it somewhere else
• Time tracking was not a necessity, but I thought it would be a neat feature to add, especially if you’re billing per hour
• Zero config files. All necessary information is obtained from git and the environment.
• Also no files stored in git repositories, though this might be reconsidered later
• Opinionated and minimal, no hundreds of features configured with yaml

If you like the idea, head over to the docs and give it a spin. Unfortunately, you’ll need Go and GCC to build it, as it’s not officially packaged for any platform yet. I still consider it as a proof-of-concept, though it’s perfectly usable and mostly feature complete at this point (I use it at work btw). It’s free and open source.

Conclusion

If you’re struggling with context switching or with maintaining focus, give some “committing upfront” in the form of a to-do list a try, and see if it makes a difference. I’ll be honest and say that I haven’t developed my discipline around it yet, since I’m not practicing it for every task I have to do, especially if I’m doing things intended for mindless code monkeys. But once I do, thinking about things upfront and writing them down usually leads to more quality output.

P.S.

There was a local meetup some time ago where a guy gave a talk about writing commit messages upfront for similar reasons discussed above. I wasn’t aware of it, a friend of mine mentioned it to me recently. So this isn’t anything new, just a bit different approach. If I ever find out who it was, or find any posts/videos from it, I’ll post them here.