24
T0D0
21d

I have a junior who really drives me up a wall. He's been a junior for a couple of years now (since he started as an intern here).

He always looks for the quickest, cheapest, easiest solution he can possibly think of to all his tickets. Most of it pretty much just involves copy/pasting code that has similar functionality from elsewhere in the application, tweaking some variable names and calling it a day. And I mean, I'm not knocking copy/paste solutions at all, because that's a perfectly valid way of learning certain things, provided that one actually analyzes the code they are cloning, and actually modifies it in a way that solves the problem, and can potentially extend the ability to reuse the original code. This is rarely the case with this guy.

I've tried to gently encourage this person to take their time with things, and really put some thought into design with his solutions instead of rushing to finish; because ultimately all the time he spends on reworks could have been spent on doing it right the first time. Problem is, this guy is very stubborn, and gets very defensive when any sort of insinuation is made that he needs to improve on something. My advice to actually spend time analyzing how an interface was used, or how an extension method can be further extended before trying to brute-force your way through the problem seems to fall on deaf ears.

I always like to include my juniors on my pull requests; even though I pretty much have all final say in what gets merged, I like to encourage not only all devs be given thoughtful, constructive criticism, regardless of "rank" but also give them the opportunity to see how others write code and learn by asking questions, and analyzing why I approached the problem the way I did. It seems like this dev consistently uses this opportunity to get in as many public digs as he can on my work by going for the low-hanging fruit: "whitespace", "add comments, this code isn't self-documenting", and "an if/else here is more readable and consistent with this file than a ternary statement". Like dude, c'mon. Can you at least analyze the logic and see if it's sound? or perhaps offer a better way of doing something, or ask if the way I did something really makes sense?

Mid-Year reviews are due this week; I'm really struggling to find any way to document any sort of progress he's made. Once in a great while, he does surprise me and prove that he's capable of figuring out how something works and manage to use the mechanisms properly to solve a problem. At the very least he's productive (in terms of always working on assigned work). And because of this, he's likely safe from losing his job because the company considers him cheap labor. He is very underpaid, but also very under-qualified.

He's my most problematic junior; worst part is, he only has a job because of me: I wanted to give the benefit of the doubt when my boss asked me if we should extend an offer, as I thought it was only fair to give the opportunity to grow and prove himself like I was given. But I'm also starting to toe the line of being a good mentor by giving opportunities to learn, and falling behind on work because I could have just done it myself in a fraction of the time.

I hate managing people. I miss the days of code + spotify for 10 hours a day then going home.

Comments
  • 9
    Some people don't want to improve. I have coworkers like that. So frustrating, they wont even spend a minute to discuss new/better ways to solve problems.
  • 5
    Some folks just aren't very self aware of their work and/or choose the path of least resistance, even when they could do better.

    I've worked with some smart folks who just didn't want to try more than they did.

    It can be confusing for folks who can't imagine making that choice.
  • 3
    Your last sentence... I'm with you.

    I had a lot of juniors like yours, never found a constant way to make it work. To each its own.

    You could try to start playing the rank card. Force him then congratz him. After a while, he should have acquired new habits.
  • 7
    Most people in coding aren't actually passionate about it. That people will always try to use the fastest and cheapest solution available to them. They will not invest time to hone their skills if they aren't forced to do so. And even if they do, their skill does not increase as much because they aren't having any fun...

    Just give them the boring tasks.
    They neither can do the interesting things nor can they learn to do them.
  • 1
    @Oktokolo

    I am surprised that people who are not passionate can survive as a developer.

    In my country there is a barrier for the developer. You can say the deck is stack against us.If you work without passion you are weeded out since there are a lot of unpaid overtime.
  • 0
    I share your pain, sounds like we have the same kind of role (and I know what you mean about missing coding - I do still twiddle bits, but it's 10 minutes here and 10 minutes there in-between meetings and emails and all the other lead/management-type garbage, so it's almost worse than not at all some days). It's definitely not easy. As others of said, some people aren't interested in improving... and honestly, some just aren't capable of it no matter what you do for them. We hate to admit that, but it's true. You gotta be able to recognize a lost cause... give every opportunity and help every way you can of course, but there does come a point where you just gotta wash your hands of someone and give 'em that bad review... sometimes, that's exactly what they need actually. Had a case like that last year, and the guy has improved quite a bit. You never know.
  • 1
    @mr-user
    Humans can survive in jobs far worse than non-passionate coding.
    And there are a lot of jobs wich are far far worse than coding without actually liking coding. Some of them are outright dangerous and a lot of them are physically exhausting as hell.
  • 0
    @Oktokolo

    but shouldn't there be a natural barrier in every job.

    I mean if you are not passionate

    1) You make critical mistake which get you fire

    2) You get bore out of your mind so you quit

    3) Your employer realize that you are just a cog in a machine and they replace you with a cheaper people (or a machine)
  • 0
    Options:
    A. Kick him to the kerb, he's clearly not interested in growing as a dev and is a suck on your time and will to live.

    B. Look at this as your challenge at becoming a better people manager. Learn what makes the guy tick, figure out how to put that into his day-to-day.

    C. Do (B) and then (A), because sometimes life just sucks and someone just isn't a good fit. Been here myself.
  • 0
    Fuck, man, I really would appreciate someone who puts effort at something that is basically "optional." And It sucks hearing how others fail to see this and are somehow comfortable about it. Hopefully, I get someone who is chill and looks out to help when needed in a future job.
  • 0
    Yeah, I also face the same problems with some people. It seems you just can't motivate everyone, but it never hurts to try. I think you did good. Next time the boss asks you can just be honest and say that you thought he had a chance to improve, but he's moving anywhere.

    They could try changing his position. I had a junior who started on FE and wasnt too good at it, mediocre at best. We found it he likes BE more and switched him. Turns out he's a quick learner and really took well to it. I enjoyed working with him a lot and he even showed me some things as he was learning!
  • 0
    Sounds like you've analysed enough. Time to verify your analysis with the dev.

    Really, try to understand their point of view. Help them see what you see. Explain why that's necessary and that it's important. If they disagree, talk about it.

    Find out their why and step over your ideas of how this should work (your ego). Only when they cannot even talk about this, let alone improve, then is when you need to start drawing lines, again by taking about it.

    Also, this might not be up to you. You too probably have a superior you can talk to about this.

    And remember: talk to take action. Don't talk to just talk. I hate that.
Add Comment