Tracking your advancement

I use plain text to take notes and also to maintain my todo-lists. Then I try to make my progression explicit by my environment.

I open a tab/window for each little task and I close them once done. In my code editor, I do that by opening/folding blocks, usually the definitions of functions. In my todo-list, I do that by adding/deleting lines.

This may sound too simplistic and prone to fall short on hard tasks. But it has been working for me so far, and I have never been left wanting. Read on the full details to make up your mind. It may not work for you, for a variety of reasons.

The details

First of all, it is worth noting that there may be no todo-list beforehand. Or just a very high-end one. I'm not big on playing the big planner who tries to anticipate every little detail before getting to work. It is rather the contrary, hence the reason why I tie tab & task together, so that my progression is made explicit by my very environment.

That is: when I open a tab, I see it as representing a task. On one hand, it is about a task anyway (usually editing a code file, reading a document or editing data). But as I am deliberate about it, I close the tab to represent that the task is done.

Tabs are short-lived, hence the need for shortcuts, to easily open them and never fear of closing them. When I was a junior, I often thought “I'll keep this open, just in case” or “This is so specific, better keep it open”. Nowadays, I know I need a shortcut. Or paste the code/link to a note file. Basically, anything that helps me to get things back.

Of course, if I am done with the task, I will never need to get back to it. So I'm happy to close the tab and even happier to realize that I will never need it again. The task is truly behind me and seeing the tab disappear is a real pleasure in such a case.

But when I cannot close a tab, that is when I start a todo-list. As said earlier, I may work without a todo-list. I just open tabs here and there, and start working. I'm closing tabs as I progress, opening new ones if needed. I work like that when I am confident about my competence. The more I know, the more I go with the flow.

When I do not know, or when I encounter a difficulty, I can tell — or, rather, my environment tells me: there are many opened tabs and some have lingered for a while. So I start a todo-list and split tasks into smaller tasks until the actual steps are obvious.

Being obvious is what matters. It does not follow that a step is quick to do. It may even be an opened door to a larger task. The method still works: you need to apply it some more. It's just a bad surprise as you realize things are much more complicated than you thought…

As said earlier, I may have a high-end todo-list. Well, I always have one, at least in my head. I also said I am not a big planner of detailed todo-lists. Now, you know why. If I'm competent, I'll wrap things up without such a list. And when I'm not competent, I will know why and on what, for real. So I will write a detailed todo-list with the actual correct details.

What is the goal of splitting tasks, if not to clarify the steps to do? And how to get the details right, if not by trying to do the task firsthand? This approach ensures I make good todo-lists and, what's more, only when it is relevant. I then narrow my focus on the first step with the guarantee it is spot-on. High-end todo-lists for planning only orients me.

It may be tempting but I rarely reuse a tab from one step to the next. Because when a task is done, I may close several tabs. I know this is not in line with the “one tab = one task”. What can I say? When you are scouring the web, hopping between code files or crisscrossing logs from different machines, how can it fit in one place?

Well, it can: in one notes.txt file. And if the file is overflowing with information, I split it, just like I split tasks. The idea of “one tab = one task” is not to embody a task in one single thing. It is to remember what the task is behind each tab to know when you can close it, lest your environment overflows with tabs, windows and whatnot.

Trying to reuse a tab means you need to change in your mind what the task behind the tab is. I find it much more lightweight to just close the tab and be done with it and the task and everything. I'm starting afresh: it's much nicer visually and I avoid unnecessary mental overhead.

The exception is documentation. That's because I generally need to read a lot of it and that requires jumping from page to page. You can put the Back and Next navigation features to good use by keeping everything under one tab.

The takeaway is that it is important to close things to give yourself breathing room. To that effect, you need to know why you opened something in the first place. But you also have to mitigate the effect of closing something by being able to quickly get back to it. With everything you have: shortcut, script, undo, history, Git, bookmark, note, etc.

  1. My progression is made explicit by my very environment.
    • one tab/window = one task
    • closing a tab/window = task done
    • shortcuts ⇒ to get back to important things
  2. In my comfort zone, I go with the flow.
    Closing things is a pleasing indication of my progress.
  3. Out of my comfort zone, I write tasks down and split them in sub-tasks if need be.
    The goal is to make the actual steps obvious.
  4. I plan with a high-end todo-list, even if just in my head. Then I start working.
    Planning orients me ; it's not about deciding by anticipation.
  5. I write better detailed todo-list when I tried to do the task first.
    Then I focus on the first step, which is most assuredly spot-on.
  6. I do not try to “re-allocate” the tab to another task. Instead, I just close it.
    • This avoids mental overhead.
    • It's nicer to start afresh.
    • Documentation is the exception, as it is often spread on several pages. By keeping things under one tab, I can use the Back and Next navigation features.
  7. Takeaway:
    • Closing things gives breathing room.
    • Identifying why something is opened makes it possible to close it appropriately.
    • Keeping track of everything important enables to get back to it easily.
      This cannot be overdone: shortcut, script, undo, history, Git, bookmark, note, etc.

Reasons why this is working for me

This is mostly a reformulation of the previous part, in an attempt to give another perspective.

  1. Closing does not feel like a loss or a danger.
    On the contrary, it feels good to close one tab and it feels very good to close several tabs, as it means I am moving on.
    Sidenote: a software should provide the history and the undo features. Find how to use these.
  2. The proliferation of information can creep on naturally, so I prefer to be deliberate about it all.
    Sidenote: if a software gives poor ways to no way to tame such proliferation, it is a problematic software. Even more so if it works because of endless content.
  3. In one glance, I know how much work is being done.
    Misjudging a task is visually obvious: lots of tabs & windows. I may then take notes in my second editor (free-form comments, snippets of code, any data, all file paths, all links). Basically anything that can help me resuming the work later on, after I've closed the surplus.
    I may even write down the steps, to track things explicitly, just in case the task is really harder than I thought. What I do then won't surprise you much: the more I move on, the more I delete steps, notes and everything.
  4. Tracking is implicit as each tab embodies a self-contained task.
    A quick look at the tab may be enough to remember what needs to be done. If not, a quick read into it usually tells me about the work. This is no waste of time anyway because, if such a tab is opened, it means I have to get a closer look to it, which usually translates as: “read thoroughly” and even “read all”.
  5. Tracking is also implicit as a tab gets closed once its task is done. So, any opened tab means something needs to be done.
    Even when there is nothing left per se, there is always the same last step to every task: double-check that the task is truly done, just to be sure I do not forget anything.
  6. This approach is open to recursion, and recursion often happens.
    “Life lesson”: everything is more complicated than you think, everything takes more time than you anticipated, and maybe than you want to spend. I'll leave you to be the judge of that but this has been true enough for me. It's the rule, rather than the exception in my experience.

Folding in code editor

I use folding a lot as an implicit way of tracking the work to be done. A folded definition means I have no (more) work to do. A non-folded definition means the reverse. If you go through the above list, you will see that folding just satisfies all criteria.

Opening several explorer windows

I use an explorer windows just like I use a tab. It embodies one precise task and then I close it, even if I may come back to the same folder the very next moment.