The Worst Programmer I Know (2023)

What is your purpose? Making the team perform great, I hope. Will you achieve that by picking on someone? Hell no. Others will protect him, because they know they will be next in line. Do you think the "underperformer" (if he really is that, even) is doing that because he is lazy? It is more difficult to ask for help all the time than just to do something.

How about you try to find a way to help him achieve the level that others are at? THAT is what should be your goal. Instead of spying on them, award team members who help others, so that they won't feel the need to hide. And make weak members feel safe. Currently it sounds like the environment is pretty toxic with regards to admitting to any problems.

If, after all the genuine effort, you still fail and need to let go of the guy, because he is really bringing productivity of the team down and you can't motivate him to change, then you should know that this is still primarily your own failure. Which is ok, everyone is allowed to fail from time to time. But it is a signal that you should try harder.

(speaking as someone who had to let someone go because I wasn't good enough to make them better... on two separate occasions... so I'm not judging)

It means, this team was very much a team built out of the resources available, because the existing experts in the company who could have been mentoring new grads were already working full time doing something with a direct contractual obligation to the company. I would have been negligent to pull them from an existing inprogress contract to mentor newbies, and the contracts had a hard limit on number of hours, (not years of experience), so placing a new grad on one of these contracts, replacing an experienced engineer would have degraded the success of the contract.

> Yet your other comment says, "this particular company paid way below market rate with the promise of interesting work. It without a doubt incentivizes hiring new grads where you roll the dice and hope the good ones will stay because they enjoy the job. It's very hard for them to attract experts at the salary that they're offering." https://news.ycombinator.com/item?id=43453700

Right, they're not conflicting statements. The company would hire a pool of engineers that can do engineering, then a different part of the company would sign contracts to complete work, than a middle part would place the engineers in the company onto contracts.

> I'm having a hard time understanding why this project needed to exist at all.

Well, because it was a really cool project that the company did end up marketing and selling to it's various clients. It was also a perfect project to put a bunch of new grads who otherwise wouldn't have been doing any work at all given the projects had contracts that stated they couldn't accept more engineers.

> I disagree, and it only created unnecessary argument in this case. You ended up having to retract and clarify anyway:

I didn't retract anything? Are arguments bad? I actually enjoy being able to arguing interesting points and topics. If you're willing to be wrong, you can learn things. As an example I didn't think my previous examples were so controversial. Nor did I remember that contract based engineering work isn't a common thing the most people already have intuition for.

> [just like 5 to zero is bad...] But the team was 5 to zero.

The team you called pathological? Yeah, it was bad. Missing deadlines is bad. I don't understand where you're confused.

> [just like 1 to 1 is bad...] Why?

I already answered. Because of politics a project that small would have died with a team with just a single new grad. It also would have been boring as fuck. So if I left, I'm sure the new grad would have also left. Which means the company who hired us both, would then have to hire two new people. This was years ago, but I assume some of those original new grads are still there. In part because that team was actually fun to work with. They were good people, and the team was just fun to be around. A team of just 2 is boring... I know because I've also been on that team with me doing all of the work, and it was soul crushing, and contributed to why I left.

That said, at every place I've worked you could get a starting point idea of who the top devs were by looking at overall code commits. This Tim sensei situation may be more common than I think, but I've never run into it.