There's either a cost or benefit of everyone on the team. Programmers generally push the code at a constant velocity in one trajectory between the two.
They'll be somewhere between fixing things and making it better to breaking things and creating new problems that eventually need to be undone and re-solved, pushing the quality down and deadlines back.
People tending towards the second group are a waste of time and money. As a hiring manager, to be completely brutal, unless they can demonstrate they are in or have high potential to be near the first group, I simply do not care.
The contribution value of people in the second group is not zero, it's actually negative. Their bad decisions and buggy creations decrease the quality of the product. It's like putting an saboteur on the payroll and then handing them important responsibilities. The team likely becomes friends with them (friendships at work happen about 10 times for every 1 enemy) and this makes reversing the mistake even harder because after all, we are social creatures at heart.
What's worse, after the inevitable breakup, I then have to re-allocate my quality assets away from pushing the product forward to cleaning up the mess someone just left and things stop getting done in the meantime.
It is indeed negative, because not only they can break some things, but their code has to be reviewed thoroughly, and more experienced developers usually have to spend some of their time teaching them some concepts, which will slow down everyone.
Of course, not everybody is like that, but some people are, and here is the danger.
> We've known since the early sixties, but have never come to grips with the implications that there are net negative producing programmers (NNPPs) on almost all projects, who insert enough spoilage to exceed the value of their production. So, it is important to make the bold statement: Taking a poor performer off the team can often be more
productive than adding a good one. Although important, it is difficult to deal with the NNPP. Most development managers do not handle negative aspects of their programming staff well. This paper discusses how to recognize NNPPs, and remedial actions necessary for project success.
I think this is the right answer, though I think there's a mentoring element that has to be considered. Plenty of people will break things if left unsupervised but will learn quickly to contribute if they get the right feedback.
That's fine if you have the cash to burn and people to squander. Larger firms probably do (after all some have daily banquets and onsite gyms), but it is just burning cash and squandering time.
If you're on a tight budget like I usually am, I let someone else do that investment. I simply don't have the resources. Early stage startups are the most enjoyable nightmares I've had.
Unfortunately feedback has a price: senior engineers have to do more thorough code reviews, they may have to explain more fundamental things, and it all adds up. Some junior devs are independent and learn quickly with minimal feedback. Bless these devs, I love working with them. Some junior devs require a lot of time, and make the same mistakes over and over.
They'll be somewhere between fixing things and making it better to breaking things and creating new problems that eventually need to be undone and re-solved, pushing the quality down and deadlines back.
People tending towards the second group are a waste of time and money. As a hiring manager, to be completely brutal, unless they can demonstrate they are in or have high potential to be near the first group, I simply do not care.
The contribution value of people in the second group is not zero, it's actually negative. Their bad decisions and buggy creations decrease the quality of the product. It's like putting an saboteur on the payroll and then handing them important responsibilities. The team likely becomes friends with them (friendships at work happen about 10 times for every 1 enemy) and this makes reversing the mistake even harder because after all, we are social creatures at heart.
What's worse, after the inevitable breakup, I then have to re-allocate my quality assets away from pushing the product forward to cleaning up the mess someone just left and things stop getting done in the meantime.