Do you remember a time when a log book was left by a server and you wrote down everything significant that happened?
I know, that is what the electronic logs were for and this technique is “obsolete”. Yet I remember doing this on our test servers when I worked at Novell. The log file on the machine can’t write down things like: “Replaced the NIC card with an NE2000 after repeated system lockup”.
Now, years later, I find myself journalling the day’s activities. Things like: “Wrote a test for the new caching system. The test fails, and part of the system is implemented, need to finish.”
I know it sounds hokey, but it is a tool that helps me drop back into the programming context faster. Most of us have a life outside of programming and the context switch can be easier if we can resurrect the stack. I am only trying to persist my state in my programming context.
Yeah, I know that many would say, just look at the last files you touched, or checked into the source control. But I like the Lewis and Clark feel of having my personal guidebook. I am charting the unexplored territory of new code and I can get lost with all the twists and turns.
So I keep a log book, journal or diary. Whatever you want to call it, a map of where I’ve been in the code and what I want to do next. I do write it with a modern word processor, Open Office Writer to be exact, but the comments are terse and unpretentious like the comments in the old log book kept by the server.
I don’t know if this is a best practice, but I feel that it is a good practice. If you are feeling like it takes you too long to get context on a Monday morning, consider journalling. I hope you find it as useful as I do.