Managing interruptions with increased seniority...

Question

As developers advance in seniority, they are more frequently the "go-to" person for questions from business people, other developers, and other teams.

As we know, interruptions have a devastating impact on programming productivity.

How do people deal with this? Do you give up on the idea of writing code yourself and see your job as a mentor/point-person for the other staff? Do you just set up "office hours" when questions are welcome and other hours when they are not? Try to find a work environment with more self-sufficient developers? (I had someone with the same title I have aske me how to debug a program last week).

Answer 1

I am really struggling with this too. One thing that I realised is that if I do not make myself available at all times to the team, then bad code starts to get written and technical debt accumulates.

I've therefore taken an active decision to write less code myself and spend more time helping out my teammates and reviewing their code.

Answer 2

Personally, I think an approach that involves several of the ideas you mention is best - and I actually believe that working with people you have to mentor is good for your own knowledge and finding those edges of it where you might not know as much as you think. There are times more junior developers will ask questions you may have never thought to ask, and you find that your knowledge can grow if you allow yourself to recognize your own inadequacies.

I would tell them that if they run into something they can't figure out to wait until the top of the next hour and then give them a few minutes. Hopefully they have something else they can work on until then - if they don't, let them struggle with it until that time, they will either figure it out themselves or understand the problem even better so that when you go to help them, things will work out better.

Answer 3

Office hours works well for me. Stack Overflow is less helpful I'm discovering.

Answer 4

Teatime.

It's a civilised ritual in the Commonwealth, whereby one makes tea with ones co-workers.

You're already not coding, so no hit.

Of course, for some of us ,there are six teatimes in a day.

Answer 5

Well, I spent a over a year recently working in a job that was extremely high energy and high stress. There are a few tips that I think are helpful: check your e-mail only once ever couple of hours. You can write e-mails as much as you need to, but don't let yourself look at that Inbox & get distracted. As for face-face or phone contact, if you're using Outlook I recommend that everything be handled via meeting requests. You can block out your time better, give people's questions your full attention, and maybe-just maybe-in the intervening hours till the meeting they'll figure out the answer themselves.

Those are my tips for how I managed to actual write code & get things done when there was a plethora of phone calls, e-mails, & personal questions.

Answer 6

Headphones man, headphones.

Answer 7

The company I work for has a large open-plan office, with pretty much everyone in the same room - developers, QA people and BA people.. It's a smallish company.

So I have the same issue with people interrupting my coding with questions and requests.

What we have been using for a little while is "do not disturb" signs on our desks, which can be flipped when "in the zone", and flipped back when you don't mind being disturbed (as much). They mostly work for us, when people obey the signs of course.

The other thing I do is to encourage people to email me instead of phoning or face to facing - so I can respond later at my convenience (but I try to get back reasonably quickly).

Answer 8

Do what you are passionate about and focus on where you add most value. For some people this will be coding, for other it will be teaching or mentoring.

I would also:

• Time box certain activities like reading email (Rescue Time can be helpful here to identify where your time is going)
• Use stand up meetings to disseminate information and give people the chance to ask questions at a specific time
• Document things that you get asked frequently and point people in the direction of the documentation
• Allocate time daily to train people around you, the pay back happens quite quickly
• Learn to say "no" to requests for help when it is not convenient for you and arrange a time when it is

One interesting phenomenon I have noticed is that people who often complain the most about being interrupted also enjoy the sense of importance they get from being the "go to" person and are reluctant to do any of the things listed above to get themselves out of that predicament.

Answer 9

If you have flexibility in your working hours, I think that there's a lot of benefit from coming in early or staying later than the usual working hours -- less people around and less interruptions.

My boss begins work around 7 AM or earlier, a good hour or two before people have enough coffee to ask annoying questions. It seems to work for him.

Answer 10

I find myself in the very situation you describe almost every day.

We use the outlook calendar pretty religiously here. I've found if I really really need to cut some code, I block myself out in the calendarand turn off the phone - but that's not really ideal. Something akin to shutting your door!

We have three developers in our small team and we have initiated a roster system, afternoons only, where the sales and support staff know which developer has made themselves available for interruptions. They ask them for help. The name of the developer available for tech support is displayed on our metrics display(a monitor in the common area) along with several other key things.

It works well because I find when devs are prepared for the "annoying tech support interruptions" ahead of time, they cope with them more pleasantly. Also, most "emergencies" can "wait until lunch time when a developer will be available to help".

As lead of the dev team, any more urgent "bush fires" are still brought to me however - that just goes with the territory.

Answer 11

Don't be a go-to guy!!! After you build anything new for your team, you will be the go-to guy for that component. You should immediately try to transfer knowledge of the system to your teammates -- if you don't do so, you will become a blocker, and will slow down your team's progress as requests and questions are routed through you.

The best move you can make is to try to educate your teammates about the mystery feature. One of the best ways I've found to do this is to give them some smallish bugs to fix -- fixing (non-impossible) bugs is a great way to learn code. (Of course, make sure you fix some of their bugs too! :-)

A lot of people like being a go-to guy, because it looks good to management, boosts their self-esteem, etc; however it's ultimately detrimental to the team's performance, which is what everyone should be focusing on.

Answer 12

I make it a known fact that morning is for coding and if anyone has questions, they can catch me in the afternoon. It forces people to skip the current problem to work on other piece of code. In the mean time, their subconscious will digest the problems and reformulate their question to one that is easier to understand.

However, interruptions still occur when the production line suddenly goes offline because of a bug. This is when I attempt a task switch, much like a computer. I open up notepad (or piece of paper) and write down the most recent thought that is still fresh in my mind. I then add a piece of comment in my source code //You are here Sept xx 2008. Basically, performing a memory dump while politely asking the person who interrupted me to give me 1 minute.

I am with the mindset that if your team succeeds, everyone else does too. Once you get senior enough, it's not just your programming skills that will get you promoted to the next level.