Apologies for being nonspecific, but I don’t know how else to describe Bob’s struggles. Bob has been on the team for over a year now, and his code is just… not okay.

To his credit, he can make something that works… but that’s not enough. His code belongs on programming horror. He’s not supposed to be my junior; I’m just the repository’s lead. I spend half my week helping him. Reviewing his pull requests takes hours because it’s always a rats nest that needs significant refactoring/simplification. I’d love to say “do better” - but this is his best.

Most recently, Bob crashed his dev environment with a getter. (A mix of nested parsing logic with Angular’s change detection = CPU crashed). It’d be impressive if it wasn’t so irritating since I’ve already had a conversation with him about proper use of getters/setters. I even demonstrated how spammy the calls can be with a console.log statement for emphasis.

I could go on, but this is enough of a rant. I don’t really know how to handle him going forward; I spend so much time helping and teaching him but he retains none of it.

Is there any hope for him? Any learning material? Advice on balancing my own sanity and workload?

  • WhatTheDuck@piefed.socialOPEnglish
    0·
    12 days ago

    Thank you for the time you’ve spent in your reply; it’s very well put and thought out.

    Ask him to do tasks where the output can be safely thrown away or delayed indefinitely while he tries again.

    This is a great point. He’s been given “easy” tasks with - what should be - plenty of time to finish for an upcoming release. Then we feel the pain when it’s inevitably not done in time and/or being rushed to a finish. Maybe a task that’s harder with no deadline would be less stressful for everyone.

    Is there something Bob should read right now to keep him busy and to give him some chance of producing better output in the near future?

    It’s hard to know what will help him since his struggles seem to be more generic “coding principals” vs something like “understanding Python better.” For example, he’ll do weird things like use a float instead of an int or an Enum of true/false rather than a boolean. They’re small things that make you go “But…why???” …which are challenges of their own to explain without coming off demeaning.

    I’ve given him references for Design Patterns, The Typescript Handbook, and related API references when he starts a task. Do you have any recommendations that might help him?

    …if someone tries to blame you for Bob’s production…

    Thankfully management is very reasonable, and the rest of the team are more aware now. We’re working on sharing the responsibility more.

    • jbrains@sh.itjust.works
      0·
      12 days ago

      For example, he’ll do weird things like use a float instead of an int or an Enum of true/false rather than a boolean. They’re small things that make you go “But…why???” …which are challenges of their own to explain without coming off demeaning.

      Excellent! These are easy discussions if you stick to asking him to account for his thinking. If you struggle to ask “why?” without sounding demeaning, then that’s something you would probably benefit from practising. I had to.

      Moreover, these are relatively safe changes, if tedious, so you can ask him to make those changes and that will slow him down while he learns. If he persists in making literally these same decisions repeatedly, then you know you have a bigger problem to deal with, and that will have to involve people with HR decision-making authority.

      What you describe also makes me wonder whether he indeed needs to know more about Python (or whichever language he’s working in), because an Enum of True and False is structurally equivalent to a boolean and sounds like Smalltalk to me. That could signal someone both unaware of what the language offers out of the box and terrified to ask questions that might be interpreted as dumb. I’m merely trying to account for the behavior you’re describing.

      For someone in that situation, they might need discussions with a patient human more urgently than books. After that, maybe Pragmatic Programmer could be an interesting starting point. I don’t know whether there is a 2020s equivalent to it.

      Thankfully management is very reasonable, and the rest of the team are more aware now. We’re working on sharing the responsibility more.

      I’m very glad to read that, for your sake. Keep going, practise patience, remain curious about Bob, and maybe this will all merely be interesting fodder for a future conference talk.

      Peace.