Tim Gittos

I'm an Australian currently living in Austin, TX in the USA.

I currently earn a living programming, though I wouldn't call myself a programmer. If I had to attach a label to myself, I'd use the term autodidact.

I love learning, and my favorite things to learn about are programming, computer graphics, AI & machine learning, robotics, painting and creativity.

In Defense of the Jerk

Last updated on 29 Mar 2009

Not just any jerk, but the jerk who knows his stuff. The technically strong, socially weak programmer who does not play well with others.

During a recent employee review, I was told that I need to work on a few areas, namely the way I communicate with my co-workers, and my tendencies to shoot down ideas without supplying alternatives. I was also told that my technical proficiency was more than sufficient.

The technically capable but socially awkward programmer is a cliche in every day society, and the rogue programmer is a cliche in development teams. Seth Godin’s post, and another one that cropped up in Hacker News reminded me of this, and made me think. I realised that, to some extend, I am that jerk.

The point of this isn’t to toot my own horn, rather to try to offer an explanation on behalf of all well-meaning jerks in software development teams. Now, I’m not talking about those jerk jerks, who code maze-like code to secure themselves a job, those who are needlessly rude and abrasive, and those that ignore the other members of the team to the detriment of the whole project.

I’m talking about the jerks who are otherwise good employees. We’re not trying to sabotage the project, to exert our will over the project, to make anyone feel bad or insufficient.

We just care about the code.

At least, I do. I care about what I’m doing. I care about the project. I want my code to be the best code I’ve ever written, I want this project to be the most successful project the company has. I own my code, and take pride in it.

When somebody suggests something that I know won’t work, that will negatively affect the quality of the code, I freak out, somewhat. The first thing on my mind is to shoot down this idea, because I don’t want it reducing the quality of the project.

If my manager is planning on putting another programmer on the project with me, and I don’t believe they’re quite up to standard, I’m going to try to limit the damage they do to the application. I’m going to try and push them to work in a relatively isolated corner of the application. Unfortunately, I know this is a bad team work based attitude, however I can’t help it.

Now, I’m not defending jerks. Being a jerk is a bad thing, I know this. I agree with what my boss said, and agree that I need to work on these areas. However, instantly firing the jerk, if they’re a well meaning jerk, is not a good idea, because you’ll lose someone who is passionate about what they do, and constantly striving to improve them.

Instead, just try to work things through, and soften the edges of the jerk.