Topic: how do you tell someone...

[micah]

...that their code is absolute shit?

First of all, he are young, right out of college with no practical programming experience.  Honestly, I was against even hiring him but he's the friend of another coworker so it was like an automatic in. Anyway, he came to me for help with something not working so i said I'd take a look.  The code is just a hot mess.  So so much wrong with it. I'm surprised he ever got it to even run in the first place.  I just wasted 90 minutes trying to fix things just so i could understand what he was doing...then I gave up without solving his original problem because I just don't have time for this.  I have my own deadlines and my own problems.

So I messaged him back and said, "I need to step away from this for a bit, sorry I wasn't able to help." I went on to say that his problem that he came to me for, is probably in the multiple nested XHR (this is javascript) calls and the fact that he's repeated huge chunks of code instead of creating smaller reusable functions.

I feel like that was me being nice.  I don't want to refactor his whole app (nor should I have too) but I honestly don't want him checking this clusterfuck into my project.

Thoughts?

[Mike]

Yeah, it is tough.  I generally try to call a shade a shade in this circumstance.  Something like "I'm spending too much time just trying to understand what you are attempting to do.  I need you to break things into smaller pieces, reuse existing logic, and following the coding standards.  If you are still having issues after that then come back to me."

One thing I'm struggling with as the lead is trying to get the others to understand/see the art side of it.  Code (IMO) should have a flow to it, should be readable, should look nice, etc.  I had someone put up a PR that had both a left and right join and a union.  I could count the number of times I used a right join on one hand after a drunken knife game.

Do any of you following the the function complexity and max length rules?  I generally turn it off in the linters but I always wonder what it'd be like to constrain myself that way.

[ober]

As a manager, I've had to deal with this stuff a number of times.  You cannot just shove them off and say 'come back to me when you git gud'.  They won't get better.  You have to take the time to mentor them.  But what does that mean?

Mentor in chunks.  They come to you with a problem.  Start by helping them to break it down.  Teach some basic debugging skills.  Then when they fix the problem and submit it again, highlight ways to DRY up the code.  Once they DRY up the code, look at readability.  Once it's readable, see if it's maintainable.  I once had a senior dev write a book in a code review to me where he spelled out the issues.  He didn't fix them.  He didn't touch my code.  He pointed out the issues and at least one way I could potentially address them.  He left it up to me on how far to go and how far to refactor but he gave suggestions on what he would do.

Just remember it is not YOUR job to fix their issue.  It is YOUR job to help them grow and understand better ways of doing things.  And personally, it has been my experience that honesty is the best course of action.  Do not sugar coat it.  A lot of devs will take it as a personal challenge to improve their code if you are clear that it doesn't match coding standards or is a mess.

I will also say that sometimes some people just aren't good engineers and will not make it.  Some people just don't have the mind for it.

Micah, one last thing.  Do NOT let someone get hired just because they are 'a friend'.  That can get messy in a number of ways.  You don't owe it to anyone and you're not doing yourself any favors.

[Mike]

Micah, one last thing.  Do NOT let someone get hired just because they are 'a friend'.  That can get messy in a number of ways.  You don't owe it to anyone and you're not doing yourself any favors.

Not always our call.  Sometimes all you can do is give your input to the person making the hiring decision and hope they listen.

A lot of devs will take it as a personal challenge to improve their code if you are clear that it doesn't match coding standards or is a mess.

Can you send a few of them my way?

[ober]

That's fair if you don't have direct hiring power.  But you should at least make a strong case against that kind of thing.  Nepotism is a powerful thing that can ruin a culture and ruin a company.

I've got a whole floor of devs like that, Mike.  It's part of the reason we fired 70% of the floor last year and started over (and the reason another 20% left on their own).  And myself and the other managers I work with have hired devs with specific traits: humble, hungry, and a clear desire to do better regardless of the task.

[micah]

I agree.  I was part of the selection and interview process, but in the end, it was my boss's call. I specifically green-lighted 2 or 3 candidates who I really like - they were a bit wet behind the ears too, but had great examples of projects they had built on their own by learning on their own.  They clearly had the drive and passion for the type of work. But those choices were over looked for whatever reason  and we went with this dope.

[ober]

God that sucks.  Has the hiring manager been a dev?

[micah]

God that sucks.  Has the hiring manager been a dev?

No -- well, maybe in college 30 years ago -- but he's been in tech management for the past couple decades after leaving the military.

[ober]

That's half your problem.  People that have never professionally programmed do not know what to look for in a good developer.  They're often terrible interviewers as well.