Are Quirky Developers Brilliant or Dangerous?

A story of a highly talented but egocentric developer, the type we all know and dislike. Can we stop enabling these people?
(Page 1 of 2)

Some of the smartest developers I’ve ever worked with were also some of the weirdest.

You might say that “weird” is a matter of opinion or perspective. Perhaps it would be nicer to refer to them as quirky. But either way, I must say that in retrospect, in many cases they weren’t worth the trouble.

It isn’t that they weren’t smart. In every case, these “great” developers were the most talented in the group. Their intellectual abilities and problem solving capabilities were unparalleled.

There were times when they were the only ones who could solve a problem that could have cost the company millions of dollars. Of course, most of those times were the result of code they designed or influenced in the first place.

It wouldn’t surprise me one bit if they created the impending disaster on purpose, so they could look like a hero.

And unfortunately, in many IT cultures, hero worship is the norm. The same developer who wasn’t quite the team player is now the one who management elevates to the head of the pack.

Should management care? I have written in the past about prima donna developers like Tyler who ignored the rules to the detriment of the team. And yes I believe management should most definitely care because of the impact it can have on the rest of the team, and the risk this dynamic builds up over time to the organization.

The challenge is that managers tend to lean on these brilliant developers as a crutch.

I have been guilty of this in the past. It’s an easy trap to fall into and it takes guts to get out of it because it might cost you your job.

Over the years I have worked with many of these challenging personality types. I’ve picked one as a representative example: I guarantee you that Josh was a real person; however I assigned a different name in case he was truly crazy and might try to look me up.

The first time I met him was my first day managing a crisis on a new job. Josh had been with the company a few years before I arrived. It was my team’s responsibility to deliver solutions built around the company’s software products.

We were all in a conference room with the customer screaming through the speakerphone. He was fed up with the delays in resolving a problem in their production environment and was threatening to cancel the purchase.

So I brought in Josh, who was the developer – more like master mind – behind the code causing the problem. Now typically, no one put Josh in front of a customer because his appearance was, well, like Pigpen from Charlie Brown.

I figured the speakerphone didn’t allow visuals (or smells) so it was okay. And sure enough, Josh solved the problem within an hour. The customer was placated and I was relieved to avert the loss of a customer under my watch.

When I asked the lead engineer on my consulting team why it took Josh an hour to solve a problem that our team couldn’t solve over the last two days, the answer stunned me.

He said “I asked Josh yesterday to help me and he laughed. He said if I wasn’t smart enough to figure it out, then I shouldn’t be working here.”

My guy went on to explain that although he tried to step through the code that was causing the errors, it was so convoluted he couldn’t figure it out. I asked about documentation and he rolled his eyes and smirked, “What documentation?”

Next Page: When Josh gets pushed...

Page 1 of 2

1 2
Next Page

Tags: developer, software, management, IT

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


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