Are Cocky Developers Worth It?

Sure, he can code circles around the other developers, but that attitude…
Posted September 16, 2008

Eric Spiegel

Eric Spiegel

(Page 1 of 2)

I was sitting down with one of our most productive software developers for his annual review, trying to carefully craft my words. You see, Tyler had produced some amazing results that year in tackling our most difficult assignments. Praising him was easy… almost too easy.

My conundrum over word phrasing was a direct result of the way he worked with the rest of his peers on the team.

How did Tyler’s teammates perceive him?

The descriptive words I can print were brash, arrogant, overbearing and even cocky. It’s important to consider that these other developers were not in his league, at least not when it came to solving the most difficult technical challenges.

I actually believe the majority of the team was intimidated by Tyler’s technical prowess. To help understand their viewpoint, let’s examine his impact on overall team cohesiveness.

One of the more productive project management tasks this team participated in were peer to peer reviews. In these reviews, Tyler dominated the feedback. He never hesitated to express his opinion, although some might have even considered his views as mostly subjective and sometimes overly aggressive.

I had no problem with this because these code reviews were meant to challenge and enlighten the team, bringing to light alternative approaches. As long as the attacks weren’t personal and everyone acted like professionals, lively discussion produced improved results.

What I was concerned about was that when Tyler participated, the others would clam up. Why? Because Tyler was quick to shoot down their ideas and rarely accepted, let alone objectively considered, opposing opinions.

Tyler almost always prevailed in an argument and when he didn’t, well, it wasn’t with grace. He would generally respond with a tone of snickering like “Fine, do it the stupid way, but don’t blame me when load testing fails.”

And you could be sure if it did, there would be an “I told you so” loud and clear, usually through an email to the team where Tyler would bask in the glow of his triumph – at the expense of team morale.

I had originally decided that as the team manager, I shouldn’t attend these code reviews. This turned out to be a double-edged sword. On the one hand, I wanted the developers to feel free to constructively criticize each other’s work without being afraid of how their manager would react to their honest feedback. On the other hand, when Tyler participated he ultimately had the same undesired effect of shutting down the open expression of ideas.

Finally, I reluctantly decided to sit in on code reviews. This was met with a sigh of relief from all the developers, even Tyler, but for very different reasons.

The majority of the team hoped I could temper Tyler’s aggressive style, while Tyler was happy to show off his talents to the person in charge. Almost immediately, a debate broke out over memory management in a C# application. I believe my presence encouraged a couple of the others to speak up. When Tyler started to snidely cut them off, I decided to step in and stated that everyone should have a chance to finish their points.

Tyler, being a C++ guru, felt strongly that using manual memory management techniques was the most effective approach to ensure unused memory was released. The others weren’t comfortable with this approach and felt just as strongly that automated memory management (i.e., garbage collection) was a more efficient approach for this project because it was written in C#.

Page 1 of 2

1 2
Next Page

Tags: software, management, developers, IT

0 Comments (click to add your comment)
Comment and Contribute


(Maximum characters: 1200). You have characters left.