- Last Friday, I was wrapping things up at work before leaving the office. Among other things, I had just finished refactoring some code, and I was going through all my changes to make sure my XML comments were accurate. After a lot of typing, Visual Studio crashes on me before I save the code file. When I opened it up again, VS recoved part of the changes, but not all of it. That was frustrating because I had put though into what comments I was going to write, but then I remembered TimeSnapper was keeping track of my actions, so at least I was able to go back in TimeSnapper and see what comments I had come with. At that point in time, I liked retyping comments much better then rethinking what to type. 🙂
- Yesterday I was writing some code, test-first style, and there was a point one the specific test I was working on ran successfully. Then I’ve changed a few things and got distracted by something else. When I came back to the code, my test was failing, and I could swear I had seen it running successfully before, but then I started questioning myself: "was it really running right, or was I overlooking something?". And if it was running, I couldn’t remember what I could have change that could have broken it. Well, I went back to TimeSnapper again, to replay that point in time; I was able to see that the test was really working fine at some point, and I saw what I had changed that caused the test to fail.
- Usually before I wrap up the day, I leave some notes on my computer (in OneNote) as reminders for myself as to what was the thing I was working last on the day, so that next day I know where to start from. Well, I’m using TimeSnapper for that now.
I’m starting to think of TimeSnapper as a good tool to help me getting back on track after switching gears from one task to another, or helping me understanding what paths I’ve gone through to come to a specific conclusion. For instance, when I’m writing code I’m trying out different things, and eventually I’ll settle down to something that I like, and probably will refactor the code. By playing back (at fast speed, of course) the moments as I’ve worked through the code, it gets easier for me to understand why I’ve taken some design decisions, and what I should put on the comments to better document the code.