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?

  • atzanteol@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    3
    arrow-down
    1
    ·
    edit-2
    7 days ago

    Mmmm, I see where you’re coming from. But on the other hand I’ve worked with a few “Bobs” in my day and they really are useless bordering on stupid. Some people simple aren’t cut out for software development. They’re often very nice people and I feel terrible about the situation they’re in. And I’ve seen companies throw training at them to no avail. I’ve spent so much time patiently training and teaching them. They do not improve. They don’t understand. It just isn’t worth it. They’re negative productivity with all the hand holding they require. It always becomes a situation where I would be more productive simply doing their job for them in addition to my own.

    Sure - they can learn. But it’s often “you told me to do this” without any understanding of why and when to do that, how to do something similar but different. They have a “notes.txt” file with the dozens of code snippets you’ve provided them, when exactly to apply them, what commands to copy/paste to do the basic necessities of their job, etc. All without any understanding or desire to really know what those commands do or why they should do what they’re doing. It’s like speaking a language from a phrase book vs. learning the grammar and vocabulary.

    It sounds like OP has been patient. They’re hitting that point where they’re realizing that Bob will simply be a drain on their time.

    I’d say cut Bob loose. Make sure management is aware of the situation, and start to minimize Bob’s impact on yourself and others. It can be absolutely draining to drag a Bob along with you like a boat anchor.

    Edit: And by “cut loose” I don’t mean to ignore them or reject helping them. Just minimize the amount of hand holding being done. Reply in slack vs. multi-hour long meetings in person/zoom. Email links to more info rather than chewing and digesting it for them. Etc.

    • jbrains@sh.itjust.works
      link
      fedilink
      arrow-up
      1
      ·
      7 days ago

      I have no problem with letting a worker go if the investment in their learning far outweighs the benefit. At the same time, most organizations over a few dozen people have more than enough cash to absorb giving the underperforming worker more time to turn things around. Yes, even in this economy.

      I think that random people on the internet not living in that context right now, no matter what their experience level and good intentions, ought to be considered a reliable resource for judging whether specifically Bob needs to go from specifically this place specifically right now.

      • atzanteol@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        1
        ·
        7 days ago

        At the same time, most organizations over a few dozen people have more than enough cash to absorb giving the underperforming worker more time to turn things around

        That needs strict timeboxing. Because they generally don’t “turn things around”. Often they’ve been at the company for decades and everyone just assumes they’re doing something right because “why else would they still be here?” They just get shifted from department to department looking for something they’re competent at.

        What happens is that they just end up a burden on more productive and nice employees. What you see as some sort of welfare I see as “great I have to work with somebody who has no idea what they’re doing - and my deliverables depend on this idiot”. You can’t help everybody. At some point you cut 'em loose.

        Granted I don’t know the exact situation OP is in - but they need to know that there should be a limit to their willingness to help and train unless it is explicitly their job to do so. And that’s okay.