Software developer behavior | Pluralsight

We’ve all met code hoarders and "heroes." Like basketball players who hog the ball, hoarders work alone, reluctant to share their code, while heroes jump in at the last minute to fix other people's code. These software developers think they're helping, but their actions damage morale, slow down team development, and limit innovation.

Pluralsight developer advocate Jeremy Morgan explored these behaviors in a podcast with DevelopIntelligence CEO Kelby Zorgdrager. Here are three takeaways from their conversation on how code hoarders and heroes impact teams—and how to resolve those conflicts:

A software developer who dives in at the 11th hour to fix other people’s work may get credit for helping a team meet an important deadline. But swooping in like this on a regular basis has a dark side, worse than backseat driving. 

When "someone comes in, pushes you aside, takes over your keyboard and says, 'Let me fix this for you…let me make it better,'" as Zorgdrager said, it can create trust issues for the team. "As a developer, you don’t really want to give up your keyboard. It’s like the steering wheel for your car."

For the person receiving this "help," heroing creates self-doubt. As Zorgdrager explained, it causes developers to ask themselves, "Do I really suck at writing code? Or did I not understand the problem that I’m supposed to be working on?"

As Morgan pointed out, the "hero" might feel good about his or her contribution, but other team members experience an incremental erosion of confidence.

"You know how confidence builds slowly and then starts growing like a snowball?" Morgan said. "Unfortunately, the process works the same way in reverse."

Morgan described hoarders this way: “Someone starts saying, ‘This is my code; this is my section; this is my class method; or even this is my whole entire project. Don’t touch it.”

Why is this problematic? Zorgdrager offered two vivid examples from his own career of how this dynamic plays out. At a startup where he served as interim CTO, the founder and CEO had written a fair amount of the code. “Our CEO still wanted to write code, as well as control and dictate the direction of the architecture and code we were building.”

“In the first six months, we probably lost half of our engineering team,” said Zorgdrager. “The founder wouldn’t get his fingers out of the cookie jar. It was a very negative experience.”

The second company, a telecommunications giant, had engineers who had been there 30 years and weren’t interested in sharing code with new hires. “This was frustrating,” he recalled, “because as a younger person working in the tech field, you want to create something cool. The more senior engineers didn’t want to share the ‘secret sauce,’ limiting innovation.”

Because these behaviors damage team development and morale, coworkers and managers need to speak up. Instead of saying, “Jeremy, quit hoarding your code,” Zorgdrager recommends focusing on how the behavior affects team members. How does it make people feel? What’s the impact on others’ ability to do their jobs? “This approach leads to a more productive conversation than saying, ‘Hey, you shouldn’t do this.’”

Ideally, a meeting like this would happen face-to-face. With so many people in remote work arrangements, however, this may not be feasible.

“In the remote environment, we too often use Slack or email for a conversation that should be in-person or over the phone,” said Zorgdrager. If the topic is sensitive, with a potential for conflict, misunderstanding or hard feelings, you ideally want to be able to see body language. Without this, you are missing an important component of the dialogue.

Zoom isn’t perfect, but a private Zoom meeting is certainly better than making snarky comments in public Slack channels.