Well, I have some problems with procrastination and whatnot, but those get infinitely worse, when I cannot remember what I should be doing.

I mean, I know my project, I wrote 100% of the code so far, and I knew more or less what I was doing, but I don't remember exactly what, I don't remember what file I was editing and why.

How I get back on track? (because right now my technique of opening the source code and staring at it is not working)

  • 1
    You were editing the file to accomplish something you had to do. Maybe a todo list is in order?
    – Mike
    Oct 29, 2013 at 14:57
  • 2
    There is no to do list... The code was interrupted by disease, ie: I got a disease and had to not work for a while, when I returned the code was not even compiling. I fixed the compilation error and now it runs, but I don't remember what I was doing. Neither how to prevent that from happening again. (and in the past this happened a lot... one infamous project of mine I spent weeks not knowing what to do, coupled with burnout back then)
    – speeder
    Oct 29, 2013 at 14:59
  • For the future use a version control system from the beginning on; any vcs will do, git, being a distributed vcs, is quite portable without central repository. // Otherwise look at modification timestamps of files. And maybe you made backups (zips) to do a side-by-side compare in WinDiff or so.
    – Joop Eggen
    Oct 29, 2013 at 16:34
  • I use one :) It is just that this particular time like I said, I got interrupted in a unexpected way and my git ended being a mess. Although now that you mention it, I will re-read what I was doing on git! That is a nice idea!
    – speeder
    Oct 29, 2013 at 16:38
  • @speeder - I write myself notes personally.
    – Ramhound
    Oct 30, 2013 at 12:29

8 Answers 8


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
    I would add writing unit tests to this list. Oct 30, 2013 at 6:39
  • Thanks for the suggestion. I've edited my answer accordingly.
    – sfat
    Oct 30, 2013 at 8:47
  • Too bad test driven or unit tests do not apply to the sort of stuff I make. I already tried it, a couple times, but they waste too much time to write, and don't test much.
    – speeder
    Oct 30, 2013 at 12:53
  • Test driven design and unit tests apply to all sorts of stuff, what could you possibly be writing where they wouldn't? If they are taking too long to write and not testing much the issue is with you not the tests.
    – Mike
    Oct 30, 2013 at 14:41
  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.
  • 1
    That's one massive argument supporting TDD. :) Oct 30, 2013 at 8:58

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.

  • 2
    Totally agreed. This could be a Word document (or even a simple text file) on your desktop. Sure, you have all your project management tools and bug tracking systems and so on, but I think what we're talking about here is flow, is it not? I don't think the big over-arching tools help so much in that respect. Don't over think it. :-) Nov 3, 2013 at 19:54

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.

  • That's all well and good, but I have the sense that the OP's question is really more related to interuptions to flow, not overall project management or bug lists, et al. Have a look at this comment for some really helpful advice in that regard. Nov 3, 2013 at 19:52
  • @craig: in a comment, the OP said "There is no to do list... The code was interrupted by disease, ie: I got a disease and had to not work for a while, when I returned the code was not even compiling. I fixed the compilation error and now it runs, but I don't remember what I was doing.". That doesn't sound like flow to me...
    – jmoreno
    Nov 3, 2013 at 22:12
  • Fair enough to a point. But from my own experience, I feel like it probably still applies. I've had projects where I've been pulled off task onto something totally different for a couple of months, then coming back I've been able to reference my on-the-fly notes and get back in flow. Yes, there are source control and bug tracking apps in place. But there's a "flow" thing going on in an individual's moment-to-moment process that gets cut off, and the bug tracking system can't easily give that back after a period of time off. I guess that's what I mean by flow, in this case. Nov 4, 2013 at 16:55

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.