Are Quirky Developers Brilliant or Dangerous?

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…

A little background on Josh first. He sometimes wore t-shirts with offensive slogans. He would disappear from work, some time for days.

More than one female I worked with said that he had made inappropriate comments around them.Yet, he was still there and the highest paid developer.

I decided to talk to Josh. When I went into his office (he was the only developer with his own private office) I could have used a flashlight because it was so dark in there. More like a cave than an office.

A clothespin for my nose wouldn’t have hurt either.

I don’t remember the exact words, but it went something like this.

“Hi Josh,” I said, trying to sound upbeat.

Silence.

Josh continued to type furiously on his keyboard. I continued, “Uh, Josh can I have a minute to talk about our customer issue?”

He kept typing and said, “Go for it.”

“I want to thank you for solving the problem, but I also understand you weren’t willing to help yesterday when my team asked for your help.”

Josh, not looking up from the keyboard, muttered “So?”

“Well, why didn’t you help out?”

“I was trying to meet a deadline,” he said with indifference.

“I understand that, but it would be helpful if you…”

Joss cut me off and said with contempt “Helpful if I explained to a moron how to do his job? I write code. My code works. End of story.”

I’m not sure how the conversation ended, but then again, it wasn’t much of a conversation. I decided to talk to Josh’s manager.

As soon as I mentioned the topic, his manager quickly jumped up and shut her office door.

She said, “Look, you need to back off. Josh is Josh. He is temperamental and he could quit anytime if I’m not fully supportive of him. He puts out code faster than any developer on the team.”

I tried to reason with her about Josh needing to be a team player and to write better documented code. Her response was that any developer worth their salt doesn’t need documentation.

The “code” was the documentation. She ignored the whole “team” comment.

Then she smiled and said, “Let me be clear. If we lose Josh, we can kiss this next deadline goodbye and my job with it. End of story.”

Two “end of stories” in one day. Well, it wasn’t the end of the story. After a few more customer implementation problems the CEO stepped in and forced the issue.

And what do you think happened after the conversation with Josh? He didn’t show up for work the next day. Never even picked up what was left in his office.

He was just…gone.

And with him went his knowledge of the convoluted (brilliant?) code. A lot of very good and even “average” developers eventually cleaned up the mess, but it cost the company a lot of time and money.

Call developers like Josh quirky, crazy or irrational, but there is no doubt that they are smart off the charts. But if you continue to be an enabler, then they can become a danger to your company, team and your career.

Also see: Do Nice Engineers Finish Last in Tough Times?

Eric Spiegel is CEO and co-founder of XTS, which provides software for planning, managing and auditing Citrix and other virtualization platforms.