Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

20 Answers 20

up vote 36 down vote accepted
+50

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.

share|improve this answer
3  
Having several project going on at the same time doesn't mean you code simultaneously. That would be multitasking. Expecting to have one project at a time may be preferable, but is just dreaming about La La Land. –  JeffO Jan 29 '11 at 22:39
1  
+1 Excellent. If companies realised this they'd be doing much better. Some do though, and thats where tomorrows winners are! –  Martin Wickman Jan 30 '11 at 9:23
1  
@Alex - @bjarkef and @Jeff are absolutely right; having two projects != multitasking. Joel's post and your writeup about multitasking being expensive and wasteful are correct but they aren't necessarily relevant to working on multiple projects. –  Nick Knowlson Feb 4 '11 at 20:06
2  
For example, let's say that you decide to work on the two projects on alternating days. Where does the cost of the context switch come in here? And how does that interrupt being in the zone? It could be the case that gasan is constantly being interrupted by emergency bugs with the other project, or even emergency bugs on the same project. That's where multitasking becomes an issue, but it is not inherent to having two projects to work on and is often a problem even with just one project. –  Nick Knowlson Feb 4 '11 at 20:08

I understand how you are feeling, it is hard to make new employers understand the development processed involved, especially if you employer is not development focused.

The issue is they see 3 Jobs being worked on together more of a money maker than 1 at a time, and the statistics show 40% decrease in performance. Thats 40% loss in profit..

I have previousley worked for a orgonisation that allowed me to focus on 1 large project at a time with small jobs in between, tickets and support etc. We worked on a deal where 8:00-10:00AM was Ticket and support for current systems which come through via email / phone / helpdesk then 10:00 - 16:30 or your finish time was full solid development. This worked extreemley well, because we had a helpdesk to take the calls and emails, I was able to do the tickets in the morning and develop the rest of the day. The issue is if you have poor management. A manager makes all of this happen, and without their support or understanding of the challenges you face daily they are ignorant to the fact.

I have been thankful especially in my last job of the support and understanding from my manager, it made my life easier, less stress and we still got ALL of the work done..

Another issue is, Boss's love money, they see projects in money, When they have 5 Projects for £20,000 all on at the same time (and you are a solo developer) thats £100,000 in the books.. Looks great on paper but can damage company reputation when these are not met, deadlines are missed and systems are buggy because of lack of concentration.

I sympathise with you completely, Im in your position right now.

share|improve this answer

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.

share|improve this answer
2  
Instead of being an obedient servant and hope for the riches, perhaps be assertive and add value by pointing out inefficiency? –  Joppe Jan 21 '11 at 18:05
4  
@Tungano - in no way am i suggesting being "an obedient servant," but rather that being given multiple concurrent responsibilities is a natural side effect of being good at what you do. People tend to rely on those who can make things happen. Handling several responsibilities is not necessarily inefficient, servile, or obedient. If you (or @gasan) can't handle several things efficiently, then by all means let your employer know so they don't make the mistake of thinking you can. (FWIW, i didn't say anything about riches.) –  bill weaver Jan 22 '11 at 21:39
4  
I strongly disagree with this answer. Multi-tasking is not a measure of success it's a measure of incompetence of your manager. Knowing how to multi-task isn't that easy. PS: I posted an answer myself but it goes to the end of the line. –  Alex Jan 29 '11 at 20:28
4  
This answer makes no sense. It is "normal" in a sense that many companies forces programmers to it, but it is still a waste of the company resources. If they were to focus on one thing at a time, it would be finished much faster. –  Martin Wickman Jan 29 '11 at 22:13

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

enter image description here

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:

enter image description here

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

share|improve this answer

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.

share|improve this answer

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!

share|improve this answer

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...

share|improve this answer

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

share|improve this answer

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.

share|improve this answer
1  
Great advice. I take detailed notes and they have come in very handy on more than one occasion. –  Anna Lear Jan 28 '11 at 4:30

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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..

share|improve this answer

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.
share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
1  
Indeed, force your boss to tell you what's important. Communication is very important and when not maintained it can cause a great deal of frustration and disappointment to either party. –  Htbaa Jan 28 '11 at 13:16

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.

share|improve this answer
3  
@gasan We would all like to work on "one thing at a time". However, working on more than one project, reading other people's code, and dealing with varying requirements is the path to ninja-hood. –  bogeymin Jan 21 '11 at 10:43

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.