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?

20 Answers
20

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:

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.

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.
–
JeffOJan 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 WickmanJan 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 KnowlsonFeb 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 KnowlsonFeb 4 '11 at 20:08

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,

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.

Instead of being an obedient servant and hope for the riches, perhaps be assertive and add value by pointing out inefficiency?
–
JoppeJan 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 weaverJan 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.
–
AlexJan 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 WickmanJan 29 '11 at 22:13

@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.
–
bogeyminJan 21 '11 at 10:43

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.

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

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:

ensure that it genuinely is an exception, not just a pushy project manager: push back in the latter case.

swap your time allocations so you still work the same fraction on each project.

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.

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.

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.
–
HtbaaJan 28 '11 at 13:16

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

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.

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.

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.