What do you do when you give someone a feature ticket and they come back and the code just isn't what you expected?

Like to you how they did it, assuming they actually finished, is very hacky and not well designed/thought out?

And ur going to need to cleanup a lot of their code? And explaining to them how to do it is just not worth the time and will take longer then just doing it urself?

They just don't seem very bright or able to "get it".

I guess how do you go from a developer to a manager? And deal with devs they don't seem to be writing code they're up to your standards/expectations?

📌

First 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.

I 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.

@NEMESISprj well specifically they piggy backed off existing code by adding an extra flag to the main method and if statements throughout the existing code to trigger his "override logic" where ever is needed... rather than giving thought to and doing a proper refactoring...

@donuts ah those types. Yeah I guess you just have to tell them plain and simple what is expected from them

You 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.

@AlmondSauce well I'm not the team manager. What I meant was more like Senior-Junior relationship but well the other guy is supposed to be Senior/experienced too...

So i'm like the owner/lead dev for an project.

And I'm just going sorta isn't the quality I expected

@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.