The Forgotten //TODO

As a developer is working on code, they will often leave a trail of breadcrumbs behind that represent their train of thought as they are coding away. These breadcrumbs come in the form of the infamous //TODO. An interesting side effect of the programming world, and one that shows the relentless and charging train of thought that programmers take on during development, the //TODO is basically a way of saying “I’m too busy for this now, but I need to come back to it.” Chances are, the developer will never come back to it and it will be forgotten, left to the cold darkness of Visual Studio Code monokai font and dark mode. These //TODOs are usually rife with value and information, and prove to be a very useful productivity tool if treated correctly. Here are some of the reasons //TODOs are so valuable:

  • They are embedded in the source code, and so are first class citizens in terms of visibility. As the source code is scanned by developers’ eyes, they can be seen as part of the programmatic flow.
  • They can provide context to the inner workings of the piece of code they underpin. They are immediately visible and available.
  • Version control will pickup the //TODOs, and as such, they travel with the code as it goes through stages of change and versioning.

But what is wrong with //TODOs?

When maintaing multiple codebases and working with projects that are many layers deep, it is hard to see where //TODOs are scattered, which projects have certain types of //TODOs, the priority of the //TODOs, and the age of each. The last idea being one of the most important, as //TODOs have a lifespan since they are directly tied to the behavior of the code and can either become irrelevant over time or signal a bigger issue of stale and forgotten code.

Solving for the problem

//TODOs can be very useful for productivity, if treated correctly and actually used as a tool that will create items to action in the future. This is where Qwoka comes in (https://qwoka.io). Qwoka performs a single function, and performs it well. On each “push” to a branch, Qwoka will pickup any newly created //TODOs, centralize them in an easily searchable dashboard and tag them for filtering. In addition to this, Qwoka will timestamp the //TODO so that the age can be tracked and developers can keep watch of stale //TODOs or work that has been put off for too long. Qwoka is task management for developers, and is solely focused on developer productivity. There is no concept of Kanban, SCRUM, sprints, or project management when it comes to Qwoka. Those topics are better left for a project management or ticketing system (however, Qwoka can integrate with these if needed). Instead, Qwoka’s first class citizen is the developer, and to help the developers keep their train of thought. Wouldn’t it be nice to know that as a developer, you can maintain a constant stream of thought, writing any //TODOs that should be revisited in the future without ever leaving your IDE or lifting your hands off the keyboard? And then, once done with your coding session or your current chunk of work, you can push it to the tracked branch, and Qwoka will pickup any of the //TODOs you created and organize them nice and neat for you. This is the goal of Qwoka. To make developers more productive and to never forget a //TODO again.