I'm a solo developer and have this problem all the time: I develop something, bugfix for a few weeks, hear nothing for a year then they come back and ask for new features meaning I need to get "back into" the project. Some of these are quite sizable projects (for a solo developer), and I've had to develop a way of coping with it...
While working through a project I make these assumptions:
- I may drop the project at any point and not get back onto it for an indefinite period of time.
- If I leave the project without documentating it properly, I'll lose hours or days figuring out where I was before I can actually do work on it.
- I will rarely have opportunity to document it retrospectively to the point I'm confident I could return to it after an indefinite period of time (which for me is the whole point of documentation).
My answer to these problems is to...
- Document very simply in the present tense why each part exists, what it does, and why it does it that way.
- Do this BEFORE I create that part.
The advantages of doing this are:
- Your can pause the project at any point and know it is fully documented.
- If you follow this principle, the documentation is always up-to-date.
- Spelling out "what and why" is an effective way of exposing bad design choices before you make them (have you ever documented something, and as you've written that, thought to yourself: hold on that's dumb, but its too late now...)
- Explaining "what and why" (as well as evaluating against alternatives) is probably more useful in helping you understand the program and appreciate the logic behind it (whether it was designed by someone else, or by yourself in a distant past) than verbosely detailing how it was implemented.
The last point is very important and so easily overlooked: if you don't understand the logic and validation behind the design decisions, or think the logic is flawed, you'll find it hard to stay motivated to work on the project. If you secretly desire to scrap it all and start from scratch, that's a good indication you have this problem. I document my projects not just to remember where I'm at when I get back onto it, but also to ensure I feel positively about it when I do. Do not overlook this aspect of motivation/documentation!
It may help to think of it as documenting as if you were to provide the best handover experience humanely possible to someone who is equally skilled as you, but with no prior knowledge of the project (i.e. you in a few years time).
If you pick up a project which doesn't have this, then buidling up this kind of documentation is a good way to get to grips with the project and to feel positive towards it.