Thoughts on the Expert Problem

Posted on October 12, 2016

Recently, I discussed the Expert Problem with a friend who is a very good programmer (or developer, or computer scientist, or whatever you want - I’ll use various terms interchangably here). We didn’t know that there was a name for it, but we still came up with some interesting (if not novel) insights. Our conversation was centered around competence in relation to development. Something you’ll notice once you’ve spent some time in the CS field and socialised with people in the milieu, if you’re observant and intelligent (no, being intelligent is definitely not a requirement for being a programmer), is that developers can be roughly divided into two categories. These aren’t all that clear-cut, but it is very easy to find obvious examples of both types everywhere.

The first category, to which I count my friend and myself (though I’m not an experienced programmer), contains people who are very interested in the subject, who are fascinated by both the theoretical and practical aspects of various different paradigms, though they often detest Java and similar object-oriented languages, and other gimicky systems that superifically ‘boost productivity’. Chances are they run Debian, Slackware or Gentoo on ancient hardware (development doesn’t require a lot of performance), and they put C and/or LISP pretty near the top of their lists of preferred languages. These are the people you want to hire, because if you give them an interesting problem to solve, you’ll have more trouble getting them to stop or slow down than anything else. You might associate them with neckbeards, and while it’s true that most archetypal neckbeards probably fit in here, there are also a lot of people with social skills and a wide array of other interests that fit into this category (the Hacker News audience is probably a good population sample). So let’s just call it Category I.

Then we have Category II. These are the people who like projecting an image of being ‘nerds’ or ‘developers’ more than the subjects, and the reason they got into the field in the first place was probably the labour market and salaries. They love apps, cloud computing, agile software development, web technologies, and other buzzwords. They do most of their programming in Java or Python, or some hip framework like nodeJS or Rails. Despite having spent a considerable amount of time attending conferences about productivity-boosting development processes, they are probably much less productive than those who belong to Category I on average (as we have already said it’s not a clear-cut line, and there are definitely people who could be said to belong to both categories). My friend calls them scrumlords. The problem lies not in the technologies and methods themselves, but in the sort of people who are attracted to them.

Fundamentally, those in Category I are more productive on average than those in Category II because they are passionate. They are interested in the subjects, and they are competent because they need to be competent to master the skills required for the sort of work that interests them, and they retain competence by doing what they love, constantly. In contrast, those in Category II lack this sort of competence because they lack true interest, and they focus on minimising effort. Minimising effort can be a good thing in the right context, but when it’s about developing skills and learning important concepts, the indolent are not rewarded.

It’s worth saying once again that these two categories are very rough, and are very far from covering every developer. But they are useful for understanding some things that happen in the real world.

One problem is that, as an outside observer, given a randomly selected developer, it’s very difficult to tell which category they belong to, unless you belong to Category I yourself. If you’re a good introspector, you may realise that you actually belong to Category II (and then either do something about it, or be blithely complacent). This is only likely to happen if you understand the distinction, and even then our naturally uncritical attitude towards ourselves will make it unlikely. How can you know if someone belongs to Category I or II without spending a considerable time in the field and thinking about the issue? You probably can’t. Do you think the HR folks can?

An alert reader might notice a recursive implication in the last sentence. The question becomes, how can you know if a person in HR can distinguish between Category I and Category II developers? As an outside observer, I’d like some way to distinguish between Category I and Category II recruiters. Well, it seems I’m out of luck, because I know nothing about hiring except that the people in that sector very often can’t distinguish between Category I and II developers. Competence is very hard, if not impossible, to understand for those outside a field. How do you hire the people who hire for you?

I have some ideas for solutions to this problem that may at least reduce incompetence exposure in hiring developers - but there should be ways to generalise them. We’ll also explore the Expert Problem in some other relevant fields.