> a bunch of totally incompetent programmers out there that need to be kept out of because of fear of bringing quality precipitously down

I suppose it depends how you define "quality" - in my recent experience, it's always been the "rockstars" that are the worst developers. Because they generally write code which ends up being a nightmare to support and maintain when they're gone. Sure, it's great you wrote your own ORM in Perl but 10 years later it'll be crippling the company because no-one can make any changes without it breaking 27 other things.

(Ok, it's often Perl people...)

For me, a quality developer is someone who achieves the goals of the company in understandable, maintainable, testable, and documented code.

Ok I've had one experience with a guy that I guess thought he was a rockstar, in my opinion he was my level (from looking at the code, although he was much better than me at DevOps), but he did have one awful failing, he didn't want to figure out why something was the way it was and just decided to rewrite everything.

Also he thought I had done something using ElasticSearch because I was an ElasticSearch guy, instead of having learned ElasticSearch because I thought it was what was needed (and no amount of explaining this simple concept could penetrate)

> For me, a quality developer is someone who achieves the goals of the company in understandable, maintainable, testable, and documented code.

Agree. But it should be noted that the needs of a startup may not always make that easy. I'm personally responsible for transmogrifying an existing Perl ORM for a company, because it only supported a single database handle / class. Which is a pain when you're in a master / slave environment. This hack allowed the company to meet the performance challenges that came along each year by summer. It also allowed growing the company from ~35 people in 2004 to about 5000 people in 2012 (when I left).

It also froze the version of the ORM in question, until it got rewritten from scratch at great expense. But that expense could now be easily carried by the company.

10-20% seems really low in my experience. Do you mainly hire out of the industry?

Hiring heavily from colleges results in 60%+ of applicants that somehow have a B.Sc. from a university that produces amazing applicants with great (3.5+) GPA's but stall at either fizzbuzz or (just in case they memorized fizzbuzz) i-can't-believe-it's-not-fizzbuzz.

Furthermore, some candidates (20ish percent?) can't even answer basic, non-trivia questions about their language they self-report to know best. e.g. Java programmers who either don't know or cannot articulate what the static keyword does.

I'm convinced there's a path through every university, no matter how good, where you can avoid all the good professors and only pick babysitter professors and squeak through your four years with a piece of paper and a well-tuned sensor for which profs actually grade homework instead of just giving 100's so people don't complain.

My experience is only as a programmer, maybe HR has kept most of the bad ones out, but I doubt it based on my experiences with HR. So 10-20% is my experience of how many programmers I encounter are bad in a big organization, and bad is a relative thing of course.

But often when I am brought into a big organization there is one out of every 5 programmers that just should be something else. They're not necessarily stupid, just shouldn't program.

on edit: in my experience small organizations don't have quite as bad because for the organization to be able to exist their programmers must be able to program. (for any organization heavily focused on tech of course)

I would say that while only 10-20% of programmers might be literally not worth paying any amount for, it might be as much as half of the field that isn’t worth the current, major US market compensation.

once you're willing to admit that they are worth paying something for you're just arguing price, which is whatever the market says it is.

either that or 25 dollars, same as in town.