A good developer adds business value.

A bad developer subtracts business value.

Ultimately, in a business setting, those are the only two metrics that matter.

Selection is a management problem, and like many management problems the median level of understanding is primitive and often dysfunctional.

Not many businesses understand how many flavours developers are available in, nor how to match those flavours to the team/project roles they need at that time. So they robo-hire with standard CS whiteboard hazing, or interview for "cultural fit", or some other nonsense.

The hard-headed hiring question is always "Will this person make the business more money, and if so, how?"

This may sound like a recipe for a sweat shop, but it really isn't. There's a lot of possible variation in "how", which includes making smart architectural choices, having good team lead skills, raising the company profile through social presence, and so on.

The strongest possible code is always a good thing, but sometimes it's fine if it's eclipsed by other qualities. You're hiring a person with many possible skills, not a cog in a machine that you're planning to spin as fast as possible until it breaks.

It's up to management to work out how to get value from that. And there's a lot of creative potential in management that traditional work cultures overlook.

Problem with this is it's hard to account for risk.

What makes a good insurance policy?

To clarify:

"Will buying this insurance make the business more money, and if so, how?" is a little more nuanced, since it requires consideration of risk, and dependent, unknown factors.

I second this! From my experience the best or rather most productive programmers get stuff done focusing on customers over eligant code. Mostly, just because they want to get something done so they can either avoid further meetings or work on their personal stuff.

The "best" programmers you mentioned, from my experience, always end up souring the whole team. Most of the time, they can't seem to tell the forest from the trees.

With that in mind, one of the things I tell my team we always need to hire more of are just developers with social skills. Being effective at working with a team is 100x more important than being a good developer. As an example, I have spent weeks in meetings debating archetecture. Each meeting I would make my same suggestions and then the rest of our "best" developers would debate. By the 6th or so meeting regarding the architecture I just presented a prototype of the project. I won the debate by acting, not by trying to find an ideal solution.

Good attitude for startups which will die after barely releasing MVP. Others will learn that maintaining is where the most time is spent and that chasing customers' whims without any regard how it all fits together will lead you to the situstion where new features are no longer possible to implement and the old ones start to break in random places. But hey, you at least talk about it for hours with all those wonderful social skills you have.

I think it is false dichotomy. "Best" programmers at least do nothing before they have a plan and HLD (good or bad). Productive programmers simply get things done both ways, good or bad. I've seen many times how we "productively" produced overengineered unreadable spaghetti that works. Yeah, I can write even straighter single-page perl golf too to show selling prototypes, but that's not what we are paid for as a company. That can be outmanaged by detailed design specification, but then you have to have an expertise at the code level (easy) and spend half time on the task yourself (hard).

Both types can do good or bad for you.

Edit: iow, smart and get things done, not or.

There are lots of ways to go wrong, of course, but make very sure anyone you hire with high social skills also has high ethics (there's an inverse correlation.) Because a good actor can trash almost any tech business, if they have enough knowledge to pass. The truly competent techies will be outmatched.

>>Being effective at working with a team is 100x more important than being a good developer.

Having such a constant in your mind would be indicative of never having to do something 'hard' (algorithmic, latency related, extract every single bit of performance b/c you have to)

When you can't find a clear answer... May be you asking the wrong question. Create code is - in my opinion - a service, not a product... If you keep paying a service like it is a product it will continue to be inefficient and open to opportunitistic behaviour. What about changing the reward model then? What you, programmer, get paid some fix price for expenses coverage and then a fee for each week (or month) you're software runs without a flaw? Or a fee that goes on as long as software keep working (with your eventual maintenance and fix help, of course). This would make customer happy (he has a working programmer) and do reward more the best programmers. The main issue of one-time assessment on programmer job is, in fact, that you not always discover software flaws immediately.. it takes time..