I am currently in a role that requires me to concentrate on programming and at the same time, mentor junior devs (read constant interruption). It's very challenging for me to switch gears and maintain focussing on the job at hand. It's not only frustrating but also time consuming. I feel if I master this art of multitasking, I could definitely get more done and be more efficient.
Any suggestions on how you handle situations like this?
Trying to do two things at once means two things:
I'd suggest trying to separate your time better (if you actually have this option). In the morning (or for some predetermined about of time), you work with the junior developers, talk to people, have meetings, etc. For the junior devs, answer all of their questions, get them up to speed on what they need to do and get them to work. After you've dealt with them and any other office-related stuff, put your headphones in and do your work. To the extent possible, try to ensure that nobody interrupts you during this firewalled time so you can be the most effective. I'm sure that if you explain to your supervisor what you are trying to do that he would be more than happy to help you accomplish your goal.
Good luck, I know this is a common problem.
I find it helps to keep a notebook next to my keyboard. When i get interrupted with a question that is going to take more than a minute I write down what I'm working on/thinking. It has helped me get back into the programming mind set much faster.
I don't think there is any silver bullet. Try getting yourself into it gradually - start by setting aside some quiet time during the day for undisturbed hacking, and maybe a Q&A session as well for the opposite. That way you might be able to reduce the number of continuous hours you are fighting interruption.
I've not yet got over this hurdle myself, and I think many people never do. My wife says it's a male thing, we are just not adapted for multitasking
Get your junior devs to write down their issues, collate them and give them a specific times when they can bring them to you. That way you avoid constant interruptions. You can also get them to come up with their own solutions before consulting you so that they have to think about the problems first and so learn better.
I'd try to schedule my time for each function. Assuming that the mentoring is actually that, there should be regular intervals to check-in on what they are doing, how is it going, etc. This doesn't mean constant interruptions as it is just part of your work time that x hours a week goes to improving the work of the junior devs.
On the other hand, if those constant interruptions are because the junior devs are running into various blockers, you may have to take a slightly different approach as that kind of problem can lead to inconsistent performance as one week you may get oodles of things done and another get almost nothing because of all the interruptions. Good luck on trying to find a way out of this kind of conundrum.
if you are on Eclipse, you can try mylyn plugin. it helps in remember the different programming task that you are working on.
Since interruption is the enemy of productivity, I would say this is the most important thing to teach to junior devs.
Babysitting or constantly being the path of least resistance to a junior developer's answer finding may actually be hindering them in learning to think for themselves. They may start to think you have to do the thinking for them.
I'm not sure if there is a silver bullet for all devs but basically you want to make more self-sufficient devs.
Some ideas that I have tried in the past:
- Buddy system. Some guys are stronger than others. If there is one stronger junior dev than the rest, maybe have the other developers ask him first. Be sure to schedule his time to allow for it if it gets to be too much.
- Setup no interruption time. Schedule one or two 3 hour blocks per day for uninterrupted coding. Maybe have half an hour meeting before and/or after. Put the onus on developers to start asking clear questions, have them prepared in advance so their 3 hours doesn't go to waste. Ensure they are held accountable for their deliverable.
- Interrupt respectfully. When we interrupt someone and stick around, indirectly we are saying what they are working on isn't important. If they are to interrupt you during your block of working time, they should follow at least some basic protocol on how to interrupt and how to interrupt with preparations made in hand, before taking up your time. This should be easy, just see what you do when you interrupt someone and what you prepare mentally or on paper before asking. Ultimately they should be bringing you solutions or potential solutions and be ready to discuss the pros/cons of each.
- "I don't know how". This is not good enough. Their mindset should be "I want to find out how". Learning to ask good questions means you can learn to use google properly. There are few problems that haven't been attacked before. If trying to pick a particular approach, they should be able to line up the pros and cons of each before they talk to you and get very quick at it.
- General problem solving. That's all programming is to me. One part syntax. One part problem solving. Learning how to solve all sorts of problems, in general, quicker and quicker makes developers sharper.
joelonsoftware has his take on multitasking - basically that it is harmful.
When I was an intern (akin to being a "junior dev"), I did the same thing with my mentor: constant interruptions. But how was I supposed to know to use "ctrl" on the 3270 emulator rather than "enter"?
So if the developer is very junior/new, it might be worth spending time to develop a sort of curriculum of resources and basic know-how for the project. Dig out the documentation on project filestructure, draw up some graphs to explain data flows, etc. That way the dev can easily map between the concepts and ideas of the project and the code that implements it.
Once they have gotten over that hump, it might be good to have them set up meetings with you - even for small things ("I'd like to set up a 30-minute meeting at 2 just to go over some code and ask questions.") This way, the interruption is planned, and hopefully the meeting will be a good one because the dev has planned and formulated questions and really thought about everything he could before walking into your office.
Maybe the dev can also be encouraged to find out what everybody is an expert in: Oh, John really understands the assembly side of things, Mary takes care of packaging, etc. So that if he has a question about C, he doesn't always run to you, but has a feel for who else can be helpful to him for technical matters. This will make him less dependent on you, and also allow him to interact and work with other members of the team.