Embrace quirks when working with others

For me, learning to work with people was a two-step process:

  1. Realize that other people are different from me. And I don’t just mean that other people just act differently. I mean they are completely different with different motivations.
  2. Realize that this is actually a good thing.

It seems to me that Derek Sivers has learned the first lesson, but I’m not sure that he’s learned the second. When we realize the first lesson, most of us try to avoid the issue. If people are different, the goal must be to suppress those differences. Unfortunately, people just don’t work that way. David Keirsey would describe this as a Pygmalion Project.

For those of you who aren’t familiar with Roman Mythology, Pygmalion was a sculptor who could not find the perfect woman. Solution? He sculpted one. Venus was touched by this story, so she turned the statue into a real woman.

This is a cute story, but it parallels reality more than we realize. Like Pygmalion, when we encounter someone who’s different our first instinct is to shape them into something that’s the same. Keirsey talks about this as the downfall of many relationships: we go to great lengths to find somebody who is different from us, but then we try to make them into ourselves. Of course Derek shows that one can have a Pygmalion project on themself. If we view ourselves as abnormal, the solution is to be more normal.

This tends to have the effect of lowering one’s self esteem. No matter how hard you try, you can’t make yourself be something you’re not. If you try to suppress your quirks, you will either fail or become a mediocre version of what you perceive as “normal”.

I would argue that not only is it not feasible change peoples’ personalities, it’s not preferable. Your quirks are what make you unique, and they are the reason your coworkers need you. Quirks are different ways of looking at things. Rather than suppress them, learn to appreciate them. Most importantly, become proud of your quirks. Other people may not understand them, and that’s the point.

The only time quirks become problematic is when you turn them into Pygmalion projects. If you expect others to share your quirks, you will quickly run out of friends. However, when you learn to appreciate quirks in yourself and others, you become a better person. You begin to appreciate peoples’ strengths and weaknesses. If you pay attention, you might even discover that the person you thought was incompetent is really just different from you.

The moral of this story: Embrace quirks, but don’t enforce them.

Exceptional programmers

One thing that seems to be a perennial favorite on Hacker News is discussion of the characteristics of a good programmer. Inevitably, people disagree on this subject. I think this is a difficult question to answer not because it’s difficult to recognize good programmers, but because it’s the wrong question.

Human talent cannot be reduced to a simple boolean proposition. People have different talents in different areas. People often have problems recognizing good programmers because they try to fit people into a box. They try to say that good programmers have characteristics x, y, and z, but that characteristics a, b, and c are never qualities of good programmers.

It turns out that for every good programmer you do recognize, there are probably several other people you wouldn’t have guessed in a million years would be any good. So here’s my attempt to help people understand good programmers better. Oftentimes, good programmers will fall under more than one or even all of these categories. But usually, they’re most talented in one area.

I should also point out that I’m probably just scratching the surface here. There are probably more types of good programmer than this.

The machine

The machine is probably the first person you think of when the words “good programmer” hit your ear. The machine is someone who has the job you asked for finished yesterday. Sometimes the most challenging task is simply finding things for them to do.

Machines are the easiest to recognize simply because their talent is more measurable: they get their tasks done way ahead of schedule. However, they’re not without their tragic flaws. Although machines are good at writing code, they rarely see code as anything but a means to an end. Left unchecked, machines can turn your code into a steaming pile of crap. Fortunately, that’s where the other types of good programmers come in.

The method man (or woman)

The method man is the one who brings discipline to the team. Their greatest strength is attention to detail. Usually, they’re the ones to poke holes in the architects’ brilliant ideas or to get the machine to slow down, take a breath, and think before coding.

It’s a bit more difficult to recognize a method man than it is a machine. The key thing to watch for is process. They’re the ones who describe everything they do in excruciating detail. This is also their Achilles heel. They’re good at applying rules and processes, but they freeze the instant they are faced with a situation that falls outside them.

The architect

The architect is the crazy guy (or gal) who rambles on and on about design patterns. Get him involved in a conversation and he’ll be delighted to tell you his latest theory about whatever random thing he’s thinking about at the time. While their ideas may come off as crazy, there is almost always a method to their madness.

They’re the people who make sure machines don’t have to care about their code. They’re also the ones to offer guidance to the method men when the rules don’t apply. They’re the ones who look out for the big picture while everyone else is distracted by details.

The hallmark of the architect is inconsistency. They’re the ones you come to when you have a really difficult problem. But assign them the most mundane task and a two-hour project just turned into a two-day project. Ask them to explain Goedel’s Incompleteness theorem, and you’ll get the most brilliant description you’ve ever heard. Ask them what a database is and you’ll probably get the most obtuse and technically dense answer you’ve ever heard.

So what other types of brilliant programmers have you come across?