46

On a current job I have two 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?

Improve this question
9
  • for me working on multiple projects is more fit in term 'body shop' which is a bad thing, isn't it?
    – user1449
    Jan 21, 2011 at 11:31
  • The worst part is that I can't stand non-confidence that arises when you're not very experienced in your project. And a situation of having multiple projects to work at, precludes me from gaining strong understanding and that makes me mad, cause I'm being pulled out of my comfort life\work zone.
    – user1449
    Jan 21, 2011 at 14:30
  • don't want to close this question. Just because on my opinion, If you work as a programmer you should provide guarantee that your code your changes won't affect the system. But if you lack of expertise in the system, what guarantee you can provide? Put null check on every 'equals' or other objects method call? - Hell yeah!
    – user1449
    Jan 27, 2011 at 8:58
  • Are you allowed to use collaboration and knowledge management technologies at work? (Examples: Wiki, code review tools, access to design documents, project management tools, personal to-do lists, bug tracking, instant messaging, etc) Without those technologies, working on multiple projects is not feasible.
    – rwong
    Jan 28, 2011 at 13:24
  • Is this question "do more than 50% of companies allow multitasking" or "Is multitasking good or bad"?
    – Martin Wickman
    Jan 30, 2011 at 9:32

19 Answers 19

Reset to default
65
+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 than 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 you should definitely try to determine 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 [with your job], there are other places you can go find work. [You, the developer, are the commodity. Employers know this and pray that you never realize it.]

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.

Improve this answer
8
  • 6
    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, 2011 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, 2011 at 9:23
  • Thanks @Martin. I feel funny how some people don't understand "multi-tasking" being the same as working on multiple projects. I never said coding simultaneously is the same as multitasking where did you get that from @Jeff? Drinking coffee and coding? Are you kidding me? So if you're breathing and blinking at the same time, are you multitasking too??? At least read the whole post geez! The link to Joel's articles has very similar ideas, please read it before putting your comment here.
    – Alex
    Jan 31, 2011 at 4:24
  • 2
    @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, 2011 at 20:06
  • 5
    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, 2011 at 20:08
33

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.

Improve this answer
9
  • 7
    Instead of being an obedient servant and hope for the riches, perhaps be assertive and add value by pointing out inefficiency?
    – Joppe
    Jan 21, 2011 at 18:05
  • 6
    @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.)
    – b w
    Jan 22, 2011 at 21:39
  • It also prevents you from getting bored of the project when that's all you do. I currently have about 100 different tasks waiting to be done, spread over 17 projects. Sure, this does cause some pressure at times but I get unhappy when there's nothing to do besides putting all my energy in one single big project.
    – Htbaa
    Jan 28, 2011 at 13:10
  • 7
    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, 2011 at 20:28
  • 7
    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, 2011 at 22:13
15

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.

Improve this answer
2
  • well, actually what makes me sad is the expertise level I have in result. I just don't have that big amount of memory to remember both systems business and technical logic it seems impossible to me. All the times when I get task, I have to seek and debug very hard, because I don't know that systems well. Am I right that "knowing not much but doing all jobs not very fast" programmer is what a programmer should be, not the "knowing whole system perfectly and fixing in a couple of hours ninja guy"?
    – user1449
    Jan 21, 2011 at 10:34
  • 4
    @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, 2011 at 10:43
12

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.

Improve this answer
9

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.

Improve this answer
2
  • so, you're kind of Shiva-guy? I hardly can imagine amount of your input to that projects.
    – user1449
    Jan 27, 2011 at 9:02
  • @gasan, ridiculous amounts to some. Small, yet often critical, parts of others. And some I just have to maintain because the original dev is gone...and those are the most time consuming.
    – CaffGeek
    Jan 27, 2011 at 14:47
9

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

Improve this answer
4

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.

Improve this answer
1
  • you're right I'm working in a small company now, but previously I was working only for big ones, so maybe it's a part of a cause of a problem, I mean that I unused to work process in small companies.
    – user1449
    Jan 21, 2011 at 11:04
4

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.
Improve this answer
3

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.

Improve this answer
1
  • 1
    Great advice. I take detailed notes and they have come in very handy on more than one occasion.
    – Adam Lear ♦
    Jan 28, 2011 at 4:30
2

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.

Improve this answer
1
  • 2
    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, 2011 at 13:16
0

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

Improve this answer
0

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.

Improve this answer
0

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.

Improve this answer
-1

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.

Improve this answer
-1

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

Improve this answer
4
  • If your job is boring, maybe you should find a different more interesting one, rather than trying to make just part of it more interesting.
    – Asclepius
    Jun 5, 2014 at 3:38
  • I did - but to think every aspect of every job is going to be exciting is naive.
    – cjmUK
    Jun 5, 2014 at 12:22
  • Sorry, but I cannot empathize. As a programmer I find all of my assigned projects interesting, not only in my present job, but also in the one I had before. It doesn't have to be exciting; that's different. There is an interesting spectrum between exciting and boring.
    – Asclepius
    Jun 5, 2014 at 14:37
  • Then I think you are very fortunate... However, I suspect that I'm in the bigger demographic who have to take the rough with the smooth.
    – cjmUK
    Jun 10, 2014 at 12:01
-1

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.

Improve this answer
1
  • how does this answer the question asked?
    – gnat
    Oct 15, 2013 at 8:21
-2

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.

Improve this answer
1
  • We provide 2 separate products and they share a little piece of code. That products are for different user needs, but still they are in the same domain.
    – user1449
    Jan 21, 2011 at 14:16
-2

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

Improve this answer
-2

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.

Improve this answer