The nature of my job is that I have to switch back and forth between projects every few weeks. I find that one of the biggest impediments to my productivity is the ramp-up time to getting all the relevant pieces of code "back in my head" again after not seeing it for a period. This happens to a smaller and larger extent for briefer breaks / longer breaks.

Obviously, good design, documentation, commenting, and physical structure all help with this (not to mention switching between projects as infrequently as possible). But I'm wondering if there are practices/tools that I may be missing out on. What are your specific practices for improving on this?

6 Answers
6

Because I do development and production support for several clients, I switch projects multiple times per day. The two things that help me the most are never leaving one project until I have saved everything (And commit to a local branch if it isn't in the state I want to put it back to the main branch of my source control) and I set a breakpoint at the spot where I left off. Just being able to quickly find the exact line where I left off, helps me get back in the swing of a project much faster. I also tend to create a todo list for each major project and check things off as they are done, so a quick review of that tells me where I am as well and reminds me of my thinking process on the project. I generally also write a quick note to myself of things that I was thinking about but hadn't done yet if I need to (things like: The XYZ still isn't working, try abcd next.)

Having a project easy to read, with a good design helps, but before leaving a project, make sure all the context and information you have in your head it's written or stored somewhere. For instance, notes about the third party library functions you were using if it was a new one you never used before. I always write notes about the things I learn or think, in my own words.

Also, what I find most important to write in a file is if you write TODO comments in your code, copy the last one you were working on, and paste it in a new text file and call it TODO. Write in it context information about where the TODO tag belong and write what you had in mind or what you think you would like to know about that task.

Leave pointers and hints for yourself in the code, in the form of comments.

Follow KISS and DRY.

Be consistent, within each project and across projects.

Be religious about refactoring.

Document everything; consider your future self a different person with no way of asking your present self any questions.

Avoid "clever" code that breaks your IDE / editor.

Use source control, with commit messages that tell you where exactly you left things; tag versions that you deem shippable, and aim for short periods between shippable versions.

If you get to pick the programming language, choose one that can help you do things right.

This one's a matter of personal taste, but it works well for me, so I'll recommend it anyway: Keep a simple, concise text document containing upcoming tasks, and update it each time you finish a task. Also use this document for design-level notes that don't fit in code comments. Basically, this text document should contain your entire design, only in condensed form (enough information for you to make sense of, but short enough to get you back in the saddle within 10 minutes). A bug tracker works too, but the text document has a number of advantages: it forces you to cut the fluff and focus on the relevant stuff, and it can be committed to source control alongside the real code, which means it is naturally tied to SCM versions.

Consistency is key for code. I don't need to remember where everything is and how everything interacts if I can extrapolate what I would've done. If it is a project with others that becomes more troublesome, but code standards help quite a bit. Knowing what something is by looking at it and making a few safe assumptions decreases the on-boarding time a bit.

Specification is more helpful for design. At least for me, I find that I tend to forget some of the nuances of product design after a break. Or when I return, it is because of this awesome idea that promptly feature creeps into the project. If your project does not have good requirements (either in a waterfall-y spec or a product backlog) you have to basically re-invent these each time you come back to the project. Almost all of the best practices for software development are still best practices when it is a personal project; don't skimp on them.

I switch among different projects (both technical and non-technical) frequently as well. Organization or "ease of retrieval" has been key for me. Before leaving a project, I make sure that I put things in order so that it's easy for me to get the context back in my head. For me, this means putting all relevant things (bookmarks, files, docs, emails, etc) or links to them in one folder so that I don't have to hunt for sources of info.

One thing that I've started to do recently is use one virtual machine for each large project. When I need to switch to another project, I keep all the relevant apps open and then suspend the virtual machine. So, when I need to switch back to the project, I can start the VM up and it will present me with all of the information already on the screen.