Leave Breadcrumbs For Yourself

I've been doing this kind of thing for over 15 years and not just at the end of the day. At first I intended only to keep track of my consulting hours and what I did during that time, using a small database program I wrote. But I soon started adding design decisions, ideas, and todo lists. Nowadays I use a text editor, and every project folder has a Notes folder where I create a text file with the date encoded in it (like "N2012-09-06.txt" for Sep. 6, 2012) for each day I work on that project. I continuously add decisions, thoughts, ideas, unit-test results (when it makes sense), todo lists, errors, fixes, etc. It's a running log of what I've done on any given day. Being searchable, it's also a knowledgebase that has saved me hours upon hours of repeated effort and research. And of course it helps me recover more quickly from disruptions, no matter when they occur in the work day.

I do the same thing in two different ways: 1. Send a "where to start" email to myself when I have a number of loose ends to deal with the next morning, or 2) maintain a to-do list in a note program such as OneNote or EverNote when I am working through a particular new feature.

@dleppik: Good point. I'd completely overlooked the last aspect you mentioned. By having a system of prepping for the next day, you give yourself a mechanism for bringing your current day to a close. Thanks for adding that!

I use (for many years!) a modified approach. I embed the notes in the code or document, preceded by a series of question marks (???????). I do this for unfinished sections and the last bit I worked on. When I resume the work, I search for multiple question marks and pick up after reading my notes.

I agree. I end each day by writing my next steps on the back of an obsolete business card and stick it in my keyboard, so I have to pull it out the next day.

Similar to Kent Beck's suggestion of ending the day with a failed test, my motto is: "end every day with a stack trace." (I don't usually live up to it.) This provides two advantages.

First, a stack trace is enough context for me to get back into work in the morning-- and like an unfinished Sudoku puzzle, it's much less intimidating and more engaging (taunting?) than starting completely fresh.

Second, it encourages me to drop what I'm doing at the end of the day and get home on time, even if I'm in the middle of something. (I don't usually live up to that either; but at least my wife is also a programmer who can empathize.) And it reminds me not to avoid starting a new task, just because I'll inevitably have to quit just as I'm getting into it.

@LilShieste:Thanks for your comment. I probably should have mentioned Beck's suggestion explicitly in the editorial. It's one of Beck's few suggestions I disagree with. On two counts: 1) whenever I stop, I want all my unit tests to be passing; 2) a failing unit test in itself is too little information about context. At least for me, that is, it's too little information to reconstruct where I was, what I was doing, and especially, what I was planning to do. This last aspect is even more problematic in TDD, b/c the failing test is supposed to represent the smallest possible increment of functionality.

Your "breadcrumb approach" reminded me of one of Kent Beck's suggestions in his TDD By Example book:

"Finish a solo session by writing a test case and running it to be sure it doesn't pass. When you come back to the code, you then have an obvious place to start."