I assume you are not using an issue tracker for your project. Else it would be trivial to trace your previous steps.

Finding the latest changes

Finding the file you were working on before procrastinating should not be much of a problem. If you are using a source code management (SCM) tool like Git, reading the history should help. If you aren’t using any SCM or version control system (VCS), you can still sort your files by modification date (here’s how to do this in a UNIX shell).

Remembering your intentions

The difficult part is to remember why you were doing something. If the code is so hard to read that its intent is unclear, I perform static code analysis. I do this the same way I would do it to understand code that was written by someone else. While trying to follow the program flow, I draw UML diagrams (mostly class and activity diagrams, in really bad cases also sequence diagrams). This does not only help with getting to understand the code but also serves as a future documentation.

Avoiding the problem in the future

First of all, if your main problem is that you cannot remember you previous intents because the code is so difficult to comprehend, this is the time for refactoring. It will save you a lot of trouble in the future. If, however, the problem is that you have multiple unfinished code structures and you cannot remember what to finish first, you might want to try one or more of the following:

SCM: If you’re not using SCM/VCS, start doing it. In case of tracking your previous steps, SCM helps you if you keep a clean history (remember the principle: “commit early, commit often”). It also prevents you from irrevocably deleting files (e.g., with UNIX’ rm).

Issue tracker: If all this still does not help you avoiding your problems, start using an issue tracker. There are countless free and light-weight tools available to help you keep track of your changes.

Unit testing: Another method that can help you to quickly find the place to continue your work is to create unit tests. There are frameworks for all the widely used languages (e.g., Java, C, Objective-C, …) and some languages even have a such a framework in their standard libraries (e.g., Python). If you think that unit testing might help you, also take a look at test driven development (TDD). For many developers it seems really weird not to start programming right away but to write tests for something that isn’t there. However, it can lead to a whole new perspective of software development.

If all of these suggestions seem to be too much of an overhead, you could just write TODO comments in your code. This is not the cleanest and safest solution but the easiest and fastest.

1. Run the tests. If I have failing tests then that is probably what I was working on.
2. Diff working copy against revision control. Seeing all the edits I have made recently but not committed usually reminds me of what I was doing.
3. Read commit history. Start looking through version control history at what has been happening recently. That usually points me back at the road map and the next task on the list.

I situations like these I find it helpful to take a look at the use cases and try to map them to the source-code. In other words, pretend you are one of your most important users and think what they would do when using your system. Think about the most important task they would be trying to accomplish with your software, and what steps they would take to accomplish their work. Then, think about how that would be implemented and what parts of the source-code would perform each function. Then you will start to get familiarized again with the code base.

Take your time. Don’t try to know everything at once. Once you learn how a single function works, it will help you learn the next and so forth.

Best of luck.

I used to suffer from the same problem once. Not because my code was so messy, but simply because sometimes one is interrupted for longer than originally planned and thus simply forgets things you didn’t plan to forget initially. A todo list may help, but usually it is not fine-grained enough.

I then developed the habit to leave some small notes to myself within the code, near the place where I planned to continue work. This is not checked into the VCS, it’s only for me. Maybe two/three lines is completely enough to capture the latest thoughs when you leave work.

When you come back later, you simply hit “compile” and the Compiler will bring up the (uncompileable) place in the code, where you left the notes. And that’s the starting point.

It may not work in all cases one can think of, but for me it does.

All I do is I keep a notebook/TODO file, and before I go on a long (>hour) break, I write down what remains to be done. My mind then extrapolates what I was doing before. I always do this, and it never disappoints.

Well, besides whatever disease interupted you, it sounds like you have basically two problems.

1. A lack of version control and bug tracking.  Get one of the many free 
   VCS/bug trackers/project managment.  TFS from Microsoft, git and Jira or 
   or even FogBugz from Fog Creek.  There's a bunch out there, pick one or 
   just try a bunch.
2. Having lost track of what you were doing, you're now in something like 
   analysis paralysis -- and the solution is the same.  Do something.  It 
   doesn't matter what you were working on, it will come back to you if it's 
   important, and you can work on something else important until then.

This is where the project managment tool of your choice can shine — you have bugs that need to be fixed and features to add. You can prioritize them and record which one you are currently working on. Start doing that. Good chance that while you are entering all of your known bugs and desired features, that you will recall what you were doing.

First, learn the lesson.

From now on, write code easy to understand:

• Document it. Tools like Doxygen are very helpful. Actually, Doxygen is helpful even with undocumented code with its capability to draw call tree, caller tree and dependency tree.

• Don’t try to look smart when you write code. Don’t use advanced features just to show that you know about them.

Remember that documentation and simple code are read not only by other maintainers but mainly by your future self.

What has been already suggested is probably useful but in general I would use a separate issue tracking or task management system (such as Jira) for planning and managing your work. There are also additional tools (such as Mylyn for Eclipse) that integrate your IDE to the task management system.