July 24, 2011 at 2:20 am
Comments posted to this topic are about the item Leave Developers Alone
July 25, 2011 at 4:18 am
One study finds a 10 point IQ drop from regular email and phone interruptions.
BWAA-HAAA!!!! That explains the first 4 letters of "twitter". 😀
It's a trade off. I've found that leaving some developers alone encourages them to "tweet", browse the internet for that new pair of tennis shoes or baby dress, and do other unproductive things. Sure, I agree that everyone needs a break here and again during the day, but not hours-long breaks.
As my boss used to sometimes exclaim... "it's after 10 o'clock... do you know where your Developers 'are'?" 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
July 25, 2011 at 4:40 am
Back at the bank, constant interruptions (developers, change control, management, etc) got so bad at one point that I ended up putting a sign up next to my desk saying what time people could next interrupt me (unless it was something like 'server down' or 'building on fire'). I told the developers about it, told my boss, told my team. Considering that at the time I was busy with a rewrite of some of the core stored procedures for the main system, I needed the uninterrupted concentration time.
There's no need to bug developers every hour or so checking on what they are doing or how far they are. That's one of the things that happens at the 'client from hell' that I had, and is one reason they got that name. If the developers are loafing off, it'll show in their overall productivity, if it does you have words with them (strong ones if necessary).
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
July 25, 2011 at 6:16 am
From meeting-free Fridays, to don't-bug-me blocks of time, we've attempted a number of ways to schedule that pristine, get-the-work-done time.
The real issue is the corporate culture. Co-workers expect you to be able to pick up the phone, have that drive-by chat, or attend that last-minute meeting, your productivity be damned.
If there were some way to represent the cost of such interruptions to the business, they might understand our need to concentrate.
(Housekeeping note: your link to Steve McConnell's technical debt article returns a 400 error.)
July 25, 2011 at 6:17 am
Jeff Moden (7/25/2011)[hr...Sure, I agree that everyone needs a break here and again during the day, but not hours-long breaks.
I think there's a big difference between a "break" and a "quiet time".
In the last department I managed (Estimating and Customer Service), I set a policy that every person in the department got a minimum of 1 undisturbed hour per day. That meant no phone calls, no emails, no interruptions period. During that period a co-worker, our admin, or myself would take messages. We found it improved productivity dramatically and reduced stress considerably.
Now that I've returned to developing, I've found I use any trick possible to grab that quiet time, including scheduling "meetings" in whatever conference room is available.
If you don't think "quiet time" is a good idea, consider the number of times you've heard someone talk about how much more work they got done by coming in on a Saturday versus the rest of the week.
July 25, 2011 at 6:27 am
Ya after those Hello break, lunch break, e-mail break all you need is a work break. :w00t:
Totally agree on the quiet time. I used to work for a client who made it his priority to bug me every 10 minutes. I NEVER got anything done. I would do more work in 30-60 minutes from home than a full 10 hours in-house.
July 25, 2011 at 6:46 am
A few years back I learned of a test that demonstrates the evils of multitasking. It's a way of training people not to say "no" but "not yet". I've shared it with many and will share it here as well...
Everybody knows how to count, the alphabet and Roman numerals. So, lay out the paper in three columns one entitled "Numbers", as second entitled "Alphabet" and the third entitled "Roman". Then instruct the group (that should include developers as well as managers) that they will be timed as they fill in the top 10 values for each column (1 - 10; A - J; I - X). The time trial will be run in two heats, the first time they should fill in the values by traversing the columns (1, A, I -- 2, B, II -- etc.). The second trial they will fill in the columns vertically. Compare the times between the two groups and discuss why they believe one was so completed so much more quickly.
The first trial is a very simple example of multmultitaskingle the second is the more focused sequential task. Explain that the more difidifficult task the more productivity that is being lost. To the greatest extent possible management should avoid situations where a great deal of context switching is required. If possible, make the context switch fall at a natural time (like after lunch or a meeting).
I hope you find this a useful example.
--Paul Hunter
July 25, 2011 at 6:48 am
I had one like that. He finallly quit when I made a point of putting my feet up on the desk and asking him a number of totally unrelated questions.
When he started to spaz out I replied "Based on the number of times you've interrupted me I have to assume you just needed to talk. Now do you want me to work on your problem or just keep on shooting the bull with you."
Not only did he stop bothering me, but he made sure no one else did either.
July 25, 2011 at 6:56 am
Paul Hunter (7/25/2011)
A few years back I learned of a test that demonstrates the evils of multitasking. It's a way of training people not to say "no" but "not yet". I've shared it with many and will share it here as well...Everybody knows how to count, the alphabet and Roman numerals. So, lay out the paper in three columns one entitled "Numbers", as second entitled "Alphabet" and the third entitled "Roman". Then instruct the group (that should include developers as well as managers) that they will be timed as they fill in the top 10 values for each column (1 - 10; A - J; I - X). The time trial will be run in two heats, the first time they should fill in the values by traversing the columns (1, A, I -- 2, B, II -- etc.). The second trial they will fill in the columns vertically. Compare the times between the two groups and discuss why they believe one was so completed so much more quickly.
The first trial is a very simple example of multmultitaskingle the second is the more focused sequential task. Explain that the more difidifficult task the more productivity that is being lost. To the greatest extent possible management should avoid situations where a great deal of context switching is required. If possible, make the context switch fall at a natural time (like after lunch or a meeting).
I hope you find this a useful example.
What were the time differences?
July 25, 2011 at 7:21 am
bwillsie-842793 (7/25/2011)
Jeff Moden (7/25/2011)[hr...Sure, I agree that everyone needs a break here and again during the day, but not hours-long breaks.
I think there's a big difference between a "break" and a "quiet time".
In the last department I managed (Estimating and Customer Service), I set a policy that every person in the department got a minimum of 1 undisturbed hour per day. That meant no phone calls, no emails, no interruptions period. During that period a co-worker, our admin, or myself would take messages. We found it improved productivity dramatically and reduced stress considerably.
Now that I've returned to developing, I've found I use any trick possible to grab that quiet time, including scheduling "meetings" in whatever conference room is available.
If you don't think "quiet time" is a good idea, consider the number of times you've heard someone talk about how much more work they got done by coming in on a Saturday versus the rest of the week.
I'm pretty sure that I didn't get "quiet time" and "break" mixed up, here. I absolutely agree that "quiet time" is essential to being able to work effeciently. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
July 25, 2011 at 7:55 am
Ninja's_RGR'us (7/25/2011)
What were the time differences?
They generally range from 1/3 - 1/2 longer for the context switching. I have one person (a mother of twins) that can context switch like crazy. There were no differences in her times, but she was definitely the exception. All other times I've done this the difference was very noticable regardless of education, gender or position within the organization. As a rule, the higher up the ladder they went the longer it took.
--Paul Hunter
July 25, 2011 at 8:02 am
Paul Hunter (7/25/2011)
Ninja's_RGR'us (7/25/2011)
What were the time differences?
They generally range from 1/3 - 1/2 longer for the context switching. I have one person (a mother of twins) that can context switch like crazy. There were no differences in her times, but she was definitely the exception. All other times I've done this the difference was very noticable regardless of education, gender or position within the organization. As a rule, the higher up the ladder they went the longer it took.
Nice to know... I'll keep that in mind next time I'm asked to multi-task!
July 25, 2011 at 8:43 am
Reading email doesn't necessarily have to involve preemptive multi-tasking. The developer can read and reply as they come in, or he can just let them queue up for a couple of hours and reply when convenient. When I'm really focussed on some issue, I'd rather have someone send me half a dozen emails than drop by me desk once.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
July 25, 2011 at 9:00 am
phegedusich (7/25/2011)
From meeting-free Fridays, to don't-bug-me blocks of time, we've attempted a number of ways to schedule that pristine, get-the-work-done time.The real issue is the corporate culture. Co-workers expect you to be able to pick up the phone, have that drive-by chat, or attend that last-minute meeting, your productivity be damned.
If there were some way to represent the cost of such interruptions to the business, they might understand our need to concentrate.
(Housekeeping note: your link to Steve McConnell's technical debt article returns a 400 error.)
It's definitely a cultural issue, and often a management issue. We don't train managers well, or teach them how to get developers to work better.
Thanks for the note on the link. Looks like the Construx blogs are down.
July 25, 2011 at 9:37 am
Thanks for the important article Steve.
A while back, my boss was good enough to ask if it was too noisy in my area and I appreciated that.
On a related note, I think that this pressure we've had lately to multi-task is largely misguided. Unless you're doing two very simple tasks, it probably won't work. I suppose we weren't very well made for parallel processing. But it's an interesting topic; I've noticed that my wife is able to play Guitar Hero and talk at the same time very well. Me, not so much - I do neither well if I try that!
The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge. - Stephen Hawking
Viewing 15 posts - 1 through 15 (of 43 total)
You must be logged in to reply to this topic. Login to reply