Don’t Become the “Guy in a Room”

You’ve worked with him, maybe you are him. He has particular needs when it comes to his computing environment, we’re not talking Hugh Jackman in Swordfish but he has his own room in which to work. It might feature a South Park poster, a shrine constructed of empty coke cans and a somewhat sour smell that defies identification. Amid his multiple monitors and PCE ergonomic chair there’s a USB coffee warmer, USB mini-rocket launcher (aimed at the guest’s chair) and a USB fan to cool the enormous heat generated by his furious keyboard activity.

Sure he’s weird, maladjusted even! But his mind is brilliant, his development skills unquestioned, his encyclopaedic knowledge snaps out honourable and moral judgement on any coding conundrum presented before him. His frequent, rock solid delivery of numerous projects has forged a reputation as a shining vanguard of programming righteousness. He’s forgotten more about development than most of us will ever know!

He’s the guy in a room.

He needs his room, he’s earned his room, his room is an oasis free from the poorly researched questions of less gifted programmers, and of course – quite separate from the annoying interruptions of project managers.

But in the Dynamics of Software Development (Microsoft Press, 1995), Jim McCarthy provided this sage advice: Beware the guy in a room.

He recounts a familiar scenario: you have a particularly difficult task forming the core requirement of your system. The code produced by this task is fundamental to the success or failure of the project. Who do you go to? Your number one guy: the guy in a room. The team sighs in collective relief secure in the knowledge that the guy in a room is applying his awesome knowledge to this most difficult of tasks. Everyone else need only be concerned with maintaining his supply of caffeine and chocolate bars.

Nobody dares check his status; it is enough to glance in every now and then to see him hammering out screen after screen of astonishingly complex code. The project manager marvels at the quantity of the guy’s output, the project must be weeks ahead of schedule by now? He didn’t even need to work from technical specifications, wow that saved a lot of time too!

But as the deadline approaches the mood shifts. The guy is working longer hours, he’s more irritable than normal, the South Park poster hangs limply on its last drying bead of bluetack and the USB gadgets are untidily pushed aside. The odour emanating from the room has at last been conclusively identified as the smell of fear.

Unsurprisingly the deadline is missed and the knock-on effects are catastrophic – all the interdependencies on the guy’s task are put under extraordinary pressure. The team has gone from appearing to be weeks ahead to being unable to predict when the project will finish. There’s virtually no good solution to this situation, the guy is so far progressed that he is the only one who can finish what he started, he can be micromanaged, administered with regular pep talks, fed more caffeine or given resources to work under his direction, but it will come down to everyone waiting until he completes his task.

Even brilliant developers need to be bought into the consensus view of a project’s technical architecture and every detailed technical design needs to be socialised and debated before being approved for the build. And nobody is above having their work scrutinised to peer review at regular intervals.

Don’t let yourself become the guy in a room. You can’t withdraw into your own headspace for days and weeks with the intention of emerging triumphantly at the last minute with the project panacea. Your energy is better spent interacting with your teammates. No matter how experienced you are I guarantee there is something to be learnt from every one of your fellow programmers.

NOTE: I originally wrote this article for publication on apcmag.com, it is reproduced here with some minor modification.