Developer Stereotypes and Career Choices

It’s well known that the human mind takes a lot of shortcuts - it’s one of the ways that it achieves the extraordinary levels of operation that we collectively refer to as “intelligence”. These same shortcuts also lead the mind to make some interesting mistakes - a rich field of quirks ripe for the both ethical researcher and the unethical conman.

One of these shortcut techniques is the use of pigeonholing - a whole group of things will be grouped together for identical treatment because many of their characteristics are similar. When a particular pigeonhole becomes widely used we call it a stereotype. Stereotypes are a useful shortcut for reasoning about large groups of items, but they fall down if used to try and assess a single item.

When one developer, let’s call her Jane, stops to briefly consider “other developers” (work colleagues, former colleagues, friends, classmates, people at the local user group, online friends, people on the stackexchange.com network and so on), what pigeonholing system is Jane likely to use?

Likely the first division is going to be between people who work with the same set of technologies, and those who work with other technologies. So we have a division between people who work in Windows vs Linux vs OSX, between open source and closed source, between Microsoft’s .NET Stack vs HTML 5 (Javascript) vs Android (Java) vs Apple, and so on in ever increasing levels of detail.

Broadly speaking, given the natural human inclination to minimize the importance of the things we don’t know, Jane’s world view is going to break down something like this:

Within the group of people working with the same set of technologies, a similar breakdown will occur, with Jane grouping people into a small number of different clusters. Again, I’ll point out there’s nothing inherently wrong with this, and that this kind of pigeonholing is an extremely common characteristic of human reasoning, a common shortcut.

I have a strong suspicion that Jane’s grouping would look something like this:

Peers - other developers who do the same or similar kinds of work and who exhibit a similar level of competence. This will naturally be the largest group simply because it is human nature to hang out with people who are similar to ourselves.

Novices - other developers who are clearly less experienced, either because they are new to the industry or because they work on projects that seem straightforward or simple.

Experts - other developers whose work is recognizably advanced, perhaps for its complexity, scalability or reliability, or perhaps simply because they get things done on a remarkably effective way.

Cranks - a small number of other developers who are just weird - who don’t solve problems in the usual ways, who often have their own language and use techniques with indecipherable names.

So most other developers appear to be peers, with the rest clearly identifiable as either novices or experts, and the rest, well they’re cranks so we’ll pay them no mind.

This leads to a world view much like this:

Any developer feels that she is one of the better developers in her field - she must be, since only a small number of experts are better.

We can also easily see the origin of some common - stereotypical - opinions that are oft expressed in the developer community …

For one, we can see why many developers are supremely confident (sometimes bordering on arrogant) in their craft, dead sure that they’re one of the best of the six million developers on the planet - if you know of only a few developers who are more accomplished, then you’ll naturally think you’re pretty good.

For another, we can perhaps see why so many developers leave the field after five to seven years - not because they find development a field that is too stressful, too hard to succeed, but because they think there is little challenge left. Having risen to the top of the field (or so they think), they leave in search of greater challenge.

This is all well and good - but what is the reality?

Underutilized Developers - business needs are often simple and there’s no prize for delivering a complex solution where a simple one will do. Experienced developers will often be pulled into working on simple projects for no other reason than that’s what the business needs. There are fewer novice and peer developers out there than you might expect.

Clever Cranks - those cranks, the ones with the odd techniques and the strange terminology. They might just be cranks (SharePoint developers, perhaps) - or they might be the developers who are outperforming the experts you recognise. Object oriented development (and its pattern language) is indecipherable to a procedural developer, and both of them look upon functional programing as some kind of voodoo with its talk of functors, monads and pattern matching.

What does this mean? Not every developer who appears to be a novice is actually inexperienced. Some of the developers who appear to be our peers are actually experts. And those cranks, we can’t ignore them because even if the way they do things is weird, its also effective. Back in the 1990’s, the cranks were object oriented developers, now object orientation is mainstream. Ten years ago, functional programming was the province of the crank, now it is becoming mainstream. The cranks seem to lead the way.

So this is reality - for developers who share the same set of technologies:

Some of this is bad news:

• We have fewer peers than we think.
• We’re not as good as we like to believe.

But much of it is good news:

• There’s more to learn than we thought - we don’t have to leave the field to find our next challenge
• There are plenty of people to learn from
• We only need to look at the cranks to find out what’s coming next

Who do you know who seems to be a crank? What are they doing that gets them so passionate about their technology choices, and what can you learn from them? Better yet, will you look outside the group of developers who share your technology choices and learn something new?