The good people at InformIT (the website for the overlords of Addison-Wesley, Prentice-Hall, Que Books, and many of the top publishers of programming books) have asked me to participate in an occasional series they run called "Best Programming Advice I Ever Got." The title evokes the image of a wise programmer passing on to me a key insight that changed me (young grasshopper!) for the better. But in fact, most of the practices I would pull on are the results of discovering them in the field or in the literature, without the benefit of sagacious instruction. Certainly, the practice that has most changed and most improved my programming is unit testing. Unit testing long predates the Agile crowd discovery of it. But it was the agilists, notably Kent Beck, who provided the tools that made it super easy to incorporate unit tests into programming. Thanks to his work, I have spent far, far less time in debuggers than I once did.

But I don't remember how I came to appreciate unit testing. The next most useful thing I can think of us is a habit I've cultivated over the years that has been an enormous time saver. Unlike unit testing, I believe far fewer developers are familiar with this helpful habit: When I finish programming for the day, I spend several moments writing down the last thing I was doing, what I hoped to do next (and the file involved), and whatever other information I might find useful when I resume work on this project. Here is the current entry, which I invariably keep in a file named "nextsteps.txt" (which I do check into the VCS):

These entries reveal an active moment in a project migration. A class, whose name I carefully give, needs the command processor to be completed. To do that, I have to design a feature. I also have to finish one of the known, needed components (the command table). I need the unit tests for the command table brought over and validated. And finally, I have to implement processing for some remaining command types.

In less than 50 words, I have given myself context, file names, next steps, and what steps those next steps were a part of. Not bad. When I resume this project tomorrow, I'll know exactly where and how to dive back in. Should I need to see exactly what I did last, of course, I can look it up in the VCS.

Note that most of the items on the list are too small to be recorded in the defect tracker/task system (DTS). These are really personal entries that are part of something that will appear later in the tracker. I don't recommend that these notes go into the DTS as "work update" notes because defect tracker notes should record what's been done, rather than the next step to be done.

Over time, my list of breadcrumbs grows. This happens because sometimes, when I jump back into a project, I'm called to fix an unexpected bug in an entirely different area. In such cases, the notes I've made become even more valuable when I return to what I was doing previously. However, what occasionally will happen is that the bit I was working on is pushed down three or four times and the to-do items at the bottom start becoming quite old.

At that point, I move the older items out of my personal tracking file and put them into the DTS. If I'm not actively working on them, it makes no sense for me to keep the information to myself. I add them sometimes purely as progress history notes, other times as a new sub-task in an existing task — it really depends on context. This step enables someone else to pick up the ball and have all the information they need without having to ask a lot of questions or read a lot of code.

Unlike many other coding practices — such as unit testing, which still is dismissed by some developers—I've never met anyone who systemically left breadcrumbs for themself and eventually abandoned the practice. It's a tremendous time saver that mostly benefits you, but can greatly help teammates if they have to pick up a thread you were previously working on.

— Andrew Binstock
Editor in Chief
alb@drdobbs.com
Twitter: platypusguy