Whenever you start something that will be “work in progress” for some time, take some sufficiently detailed notes.

Have you ever come back from lunch, only to wonder what exactly was the last thing you did? I have – and probably everyone has. It happened to me quite regularly in the past.

Retracing my steps

The outcome of not knowing exactly where to continue can be different. I usually remembered roughly what I wanted to do, and started at a more or less random point to look for the next steps. “Oh, I did that already.” – “And I implemented that, too.” – “That’s done as well.” – “Ah, here’s where I left for lunch”.

Or I assumed I finished what I wanted to do before I got interrupted, only to find out later that I had not quite finished it. In both cases, some time would go by until I zeroed in on the point where I had to continue.

Sometimes I didn’t Find that point at all. I’d come back and approach the problem slightly differently. It did not only lose me some time I spent on the first approach. It also left some unused random code snippets behind that I found later, sometimes much later.

Git diff?

Sure, we can discover the last changes we did with git diff and similar tools from other VCSes. But that will only give us the hard facts what we did. It will not help as well to remember what we thought, although those changes surely will give us some good clues.

So, when I get interrupted, go to lunch or have to go to a meeting, I always try to leave a “brain dump” on a sheet of paper, to know what I was working on when I get back.

Taking notes when it’s not just lunch

Of course, the breaks we take are not just an hour or so for lunch. We leave work in progress over night, over the weekend, and sometimes even over holidays. The time our break lasts usually influences the level of detail of our unfinished work: I might go for a coffee break or a round of foosball with colleagues and leave the editor open in midst of a function implementation.

I won’t do so when I leave longer. I’ll finish that function and when I leave the office over night. I surely will see that my code compiles, tests are green and all branches are pushed when I leave for a week or longer.

Similarly, the amount of information I leave for myself to pick up later largely depends on the time span of that break. If I am away for just a few minutes, a single word or a short sentence on a sheet of paper can bring me back to the right point. For longer time spans that surely won’t suffice.

Usually, we have issue trackers and other tools to remind us of our more detailed and larger scale plans. But not always. For example, I left my project Fix for an unplanned long time span unattended. When I came back I faced a bunch of cryptically short Trello cards that gave me no clue at all what I was planning for the project back then. I had to ditch them all and still am wondering what the heck was I thinking?

Maybe it even is not ourselves

The situation can get worse: Imagine a project that, apart from a few bullet points, you don’t know at all. Someone else started a complete rework two years ago and left the company before the rework was finished. Now it’s your turn to work with what feels like two half projects where the two halves don’t fit together, and all you have to figure out what might have been the intention of that person is the source code and the commit history. Good luck with that!

Conclusion

When we leave work in progress, we should leave a sufficiently detailed note about our intentions, what we have done last and what comes next. If it’s only for ourselves in a day or two, a few notes on a sheet of paper are enough. For everything else, use electronic communication. If we leave a project for longer (or for good), we better have good documentation, including a roadmap, checked in together with the sources.