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 werent worth the trouble.
It isnt that they werent 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 wouldnt 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 wasnt 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. Its 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. Ive 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 teams responsibility to deliver solutions built around the companys 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 didnt 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 couldnt 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 wasnt smart enough to figure it out, then I shouldnt 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 couldnt figure it out. I asked about documentation and he rolled his eyes and smirked, What documentation?