When you interrupt the work on some code (be it because you have to work on something else or go on vacation or simply because it is the end of the day), once you close that Visual Studio project, what is your preferred way to remember what you want to do next when you start working on that code again.

Do you set a Visual Studio bookmark or do write down something like // TODO: continue here next time? Maybe you have a special tag like // NEXT:? Do you put a sticky note on your monitor? Do you use a cool tool or Visual Studio plugin I should know?

Do you have any personal trick that helps you find the place in your code where you left off the last time you worked on your code?

  • 3
    Some IDEs can be set to remember that last files open, and the scroll-to position in those files. Commented Feb 25, 2011 at 17:14
  • 8
    // GOT TO HERE. (Also, who closes their IDE?) Commented Feb 25, 2011 at 17:19
  • 2
    Vim will remember where you were in every file when given direction to do so in ~/.vimrc Commented Feb 26, 2011 at 18:32
  • Eclipse opens all files I had open when I closed it, at the very same position. If that doesn't help, git status git diff` and git log are your friends.
    – Ingo
    Commented Mar 17, 2013 at 10:11
  • Emacs will do this if you enable Save Place: emacswiki.org/emacs/SavePlace Commented Sep 16, 2013 at 11:02

21 Answers 21


I fix whichever unit tests aren't working. If they are all passing, then I write a new one.

  • 1
    Worth pointing out the logical consequence: intentionally leaving a failing test when you finish for the day is a good way of reminding yourself what you wanted to work on the next day...
    – Jules
    Commented Mar 17, 2013 at 12:07

At the beginning of each day, I have a text file called Todays Goals.txt, and then each day, I add the date like this.

Friday 02/25/2011 Goals

Then I write down each project I am working on, and what I have to get done today, or to complete it.

Then at the end of the day, I write down stuff to be done tomorrow.

This daily process helps me remember exactly what I need to do, and make sure each day is well planned.

  • 2
    I do the same, but just write it on my notepad with a pencil
    – Zachary K
    Commented Feb 26, 2011 at 16:45
  • I do it with a notepad too, and every week I get rid of the old page and start a new one. Commented Feb 27, 2011 at 16:43
  • 1
    I keep all my goals for every day, gives me a historical look all the work I've done, and let's me review what I've contributed to the company.
    – crosenblum
    Commented Mar 1, 2011 at 16:32
  • The tomboy addin "Note of the Day" is very good for this, you can set up a template with a heading like "Today's todos". You can then start each day looking at the previous day's notes. live.gnome.org/Tomboy/PluginList
    – Tim Abell
    Commented Feb 22, 2012 at 9:38

Basically I never forget what I am working on. Visual studio pops open at the last file you were working on anyhow, or, I never close down Visual Studio at all and just hibernate.

I place NotImplementedExceptions at abstractions/implementations that aren't necessarily important to continue developing what I was working on.

I do place a lot of TODO's in my code, but not as you stated. I place them where I know a certain approach would be nicer/more performant, but not necessary at the moment. This gives a nice indication for myself and future developers as to where there is room for improvement.

Using Visual Studio's Task List, you can easily view all the places where you left these indications, and you can even add custom ones.


"HACK:" is also nice when you write something which works, but you aren't happy with at all.

  • But what if you stopped working on the project (for a longer time) because you had to work on some other project.
    – bitbonk
    Commented Feb 25, 2011 at 17:20
  • 1
    @bitbonk: I wouldn't stop working on a project, right in the middle of implementing a certain function. Not even a class probably, so there is no "here". Commented Feb 25, 2011 at 17:21
  • Well, lucky you! :)
    – bitbonk
    Commented Feb 25, 2011 at 17:24

At the end of each day, I write in my workbook about what I have accomplished that day, what I expect to accomplish the next day, and things that are left to do.

At the beginning of each day, I refer to my notes from the previous to refresh myself with what I need to do. Then, I spend a few more minutes making more notes based on what has happened since I left to figure out what else I need to do and what my priorities are.

I find this helps me unwind and let go at the end of the day and ramp up at the start. Additionally, when it comes time for annual or quarterly reviews, I just have to refer to my workbook to determine what I had been doing over the review period.


I use Productivity Power Tools for VS. With that I can pin tabs and group them. =D That way I never forget what I was working on.

Besides that, I also add lots of // TODO's to my code.



In one of the interviews in "The Masterminds of Programming", (I think it was Guido van Rossum, creator of Python) the interviewee said that he added a //HIER like comment at the place he finished last time. "HIER" is Dutch (?) for here and he choose it because if searching for that string it is unlikely to find other occurances

  • "HIER" (german)
    – bitbonk
    Commented Feb 25, 2011 at 17:15
  • "HIER" also in dutch, not "HEIR" Commented Feb 25, 2011 at 17:19
  • 3
    //HIERARCHY DOCUMENTATION ...oops! Commented Feb 25, 2011 at 17:30
  • @Mason: A "whole word only" search will avoid that problem.
    – dan04
    Commented Feb 26, 2011 at 17:17

By far, my favorite way is through TDD. It's quite obvious where you are when your test suite fails.

But, not all projects allow for TDD, so I tend to break the code with an uncommented, comment of where I left off.

// Some Comment

Becomes Some Comment // Which Produces Some Fatal Error

That fatal error ensures I don't leave that code untouched prior to releasing it.

Lastly, I can always check my vcs to see what's been changed since my last commit and that'll give me a good idea of where I should be going next...


I use two very sophisticated modern techniques with a very steep learning curve:

  • Do not turn off your computer. Just go home, and the next morning you'll see on the screen the exact place where you stopped hacking yesterday. But risks to lose your checkpoint are much higher if you leave for a vacation.
  • Leave a compile error, and check out to another branch. So your, say, C++ code would look like this:

    for (i=0; i<N; i++){
      int j = i + oh, no, my boss wants me to fix text on the front page!
      why? why should I do it?  Jimmy could have done it faster, but
      of course, my office is closer to the boss', and he doesn't want to
      take longer walks, that lazy fat bastard...

    This way the project won't build when you turn your computer on, or get back to the branch where you were performing active development. Your compiler will show the exact line and file where it encountered your rants.

These techniques did help me recognize the place I left development at, as well as are backed by comprehensive studies and experience of many programmers throughout the world. I suggest you to try them out.


This is now an integrated feature in Visual Studio 2012 where you can suspend and resume your workspace. Suspend will take a snapshot of your open files, breakpoints, watch list, work items etc. and resume will bring it back. Basically your entire work context is saved and will resume exactly as you left.

A short video showing the feature is here


My current preferred whay is the special // NEXT: tag. Together with the ReSharper's TODO explorer it is very easy to discover and maintain.


I keep a development log for each iteration in a non-built docs subproject in visual studio; the last line in the log is always the next task.

i also don't close visual studio very often, just put the computer on standby instead


To find what I need to come back to immediately, I usually put a comment in:

//TODO: figure out why the widget doesn't unfrob properly

I surround it with blank lines, and it draws my attention easily when I see it again. For longer-term issues that I'll need to come back to eventually, I use a Delphi compiler directive that allows you to emit messages while compiling:

{$MESSAGE WARN 'This method is not yet implemented'}

Not sure if other languages can do that...

  • In c, #error fills the same need. Java doesn't support it out of the box, but you can add a compile-time-processed annotation to your project: it's a bit of work to set up, but relatively simple to use once you have done. I'm sure there are similar approaches for other languages...
    – Jules
    Commented Mar 17, 2013 at 12:12

TODO lists don't work when we're talking about coming back to a project from months before. Comments in the code don't work well for me, it's just too easy to ignore or to remember whether or not I completely finished project X and should search for todos first. And if you have a larger team with each person having their own TODO phrase...ugh.

Since my day starts with update/merge/build, something I've tried on occasion is to put an intentional compile error in a file (but not check it in). Unfortunately, I stopped doing this after I had a impromptu office drop-in that wanted to see a demo of something I worked on the week before. "Here, let me just open this...hold on...what does that mean...ok then..."

So, I moved from that to writing an intentionally failing test case.


I leave emacs with the code I was working on up on-screen for the next day.

Sometimes I write a non-compilable note in the code telling me what to do next.

For a really complicated widget where I'm liable to be confused about things, I'll write notes to myself in a notebook or as comment.


If it's just to keep my place in a file while I follow up on a search, I sometimes abuse breakpoints.

To keep track over the weekend of where I was, I leave myself a note with the number of the bug tracker issue.


Are you using a version control system? If yes, then you should commit your changes at the end of the day and describe what you did and what you need to do next in the comment. And if not, then why aren't you?

  • 2
    -1 Never commit just to commit! What if you weren't done with what you were doing? Even if you are using DVCS, its still a nuisance. Commit based on logical change, not day. Commented Feb 26, 2011 at 18:39
  • I respectfully disagree. You should commit often. If you weren't done, then you should create a temporary branch, and commit to that, so that you don't break the trunk. Later when you are done, you merge your branch back. Committing at the end of the day also creates a backup of your work, in case your computer dies.
    – Dima
    Commented Feb 26, 2011 at 18:57
  • But including what you intend to be the next day is an abuse of commit messages. Remember that those messages are supposed to form a log useful months down the line.
    – Ben Voigt
    Commented Feb 26, 2011 at 19:24
  • @Ben Voigt: as I said, if you have to stop your work in the middle of a task, then make it a separate branch. Then your commit message will only be on that branch, and not on the main trunk. Besides, what you intend to do the next day is a very good description of the current state of your code. It just might be useful months down the line.
    – Dima
    Commented Feb 26, 2011 at 21:55

I just don't close Visual Studio and hibernate Windows on the end of the day.


I'm one of the few who reboots nightly (Still on Win XP at work and I just feel it performs better.), so I create an outlook task with a reminder set for the next morning. I may put file name, a copy of the line of code or enough of a note to let me know what I was doing.


Several things help:

  • I look for the text "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" which has the benefits that code can't run (whether it's compiled or interpreted code), so I can't miss it. Also, that tag is bright red for me thanks to synesthesia, so it's really easy to spot it even in a large chunk of code.

  • The IDE reopens the files at the location where each was open (and which lines were highlighted/breakpoints), so I can quickly remember what I was doing.

  • I can see in my todo list what problem I was attempting to solve / feature to implement.

  • +1: I absolutely loved this: "Also, that tag is bright red for me thanks to synesthesia ..." Commented Jun 6, 2011 at 18:28

Since you didn't say that you need to code to actually compile in both debug and release, one trick I often do is:


Very tough to forget that. Otherwise, I would put a #pragma warning in the code so that it appears whenever you compile.


I use several tricks:

  • Place @@ in code comments or in a document for things that need to be done in the current iteration but not immediately. No code or document leaves my machine if it contains @@.

  • That one specific place that I need to contine on working tomorrow morning I mark with @@HERE. This is seldom necessarry because my IDE will open where I close earlier, and you can even tell Word to do so.

  • All things that should be fixed/added later go into a proper bug tracking system or are in design documents.

And are you sure your Visual Studio cannot remember the last location your were working on? "Suspending Work with Visual Studio 2012" says it can be done in 2012 (Google for Visual Studio start "left off")

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