I was working on a project three months ago when suddenly another urgent project appeared and I was asked to shift my attention.
Starting tomorrow, I’ll be heading back to the old project. I realize that I do not remember what exactly I was doing. I don’t know where to begin.
How can I document a project such that anytime I look back it shouldn’t take me more than a few minutes to get going from wherever I left. Are there best practices?
See the full, original question and all answers here.
Keep a daily log
CompuChip answers (26 votes):
I just wanted to contribute some advice which is not going to be useful in your current situation, but you can start implementing it now to help in the future.
Of course there are the obvious candidates such as to-do lists and issue logs; looking at the recently added issues should give you a clue as to what you were doing when you were pulled off the project.
On previous projects I have worked on, people were expected to keep a project log as part of the quality management process. The contents were not very clearly specified, but the idea was to keep a daily log of things related to the project that may be useful for continued work in the future or for review activities on completion. For example:
Observations about the quality of the project
- This code can use some refactoring
- Did a quick implementation to get this to work but _ABC_ would be better.
To-do items / issues that you would not want to formally record in an issue tracker
- “Should make this method work for ‘x < 0′ but that’s currently out of scope.
Design decisions—especially non-trivial ones
- Our standard sort function performs a quick sort, but that does not preserve the order of items equal under the sorting condition, which we need here.
- The obvious algorithm would be _ABC_ but that fails here because ‘x’ could be negative so we need the generalized form.
Problems encountered and how you solved them
- A very important one, in my personal opinion: whenever you run into a problem note it in the log.
- Checked out the code but it gave error XYZ0123. Turns out I first had to upgrade component C to version 1.2 or higher.
The latter two points are very important. I’ve often encountered a similar situation or problem—sometimes in a completely different project—and thought, “hmm, I remember spending a day on this, but what was the solution again?”
When you come back to a project after a while, reading back the project log (whether it’s your own or the latest developer’s) should put you back into the flow that you had when you left and warn you of some of the traps that you may otherwise fall into again.
Jog your memory
Thomas Stringer answers (12 votes):
In my opinion, there are two parts to resuming a code project:
- Determining where you left off.
- Remembering what you have left to do.
This is one of those things that, I think, if you are doing version control the right way it’ll be your “other brain.”
Where did you leave off? As long as you are committing code frequently, look at your last change set. It’ll most likely jog something in your mind. If not, look at the past few, starting with the oldest and replaying commits.
As for what left you have to do, a backlog should serve that purpose (or a to-do list, or whatever you want to name it. Basically items for the future).
I am not a full-time software developer. I’m a programmer that hacks on the nights and weekends. Because of this, when work or other non-programming things take higher priority, sometimes I can go days and weeks without even pulling up my code with a glance. The above has proven to be quite effective.
Learn to love lists
Scott Whitlock answers (58 votes):
To-do lists are magic. Generally you need to keep an active to-do list for each project and even while you’re busy programming, if you think of something that has to be done and you can’t do it immediately, then it goes on the list. Keep this list in a well-known place, either in a spreadsheet, in the text file in the project folder electronically, or in your paper logbook.
Also, whenever you leave the project for overnight (or over the weekend), take a post-it note and write the next thing you were going to do on the note, and stick it to the monitor. That makes it more likely you’ll get back into it quickly the next morning.
I should mention that to-do lists (specifically prioritized to-do lists segregated by venue and project) are a key part of the Getting Things Done book, which I found highly influential.
Find more answers or leave your own answer at he original post. See more Q&A like this atProgrammers, a question and answer site for professional programmers interested in conceptual questions about software development. If you’ve got your own programming problem that requires a solution, log in to Programmers and ask a question (it’s free).