Is it normal for programmer to work on multiple projects simultaneously

Question

On a current job I have 2 projects to work on. First is very huge system and the second one is smaller but it also big (first project is being developed for 12 years, second for 4 years). At first I was working only on first project and was trying to get used to it. Then I was moved to second project and tried there, so my knowledge about first project became shady. Now I have to work on both projects at the same time. It's very hard for me because despite they both use java, they use different frameworks and the amount of code and business-logic to understand is very big so I really can't hold both that projects in my head. Is it normal and I should get used to it, although my expertise became very squashy, what won't happen if I would work only on a single project? Or should I raise a concern or maybe change employer?

Answer 1

I completely disagree when people say "yes, multi-tasking is normal"

It's not normal! Not at all, it's very unnatural for a developer to multi-task in several projects (I'll explain more later on). On the other hand multi-tasking is very common among developers. This is definitely something you should get used to. So the real answer to your question is: how to multi-task?

First of all, you shouldn't simply accept your fate because "you are such an excellent employee" and that means you need to take more tasks that you can handle. Not at all, you don't. Sometimes people are given multiple tasks because there's nobody else. Sometimes managers can't handle their work so they delegate, enforcing multi-tasking on their team because they can't handle their project schedule properly. So definitely you should try to realize if you're being asked to multi-task because it's part of your job or because other people are being incompetent. Either way, you can judge for yourself if that's acceptable or not, if you're not comfortable there are other places you can go find work.

Now about multi-tasking, I disagree 100% when people say "yes, just switch back and forth and make sure you're doing the same amount on each project". Sorry but that's a very bad advice.

First you must realize how your brain works when you're developing a software (I know there are other tasks involved but let's focus on that one). You first need to get "wired", meaning you need to concentrate a lot and get your mind in a position where you have everything mapped in your head. All variable and method names, the workflow of your code, the object model, the threads going side by side, everything. Usually takes me 15 maybe 20 minutes to get "in the zone".

When you get to that state you're really flying off and writing code like you are riding a bike. The moment you get interrupted you can lose it all. If the interruption is long enough (5, 10 maybe 30 minutes) you will lose that state of mind and will have to start all over.

So multi-tasking is terrible because it forces you to leave "the zone" and move on to something else. If you are constantly switching that means you're not being productive because every time you change to a new task/project you need to lose those 15-20 minutes to get in the zone again (not mentioning it melts your brain slowly).

It's like multi-threading: at some point the cost of switching the thread context every couple cycles is too high so the CPU ends up spending more time switching contexts than executing the real tasks.

I highly recommend reading an article from Joel Spolsky on this matter:

http://www.joelonsoftware.com/articles/fog0000000022.html

So my advice is: try learning how to (not) multi-task because it is indeed common. But also make sure you're comfortable doing it. Some people can take more time to concentrate and will suffer more than others when multi-tasking; and that's ok too. It's not because it's common that it should be considered normal.

Joel put it well when he said:

In fact, the real lesson from all this is that you should never let people work on more than one thing at once. Make sure they know what it is. Good managers see their responsibility as removing obstacles so that people can focus on one thing and really get it done.

Answer 2

Yes, it's to be expected. And welcomed.

There are a couple ways to look at this:

1. You are being expected to multi-task and it is nearly impossible to focus. This results in sub-optimal engineering processes, occasional confusion as you switch back and forth, a feeling of being exploited, frustration, stress, etc. This is all negative, of course; however,

2. You are being trusted with multiple projects, which reflects well on the results you produce and the trust your employer has in your abilities. It's an opportunity to show them the trust is warranted.

My advice is to develop sober judgment of which tasks require your immediate attention and which can wait. Sometimes the answer is that neither can wait and you need to take a creative approach to providing results (a little for project A, then a little for project B, then rinse and repeat). Cultivate the skills to thrive in this sort of situation.

Normally (though not always), this will be rewarded with more responsibility, more projects to juggle, and more expectations. At some point you will be able, and expected, to delegate some of this work. It's a measure of success.

So, even if your growing juggling skills are only exploited by your current company, these are good skills to have and will serve you well in your career.

For what it's worth, i'm usually working on a major project, a smaller one, maintenance and support of old projects, and managing at least one other. It's frustrating, confusing, tiresome, and i'm very thankful.

Answer 3

Yes! That's completly "normal"/usual when you work on a service company xD

Also if you collaborate with open source projects, thats the rule

Maybe is not and ideal state, but is the bread of everyday.

Answer 4

It's common. But it's not good, for the reasons that you have outlined. Switching context eats into productivity, so if you can, try to work on one project for a large chunk of time, e.g. a day.

Answer 5

I actively work on 2 to 3 different projects every day. And maintain a few dozen more. Some weeks it gets a little overwhelming. Some of the projects are huge, some are so small they were coded in a few days and rarely need changes. It varies, but it keeps me exposed to different ways of thinking and solving problems, different technologies, and business areas. I enjoy it.

So, to answer your question, yes, it's very common.

Answer 6

It depends on the company. IMO it's desireable to mostly work on one project only, but that's often not possible, especially with small companies.

Of course, bug fixes etc. can always happen with any project.

Answer 7

Check out the article called Multitasking Gets you There Later. This graph tells the story:

In other words, the company is wasting time by having their programmers working on more then one project at a time. With just three projects, the waste is 40%! The the rest of the time is split up across three projects.

The reason for multitasking is often stated as "getting more things done". But that is faulty reasoning. Multitasking only results in delaying all releases. This image shows the effect of dual tasking vs finishing one project at a time:

(The image ignores overhead completely. In reality the wasted time would make both projects 20% later.)

Answer 8

Yes, in my experience that's normal (even if some of the 'projects' are quite similar, e.g. a maintenance and feature project on the same product). To avoid conflicts and unrealistic expectations, agree with the project managers and your manager to allocate certain fractions of your time to each project (e.g. three days on project X, two on project Y per week). You can normally then distribute those allocations how you like, e.g. Mon-Wed on X, Thu-Fri on Y.

There will occasionally be times when one project "throws an exception" and needs to be worked on now. There are two things to do here:

1. ensure that it genuinely is an exception, not just a pushy project manager: push back in the latter case.
2. swap your time allocations so you still work the same fraction on each project.

Answer 9

If you are finding it hard to get back up to speed with a project's framework or business logic when you switch back to it, you should take the opportunity to write as much documentation as you can while you're working on it. Detailing how a complex system works, in your own words, will make it much easier to come back to the project later. Plus, this documentation can be helpful to your coworkers if they ever need to assist.

If the project already has good coverage of technical documentation, it can still be beneficial to write down your thoughts as you're working on complicated areas. That way you can pick up on your thought process the next time you switch back.

Answer 10

Well it shouldn't be normal but I have many projects on my shoulders at my current employer. It takes some getting used to I admit. The most important tip I could possibly give is to always prioritize your work. Force your boss to tell you what is the priority task and work on that only. Don't give into pressure from whoever is complaining about your other projects. You don't necessarily need to update your resume yet but make sure the load doesn't escalate beyond something you can reasonably handle.

Answer 11

IMHO, not only is it usual, but it is also desirable.

The worst development job I ever had was working on the same small section of the same part of the same application for months on end. Tedium. And when you are bored, you take your eye off the ball...

Answer 12

It depends how you describe project. Usually developer work with some problem and if in company is more than one product than you work with multiple.

Answer 13

I think it's normal. The way my job works right now (I'm in a company with about 40 developers, total company size of approx 700). And I usually have one "longer term" project with many small tickets/defects that come up so it usually ends up being 50% small tickets and 50% work on the long term project. What can be difficult is that the constant interruption can slow down and derail the longer term project..

Answer 14

I think it is normal to work on multiple projects. The key is to accept that you will be facing some ambiguity in terms of the overall picture of the system initially.

If you strive to get the bigger picture you will get clarity and be able to spot the moving/fixed parts in the system and how your changes affect the system.

Over a period of time you will learn to find common patterns in the various systems you work on. These you can apply to your other projects which will reduce the amount of granular information that you need to keep in your head at a time.

Answer 15

In any non-trivial project there is more than one person assigned to it. This means that you need to collaborate with others and wait for them doing their work, as well as they need to wait for you.

Instead of having people sitting idle, it is common to have multiple projects active so that there is always an open task to do if needed.

You should still work in sizable chunks on each project so you can get "in the zone" and be productive, though.

Answer 16

I agree with those say it's normal/common.

Look at it as a positive, you'll become more useful, seen as flexible, a go to guy that can get things done! Maybe more valuable as you eventually get to know 2 systems inside out.

Answer 17

Software projects, like love partners, may be many, and good at many, but they are good only if one at a time.

Answer 18

Yess!!! Very normal and very professional!

I currently works on three projects on three different languages!
About me it's a way to don't annoy on a single project and you are more productively!

Answer 19

Adding to what @Martin Wickman said, try to not task switch much. For example work AM on project A, PM on project B. Also say no to adding features; that is more painful when you aren't working on the project full time.