This is not intended to be a complete answer—there are already several very good ones mentioning important things like how to use your VCS and your project management software—but rather an addendum adding a few points I did not see in any others, which I find to be very helpful, and which I hope other people might find helpful as well.
1. No task is too soon or too small to write down
People usually make TODO lists for things that they plan to do in the future, but since programming requires concentration, and since we can be interrupted at any time, I've found it helpful to write down even what I'm doing right now, or what I'm about to start in a matter of seconds. You may feel you're in the zone and you couldn't possibly forget the solution that just hit you in that aha moment, but when your co-worker drops by your cube to show you a picture of his infected toe, and you are only able to finally get rid of him by starting to gnaw on your own arm, you may wish you had written down a quick note, even if only on a Post-It™ note.
Of course some other more persistent medium might be better (I'm particularly fond of OmniFocus), but the point is to at least have it somewhere, even if you'll finish in 20 minutes and then throw the Post-It™ away. Although you may discover that that information becomes useful, to put on time sheets or invoices to the client, or when your boss/client asks you what you've been working on and you can't remember. If you drop all of these notes in a box or drawer or folder, then when a big interruption hits—an interrupting project—then you can glance through them and remember a lot of the things you did to get your code to the point where you find it when you return to the project.
2. Use a whiteboard at your desk to capture big-picture ideas
I have a 3" x 4" whiteboard next to my desk, so when I start a project I can brainstorm the solutions to all the problems I perceive in a project. It could be architectural diagrams, use cases, lists of risks and obstacles, or anything that seems relevant to you.
Some more formalized approaches require you to generate diagrams and use cases and so forth as "deliverables" in some paper or electronic format, but I find that that can create a lot of extra work, and just become a series of sub-projects that end up being divorced from the actual purpose of the main project, and just part of a formalized process that you have to do but that no one pays much attention to. A whiteboard is the simplest thing that actually works, at least in my experience. It is as persistent as you want (with a camera) and most importantly allows you to get your ideas down immediately.
I think better with a pen in my hand, so dumping my thoughts onto a white surface comes naturally to me, but if you don't find that to be the case for you, here are some questions that may help you decide what is relevant:
- If I were the lead developer, about to go on a honeymoon for 3 months while other developers completed the project, what general direction would I want to give them? What ideas would I want to make sure they knew about, or approaches would I want to ensure they took? What libraries or other helpful solutions would I want to be sure they were aware of?
- If this project were my million-dollar idea that I knew would ensure my future financial independence, but I was scheduled for a critical surgery that would incapacitate me for 3 months, what would I want my future self to have, to ensure successful completion of the project?
(When I first scribble ideas down, I only worry about them making sense to my present self. Once they are down I can look more critically at them and make changes to ensure they make sense to my future self or to others. Worrying too much about communicating to others as you write them down initially can lead to writers' block—a mind clogged by competing goals. Get it down first; worry about clarity later.)
I recommend you spend the money to buy a decent whiteboard, at least 3" x 4", and hang it up in the space where you normally work. There are many advantages of a physical whiteboard over any virtual system.
- It is large. By taking up a lot of space it makes its presence felt, and the plans on it feel like they are a part of you workspace, helping to point you in the right direction all the time.
- It is there persistently: you don't have launch a certain app or web site to access it, and you won't risk forgetting how to get to it, or forgetting that it's there.
- It is immediately accessible when you have an idea that you want to think through.
You lose many of the benefits if you just use a whiteboard in a meeting room, and then take a snapshot with your phone. If you make money by programming, it's well worth the cost of a decent whiteboard.
If you have another project interrupt the one that has filled up your whiteboard, you may need to resort to the snapshot on your phone, but at least you'll have that in 3 months when the "urgent" project is finished and you have to return to the other one. If you want to recreate it on your whiteboard then, it would probably only take 15 minutes, and you may find you can improve it a lot in the process, which makes that small investment of time very worthwhile.
3. Make stakeholders aware of the cost of interrupting a project
I find the metaphor of a plane helpful: starting and completing a project is like flying a plane. If you bail out mid-way through the flight, the plane will not just sit there in the air waiting for you to come back to it, and you need some way to travel from the current project/flight to the next one. In fact if you're in the middle of a flight from Phoenix to Fargo and you're told that you need to interrupt that flight to take another plane from Denver to Detroit, you'll need to land the first plane in Denver (which is fortunately not far from your flight path—not always the case with real interruptions) and someone has to figure out what to do with the cargo and passengers. They won't just sit and wait forever.
The point of this for projects is that transitioning from one project to another incurs a large expense of time and leaves a lot of lose ends that have to be dealt with.
In a project there is obviously and inevitably a lot that goes on in your head while you work and not every thought can be serialized to a written medium, and not every iota of those thoughts that are serialized will remain when deserialized. Although we can partially capture our thoughts in writing, it is very much a lossy format.
The problem (as I see it) is that project managers and other business people think of projects as a series of steps that can often be reordered at will (unless there is an explicit dependency on their Gantt chart) and can be easily distributed amongst people or delayed until it is most convenient for the business.
Anyone who has done any amount of programming knows that software projects cannot be treated like Lego blocks to be moved around any way you like. I find the metaphor of air travel at least gives stakeholders something concrete that they can think about that clearly cannot be treated as a series of disparate steps to be reordered on a whim. It at least makes it easy to understand your point that there is a cost to such interruptions. Of course it is still their decision, but you want to make them aware of this before they interrupt one project to give you another. Don't be combative, but offer helpful information and the helpful perspective of the developer, ready to do whatever they need from you, but just offering information that they might not be aware of if you don't tell them.
- Write down everything you're about to do, even if you don't think you could ever possibly need it written down. Even a short pencil beats a long memory.
- Brainstorm the big picture on a physical whiteboard that you have persistent access to.
- You might avoid project interruptions if you make decision makers aware that there is a cost to such interruptions, and at least you will have set expectations so they know the project will take a bit longer when you resume it.