Joel Spolsky wrote a long time ago about a simple rule they used at his company when deciding whether to offer an interview candidate a job: Smart and Gets Things Done. It was a rule he’d picked up from his time at Microsoft, but he quickly realised they needed a third rule: Not a Jerk.
Software development is a team game, and no matter how much you know, or how finely-honed your skills are, if you can’t interact with other people without upsetting them, you’ll do more harm than good. This applies to everyone except Linus Torvalds: Linus gets a free pass because he wrote the OS that runs most of the things.
I’ve been working in software development for over 18 years, and I’ve been lucky to work mostly with smart, competent and pleasant people who pass all of Joel’s tests. No one’s perfect though, and I’ve noticed some tendencies in myself and other developers that I suspect we’d all be a lot happier – not to mention more productive – if we tried to avoid.
They say the first step is admitting you have a problem, so here goes:
Hi, I’m Adam, and I can sometimes be a jerk.
Before I get started, I want to clarify that I don’t believe that these tendencies are unique to developers: some might be, others probably apply to anyone doing knowledge work, and some are just examples of general human behavior. However, most of my professional life has been spent working in software development teams, so that’s my frame of reference.
I’m also aware that my own take on these behaviors won’t be universal, and that there’s a chance I might be about to announce a set of unique and appalling character flaws to the world. Oh well. Finally, and most importantly, my objective here is absolutely not to incite people to start accusing their colleagues of being jerks. Warning: this product is for internal use only.
Knowledge Is Power
In software, as in all knowledge work, your skills and knowledge are a big part of what you have to offer to your team, your organisation, and the world in general. As a professional, they form part of your self-image, provide a sense of security and accomplishment, and affect how you’re seen by your peers. They’re your greatest strength, but as the same time your greatest vulnerability: if you cease to know the right things, you cease to be useful, and in software, the things you might need to know are myriad, and change quickly.
As a result, developers can be understandably sensitive when it comes to their skills and knowledge, and this can lead to some unhelpful behaviour.
Technical Posturing
Transferring knowledge and applying our skills are core parts of our job, and most technical folk like to talk nerdy now and then. Other times though, we stray into showing off, asserting superiority or even into outright intimidation. We’re a bit like a peacock, only instead of feathers we have Big O notation and Apache committer status.
A good example of this is a comment I overheard a while back:”How can you call yourself a developer if you’ve never heard of tcpdump?”
There’s a lot to know about software development, and no one knows every language, tool and esoteric computer science fact. Nevertheless, most of us are able to function pretty well, design and write good code, and look stuff up when we need to. Belittling someone on the basis of some arbitrary thing you happen to know is irrational, petty and harmful. Our focus should be on applying and sharing our knowledge, rather than putting it on conspicuous display. In terms of information exchange, the two might be equivalent, but the effect on the people you’re interacting with is fundamentally different. Consider a situation where someone has a problem, and you realise you might have the solution.
Compare:
“Well obviously the answer is to use X. I’m surprised you didn’t consider it, but I can do it for you if you don’t know what you’re doing.”
with:
“Have you considered using X? I think it might work in this case. Happy to give you an overview if it’s not something you’ve needed to use before.”
Fear of Being Wrong
The corollary to Technical Posturing is being overly defensive about criticism, even if the criticism in question is constructive. No one likes to make mistakes, and no one likes being wrong. However, our work is complicated, and even the best developers make mistakes, miss opportunities or overlook solutions.
A few years ago I was having a discussion with another developer about a technology I’d been working with a lot, and they made a point I hadn’t considered. I felt bad that I hadn’t thought of it, and my reflex was to look for reasons to disprove the point, because at an emotional level it would be easier for me if they turned out to be wrong. After a fairly lengthy debate we decided the only way to be sure was to test it. I wrote a simple test, and the other developer was right. If I’d been more open-minded and less concerned with protecting my ego, we would’ve reached the same conclusion a lot quicker.
The trick here is to not beat yourself up about making a mistake, or not knowing something, or not having thought of something. These are all things that happen to everyone, no matter how highly skilled and experienced, and the more you obsess over them, the more likely you are to focus on trying to fight the situation rather than learning, fixing things and moving on.
Try to bear all this in mind when you spot a mistake made by a colleague. Yes, it feels good to track down a bug in someone else’s code, but try to suppress the urge to run over to their desk, yell, “In your face!” and do a little dance. I once worked with someone whose shadenfreudic glee when someone else made an error was positively palpable. It as annoying as it was exhausting.
Not Invented Here
Learning new things takes a lot of effort, and means going through a period of uncertainty that can feel unpleasant. We also have an innate tendency to assume that we could do a better job of solving whatever problem is being tackled, or would at least go about it in a way that would make more sense to us. All of this means that we’re sometimes reluctant to choose solutions that involve technologies or ideas we’re unfamiliar with.
There’s a lot to be said for maintaining a healthy level of skepticism whenever we’re evaluating anything new, but we need to be careful that our intellectual inertia and technical prejudice doesn’t get in the way of choosing the best solutions.
The more subtle variation on this is a tendency to stick to working with parts of the system you’re familiar with or have more control over, and to treat the other parts as black boxes. This can lead to us making unwieldy changes to a part of the system we know well in order to avoid having to dig into an area we’re less familiar with. Often the right answer is to take a deep breath and dive into the code.
Hype Cycling
On the other side of the Not Invented Here coin is the tendency to want to use whatever new and shiny technology is currently generating the biggest buzz among people who do their work on an Macbook Pro in the nearest pop-up artisanal coffee shop*.
Again, there’s a lot of sense in wanting to stay up-to-date and try out the latest tool, language or platform, but you start to get into problems when you’re constantly introducing new technology into the project, or when you’re picking technologies based on whether you think the other developers will tease you in the playground if you’re not using them.
Us vs Them
As well as a need to feel valued and useful, we also have a powerful need to belong, almost certainly stemming from a time when being rejected from the group meant death by sabre- toothed tiger. Sadly our hypothalamus takes a while to catch up, and is still interpreting office spaces and social functions as scenes of life and death struggles for survival. The problem with the need to belong is that it requires us to identify with a particular group, which naturally leads to the identification of the Other, and as history tells us, this more than any other aspect of human nature is the greatest cause of our being complete and utter jerks.
Tribalism
If I identify with a group, I feel protective of it. I want what’s best for that group, and I’m more likely to be suspicious of other groups. This can cause problems when the only group I identify with is my immediate team, or department. The irony is that while its easier to identify with the most immediate group you belong to, usually that group has shared interests with wider groups, extending outward to the super-set we’ll call People. The wider we can cast our identification net, the easier it is to focus on our common goals.
User Blaming
A special case of Us vs Them happens when we allow ourselves to begin resenting our users and stakeholders. It’s easy when you’re battling day to day with the trials and tribulations of writing code and maintaining systems to forget that the entire point of what you’re doing is to make life easier for other people. You start to feel an affinity to the system and the team rather than your customers, which makes you more inclined to dismiss concerns and issues as the fault of the user, rather than as a symptom of something you ought to fix.
A user might raise a support ticket and when you read it, it quickly becomes clear they don’t understand some fundamental part of the system. “Ha, here’s someone who shouldn’t even have an account!” we might say, but really, in all likelihood this is a perfectly intelligent and capable person who’s just lacking information, so the response should really be, “If this is so fundamental, how has this person misunderstood, and what’s the best way to make sure this is as obvious to our users as it is to us?”
In the interests of balance, this also works the other way, too. All developers are also users of other software and depend on other systems, and we’re often the most critical and grumpy of customers.
Here’s the thing though: the person who build that system you’re so angry at is, in all likelihood, just like you, trying to do their best with what time and resources they have. Your snark and vitriol aren’t going to help them do a better job, and will probably make them a lot less likely to want to help you any time soon. So, if you’re having problems, raise a ticket, submit a feature request, or send an email explaining what you’re having trouble with. You’ve worked on resolving support problems before, so you’re well-placed to provide them with exactly what they need to fix things.
Guidelines for Not Being a Jerk
So if this is all so clear, why are we still such jerks a lot of the time? It’s easy to call out these sorts of behaviour, and yet we all do them anyway. I’m not a natural people person, so I tend to try and find useful rules I can stick to that act as guidelines in moments of doubt. Here, then, for what it’s worth, are my Personal Guidelines for Not Being a Jerk, which I need to do better at sticking to:
- Give credit where it’s due.
- Say please and thank you.
- Share knowledge and freely admit to your own ignorance.
- Don’t say something behind someone’s back that you wouldn’t be prepared to stand by if you realised they were stood behind you.
- Let people know you appreciate their efforts, and that you understand their circumstances.
- Let people know you respect them, even if you don’t agree.
- Keep an open mind, but not so open your brain falls out.
- Unless you have clear evidence to the contrary, assume people are acting in good faith and doing their best.
- Don’t pass up an opportunity to make someone feel better about themselves simply by telling them the truth.
Finally, there’s a quote by Hemingway** I try and remember when insecurity starts to get the better of me:
There is no nobility in feeling superior to your fellow man: true nobility is being superior to your former self.
The Dalai Lama is away.
* Gross stereotyping is also bad.
** I’d love to be able to say I came across this quote because I’m all about reading Hemingway; the truth is I got it from the film “Kingsmen”