It's better to let good/great people slip away then to get a bad apple onto the team. Or worse, a mediocre one who never does anything wrong but also isn't contributing positively either.
If everyone only wants “great” people, where are the mediocre people supposed to work? Think like this long enough and soon the have-nots are plotting a revolution.
Companies with defined, well established revenue streams need to build mentoring programs that turn mediocre developers (solid C) into good (solid B) developers. Those employees tend to be the most loyal and are capable of a great amount of menial to boring coding tasks without complaint. Why do we devalue the grunts? They are the bedrock of every organization.
It’s not like Google’s Adwords is undergoing a complete code rewrite every quarter. Neither is Microsoft Word. Most code changes are incremental, and people need jobs, so why do we denigrate them so?
Plus A players are only usually A in their requisite subdomain. A crack coder of financial systems is going to struggle mightily when writing a morphological filter or a seam carving algorithm. There’s real value to the business when an individual acquires domain knowledge, especially when the domain is not fundamentally exciting (e.g. finance, geology).
The truth is that everyone actually hires mediocre people, otherwise we wouldn't get so many comments about mentor people on teams and performance reviews would look very different.
That said, very few people think of themselves as average. Just looking at the comments here on hacker news, everyone feels they are the A players and if they aren't selected for something it's because management sucks or they aren't understood, or some other excuse.
We could all stand to be a hell of a lot more humble.
>Companies with defined, well established revenue streams need to build mentoring programs that turn mediocre developers (solid C) into good (solid B) developers. Those employees tend to be the most loyal and are capable of a great amount of menial to boring coding tasks without complaint.
In general, when coding, if you're doing a menial or boring task you're doing something wrong. E.g. I've worked with a ton of mediocre developers who don't automate the menial tasks and end up doing the task manually, sloppily and slowly.
>It’s not like Google’s Adwords is undergoing a complete code rewrite every quarter. Neither is Microsoft Word. Most code changes are incremental,
Incremental changes are hard. Incremental changes to large and unwieldy systems while leaving them in a maintainable state are very hard (actually, from what I've heard, Google Adwords' code base is a mess).
>Plus A players are only usually A in their requisite subdomain. A crack coder of financial systems is going to struggle mightily when writing a morphological filter or a seam carving algorithm. There’s real value to the business when an individual acquires domain knowledge
It's vastly better to have a really good product owner/manager who knows the domain working with a really good coder than a mediocre coder with mediocre domain knowledge.
>In general, when coding, if you're doing a menial or boring task you're doing something wrong. E.g. I've worked with a ton of mediocre developers who don't automate the menial tasks and end up doing the task manually, sloppily and slowly.
That’s total BS. Development is full of boring mediocre tasks such as fixing spelling mistakes in UI controls, updating help messages for dialog boxes, or porting the product from one build system to another. In many tasks, there’s a huge gap (a chasm sometimes) between manual intervention and complete automation. I’ve lost count of the number of times a clever programmer has tried to automate the process and completely mucked things up, forcing me to go in and fix things manually.
>Incremental changes are hard. Incremental changes to large and unwieldy systems while leaving them in a maintainable state are very hard (actually, from what I've heard, Google Adwords' code base is a mess).
That’s exactly where a great product manager can mentor a mediocre developer in making a sensible change. It’s a great learning opportunity that we’re depriving people of because software founders want to retain all the revenue for themselves.
>It's vastly better to have a really good product owner/manager who knows the domain working with a really good coder than a mediocre coder with mediocre domain knowledge.
Of course. It’s also vastly better that to be born rich so one doesn’t have to work at all. Ideally, all developers in the market would be great developers. But they’re not. So I ask again, what are the mediocre developers supposed to do?
>That’s total BS. Development is full of boring mediocre tasks such as fixing spelling mistakes in UI controls, updating help messages for dialog boxes
I would say this counts for much less than 1% of what I have to do. A lot of this stuff is in files which I can give product owner control over, too.
>or porting the product from one build system to another.
And this isn't boring. Build systems are tricky and filled with pitfalls. The worst thing you can say about build systems is that it's not a prestigious task.
>I’ve lost count of the number of times a clever programmer has tried to automate the process and completely mucked things up, forcing me to go in and fix things manually.
Yeah, and fixing things manually in that case is boring. As I put it above "if you're doing a menial or boring task you're doing something wrong" and you precisely described "something wrong".
>That’s exactly where a great product manager can mentor a mediocre developer in making a sensible change.
Product managers are not the right people to teach this kind of thing.
>Of course. It’s also vastly better that to be born rich so one doesn’t have to work at all.
Unlike being born rich, which is out of your control, you are able to exercise some degree of control over whom you work with.
I always burst out laughing when I hear this. Mostly because the people saying it assume that themselves are not mediocre but good/great people.
Reminds me of the anecdote when a Google hiring committee in Kirkland was tasked to judge each other's original (anonymized) interview feedbacks and everyone failed everyone else.
"Mediocre" is virtually always considered "poor" in the USA, even though the literal definition is "middling or average." Anyone would consider going to an average restaurant, but we'd avoid one someone described as mediocre.
I think a lot of responses to this are missing something unsaid here: a single interview day for someone doesn't always give them a chance to be their best selves. That's ok but you do what you can given this fact. The whole thing is about being risk adverse with who you bring on to the team. This is the right thing to do because bad hires are exceptionally costly. It isn't a judgment on the candidate's innate value as an engineer, it's about a single sample of the "is this person a good fit for our team" function, which is different!
I just read someone talk about job post on linkedin with over a thousand applications. Are people on linked in truly mediocre that not one out of a thousand can fill the position?
I think many companies don't have exactly 1 job posting for 1 seat. For example, I've seen large tech companies have a single "Backend engineer" req that is used for every backend engineering role in the company (or org). So the pure number of applicants in a LinkedIn job post may be misleading.
Maybe hundreds could, but only one of them was having a really good day on the day of the interview. Which is why candidates have to do so many interviews and companies have to interview so many people.
Companies with defined, well established revenue streams need to build mentoring programs that turn mediocre developers (solid C) into good (solid B) developers. Those employees tend to be the most loyal and are capable of a great amount of menial to boring coding tasks without complaint. Why do we devalue the grunts? They are the bedrock of every organization.
It’s not like Google’s Adwords is undergoing a complete code rewrite every quarter. Neither is Microsoft Word. Most code changes are incremental, and people need jobs, so why do we denigrate them so?
Plus A players are only usually A in their requisite subdomain. A crack coder of financial systems is going to struggle mightily when writing a morphological filter or a seam carving algorithm. There’s real value to the business when an individual acquires domain knowledge, especially when the domain is not fundamentally exciting (e.g. finance, geology).