Dysfunctional IT relationship No. 2: Senior developers vs. junior developers
I'm a new software developer for a large company that desperately wants to be on the cutting edge. I'm trying to help them do that, but I keep getting stymied by the graybeards. The senior developers are always reviewing my code, and it takes forever to get approval for even a simple change. They're slowing down the company and, frankly, hurting my career. How do I tell these old dudes to back off without getting fired?
— Young & Restless
Old people -- when will they ever learn?
[ Want to cash in on your IT experiences? InfoWorld is looking for stories of an amazing or amusing IT adventure, lesson learned, or tales from the trenches. Send your story to firstname.lastname@example.org. If we publish it, we'll keep you anonymous and send you a $50 American Express gift cheque. ]
The first thing you need to realize is that maybe, just maybe, your more experienced developers might be right in being a little more cautious about unleashing insufficiently vetted code unto the world, says Joe Masters Emison, VP of research and development for BuildFax, which stores construction records for hundreds of millions of properties across the United States.
"Software is wonderful in that you can do amazing things with it," he says. "So a junior developer looks at Facebook and says, 'Gosh it would be easy to create X because all we'd have to do is change this one thing.' And if Facebook only served five people, that might work. But you may not understand what's required when you've got a large user base and a large body of code with a lot of people working on it."
It's the senior developer's job to contemplate all the terrible things that could happen from one tiny change, he adds. The cost of even one hour of downtime thanks to a small tweak in the code could be enormous.
For their part, senior developers must acknowledge there are scenarios where rules can be safely broken -- like editing code that's already in production -- without causing the sky to fall or the company's share price to plummet.
"There are certain situations where you want to do a live edit of a database -- say, to push out maintenance upgrades," says Emison. "Or sales might come to you and say they have a customer they need to close this quarter, but it requires certain changes to the code. When the risk of anything bad happening is low, you could be better off from a business standpoint to break the quality rules once in a while."
But if you must engage in "cowboy coding," Emison advises you follow the pink sombrero strategy laid out by Joshua Siler, a former VP with marketing firm Babcock & Jenkins who is now CTO at HiringThing, a cloud-based service that helps hiring managers post jobs online and manage applicants. Siler wrote:
Even when it makes sense, cowboy coding is not something we take lightly. Anyone editing code on a production server is required to wear [a] pink sombrero for the duration of the work. Having the pink sombrero on acts as a strong check and balance. Inevitably, the act of donning this flamboyant headwear causes a crowd to form. Lively discussion ensues:
"What do you have to edit? Do we really have to do this? Are we sure there will be no side effects?"
And it works.
Bottom line: As a junior developer, you need to learn more patience, while your bosses need to retain some flexibility. Otherwise, development turns into a fiefdom where hot new talent inevitably leaves and nothing innovative ever gets done.