IMO, the best recipe is to make a habit out of always leaving your projects in a state that allows you to drop them on a moment's notice and pick them up six months later, with very little delay. This means:
- Work in super-short iterations - not months, not weeks, not even work days, but hours or even less. Aim for a working, bug-free, useful build after each such iteration (even if this may mean that the code you wrote in the current session is inaccessible to anything but your unit tests right now: the important thing is that it compiles, passes the tests, and doesn't break anything).
- Document everything you do, while you do it.
- Don't leave uncommitted changes around: commit early, commit often.
- If you have to work on different features in parallel, use feature branches.
- Always leave your code in a readable state. Refactor early, refactor often.
- Write automated tests right now. Automated tests are an integral part of the development cycle, not a separate feature.
- Be consistent. The more consistent you are, the less you have to remember - if, for example, all the getter methods in your project follow the naming convention
getFieldName, and you know you can be 100% sure that there are no exceptions, you never have to look up the name of a getter.
- Be religious about readability.
- Design your internal APIs and libraries according to the principle of least surprise. Less exceptions means less time required to consult the documentation.
- Use a bug tracker, wiki, ticket system, or even a plain old text file, anything that helps you organize and prioritize your thoughts. It doesn't need a lot of bells and whistles, as long as you can easily throw random pieces of information at it and retrieve them quickly and efficiently.
The central idea is "fire-and-forget": Make it so that each project requires minimum brain resources for any given task, and that as much information as possible can be outsourced to your tools - a wiki, source control, and of course the source code itself. That way, the amount of thoughts in your brain that you need to swap out when switching between projects is minimal; ideally, all you need to do is point your development environment (whether this is an IDE or a command line doesn't really matter) to the current project, maybe issue one or two commands, and you'll have all the hints you need to dive back in.