Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
craig939393257833dFirst ensure that your concerns are accurate. There is a difference between not knowing, and being unwilling or unable to learn.
After that give up is my advice. If you're on the position to do so, move them to less important tasks that are much less crucial to business success. If they can't even do that, and I stress that some just need guidance, sacking is the best choice. I learned the last few years that someone who doesn't know basics after years in industry is probably a lost cause.
NEMESISprj41532dI am in no way a manager or whatever, but whenever I create tasks for others, I make sure that the "definition of done" is as clear and complete as possible in a few lines. That way you can at least control the "I didn't know what you wanted me to do" excuse/problem.
I've received several tasks myself which simple stated "create x for y" and that's just hopeless on so many levels...
If people simply ignore your requests or perform way below expectation, I'd suggest to talk with them about it?
Edit: if they are reaallllyyyy way below standards you should certainly let that know to the higher ups imo.
Idk. Different developers will code differently. However there are standards in OO and imperative (and frameworks) that should be met. If the skill level is appropriate for what he was hired (ie junior or lower intermediate) then he should be taught and given direction. Also, should define what is expected next time and to use existing code as reference for how it should look be done.
Maer126932dYou have to be able to explain *why* their solution is inadequate, otherwise I am arguing that you don't understand the subject matter either.
As in, you memorized from sources how to do certain things, instead of taking the time and understanding the reason for doing then that way and even more for not doing them a different way.
Capable developed are able to explain why a bad practice is bad in the first place. Just repeating what others posted without understanding the reason is a skill accomplishable by a parrot.
You make sure that you have a thorough code review process where yourself and other Devs can give feedback and request changes before things are merged. It's worth taking the time and being detailed with this feedback even if you feel you could do it quicker yourself, as you're making an investment in another team member so they can get up to speed with these things and then work it out themselves later.
If that's still not happening after an unacceptable level of time, then that's when you need to step in as a manager and set targets and performance reviews to make sure the dev in question is reaching the standards they need to. But that needs to be separate from the standard code review process.
@donuts You don't need to be the lead to code review and point out issues. Everyone should be encouraged to do that to everyone's code. I go out of my way to make sure juniors review my code, and they often point out things that I may have missed.
Realistically, you do need to be someone's manager to pull them into a meeting and talk about performance of course - beyond suggesting it to your manager there's not much else you can do there.