There's No Such Thing as Software Productivity (2012)

Isn't it obvious? Hiring people who are actually competent is hard. It's not just me, major corporations have found the same issue.

I do believe that you can use basic tests to determine whether someone has more technical competence than some random guy off the street, but it only works up to a point. If you try to test deeper and deeper knowledge, you might create a mirage where someone who isn't very competent appears competent because you just happen to hit on strong spots on their very sparse experience. (My imposter syndrome reasons that this is why I passed the Google interview so easily some years ago.)

But for example, interviews don't even really bother trying to determine any direct proxies for productivity. Usually, they just stick to trying to determine technical competence, communication, ability to work on a team, and evaluate their history of technical accomplishments. A list of accomplishments is evidence of productivity, to a degree, but not having a long list is not evidence of a lack of productivity, and neither will tell you what will actually happen when you hire the person. References will at least give you someone else's gut feelings (or lies) regarding someone's productivity, but any reasonably competent person is going to have people who can vouch for them even if their productivity is actually not very impressive. It's not like there's some huge punishment for embellishing someone when you're being interviewed as a reference for them.

In the context of hiring people, gut feelings are probably the best thing we have, but they're subject to horrendous bias. Even if you are highly enlightened and can recognize your own biases with a great degree of humility, this is not generally the case for most people. Because of that, Google's interviews have a lot of layers of abstraction designed to eliminate bias from the process, but then again, they also wound up doing a study where they hired people who were ultimately turned down for the job and found that those people had around the same chance at succeeding at Google as the people who were hired. (Can't find the source for this because Google Search is useless nowadays. Maybe their hiring process is to blame.) And yet, there's no doubt that even with this in mind bias will still impact the interviews, because the interviewer does ultimately have to transcribe the interview and they can choose to omit or paraphrase things in a way that makes it look worse to the committee overseeing things; likewise, you can "correct" what the person is saying if you felt it was "close enough", or omit entire segments that looked weaker. Sure, you're not supposed to, but I would bet you 10:1 that even people not intending to be biased wind up doing this. Maybe they're second-guessing themselves when they do it: was it my fault they didn't answer better? Were they saying it right all along and I just wasn't understanding?

I was actually involved in a lot of interviewing and hiring especially early on in my career. I still believe gut feeling was the best instinct I had, but there was a time when I didn't agree with a hire and was proven horrifically wrong very soon after. Granted, that mostly comes down to how you evaluate someone's technical competence, not necessarily productivity, but I think the point stands either way.

Your first scenario: possible, but quite unlikely. If James cannot even perform migrations without causing outages or dropping data, the chances are that "flagship order processing pipeline" he made is similarly bad, and even if it works, it's likely has outages and missing data. I've never seen a developer who can only do hard tasks but is genuinely bad at simple tasks (They may refuse to do those, but if they start on them they'll do them well.)

Your second scenario is unfortunately very likely, people are jerks, and if they are also high performers (or high bullshitters) then can get away with it.

Either way I fully agree one one should be firing/promoting people based on a single metric, even if that metric is very relevant to the job description. That doesn't mean that "there is no such thing", or that if you really need to get that DB migration done, you want to choose a "quintessential communicator with jr devs".

Money is a bad measure of usefulness, but it's better than any other working measure.

> With respect, that goal is far from clear. How do you measure how much they like the product?

Completely agree: focus groups, A/B testing, Net Promoter Score, 5-stars, like/dislike -- all of those systems are notorious for being unreliable in various ways, and optimizing for them is the cause of many sub-optimal decisions and Prisoner's Dilemmas in many industries.

> Customers like a product because it removes their problems. QED.

Your first point was "actually the world is really complicated" (strong agree) and your second was "actually the world is super simple" (strong disagree). Customers like products for wild reasons, unknown even to themselves. I've heard some slot-machine addicts get irritated if they win the jackpot, because it breaks them out of their state of flow. You could argue "well clearly that lack of flow was the problem slot machines are solving" but then you're just using circular reasoning: if a customer likes a product, it must be solving the problem for them that they previously did not have that product. I don't think you could have looked at the slot-machine addict a year before they started gambling and deduced that they had some sort of problem that slot machines needed to fill. There's often no clear link from a-priori diagnosable "problems" that people have to the products that they buy. In the universe populated by logical econs that do act this way, store shelves and advertising look very different.

Fascinating.

I disagree completely, of course. I imagine our backgrounds are wildly different.