4 ms·
Maybe the guy was really dumb or "awful" as the author puts it, but I think it is wrong to blame it all on the hired developer. It's like in sports, there can
by d--b 10y ago
Maybe the guy was really dumb or "awful" as the author puts it, but I think it is wrong to blame it all on the hired developer.
It's like in sports, there can be great players underperforming because of the wrong team / wrong coach.
When a team hires a person, there is a decent amount of time during which the hired person's code is not coherent with the hiring team's. During that period, the hired person must be trained so that the code can match the quality standards / spirit of the team. During that time, other devs have to mentor the new dev, which in itself is "negative work".
What the author is really saying here is "beware of the developer that needs training". Of course it'd be better if all new hires didn't need any training, but it is unrealistic.
Training is necessary for all new hires, not because people don't code properly, but because their coding style not necessarily match the hiring team. You can hire a very experienced developer who you feel spends too much time on testing, while your team has a more "move fast a break things" approach to dev. Or having people who are used use design patterns, because it worked in their previous workplace. There is always some time required to adapt.
Hiring a developer and have him check in 2 things in a period of 6 months is a failure of the entire team. If the guy was so awful, that should have been spotted in the first 2 weeks. And his "awful" code would certainly not have gone through to production.