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.

Most cases we don’t. Computed signals are better, but those can’t be used for non-injectable contexts (like class models).

I’d like to see you do better than that and I get the sense that you’d like to do better than that.

I’m not quite sure what you mean in your first paragraph. I think it’s trying to address the gatekeeping elitism experts can have? Like “they can’t code to my expectations they’re not developers worthwhile” attitudes? I agree those types are a plague, but what I’ve said here shouldn’t be in that territory.

We don’t know how to properly quantify what knowledge/skill gap Bob is missing… just that there is one and we’re at a loss for how to improve things. That’s why I’ve used “it” for simplicity.

Even so, keep remembering that you’re volunteering to help Bob…

I’m… not volunteering. 😅 “My” section of the app has the most flexibility with the work available, so he’s unofficially become my responsibility.

It’s like I have an unfilling part-time teaching role ontop of my other responsibilities. Don’t get me wrong; I don’t mind teaching nor helping someone most days, but it’s exhausting over an extended period of time with such little progress.

I hate seeing him drown with every task he’s given. He’s a good person who’s genuinely trying to get better.

Regardless, thank you for the good luck and everything.

This gave me a good chuckle. If only that were true! I’m not in a typical work environment – promotions/bosses work differently.

My people skills hit their maximum potential from previous management roles… There’s no where but down from here! 🫠

Anyone can learn to code well enough for a corporate environment.

The bar is even lower for a government environment. 🥲

Thankfully, we’re already setup with a linter/auto code formatting. Mandatory PR templates/size limits would probably be overkill with a team this small - but I get your point. He really just needs to stick to the ticket’s original scope and I’m going to harp on it more. We just had another talk about it on Thursday.

I appreciate the suggested dialogue. We’ve had conversations like this - mainly to see his openness to a lead in developer-adjacent things like testing. He’s not very… self aware or well experienced career wise to say the least.

We’re at the “figure out somewhere he can fit” or “remove him from the team” phase. We’d prefer to find a way to keep him.

Thank you for the sound advice/suggestions though.

Yes, only he could create such a beauty like:

switch(thing) {  
  case A:  
    console.log("Case A!")  
    break; 
  case B:  
    console.log("Case B!")  
    break; 
  case C:  
    console.log("Case C!")  
    break;  
  ...   // This continued for 8 other cases  
}  

I agree with your general sentiment. No, I’m not his manager. Yes, it’s not my job to hold his hand.

This post is mostly a sanity check / seeking options. We’d prefer to keep him, but ultimately it might come to that.

Haha - at first he didn’t! We had a learning good moment though.

He was really frustrated with his first pull request basically telling him to rewrite everything. He didn’t see the value in spending more time on changing so much when his “worked.”

After talking about the importance of long-term maintainability and stability etc etc, I told him about my PR experience on a previous project with a single other developer on it. We had different styles/preferences which sparked plenty of discussions/debates in the PRs. It could be so frustrating, but we taught each other so much and I honestly miss that.

There’s nothing like learning a new trick that deletes 200 lines of pain and suffering.

Appreciate the advice; I’ve been indirectly documenting it with the other devs since they were wondering why Bob’s pull requests take 2-3 rounds of fixes. (They were starting to wonder if I was just being a hard ass about everything).

But holy shit I am never ever letting him script anything that has the potential to last beyond a few months, as it’s brilliant, but completely unmaintainable, impossible to debug, and generally can’t handle edge cases.

This sounds like Bob, but subtract a few years of experience… but finding things with a short lifespan is hard on a project that’s all new code. The architecture/long term planning is crucial and that’s where Bob struggles.

Point is, it’s your boss’s job to figure out where all his people fit into the grand scheme of things.

Agreed, but it’s a small team of 4 devs (myself included) + 3 others. We’re basically at the phase of trying to find him something or else we’ll need to remove him. He’s a good fit socially and is genuinely trying.

Bob has great ideas / an eye for design, which has definitely helped. Unfortunately, he’s here as a developer because he wanted to move away from the webdesign space so nudging him that direction isn’t want he wants.

He was fully on our backend at the start and was getting help from another dev. He’s now on the frontend because that dev needed a break and was hoping the familiarity/different language would help. The problems I see are language non-specific, like basic programming principals/architecture.

Bob would probably do fine on a team that’s just maintaining a legacy codebase, but we’re writing everything from scratch.

It’s a weird work environment; HR/performance improvement plans aren’t really a thing. We’re basically at the step of asking if he should be removed but trying to find something for him. He’s a good person and fits well socially.

That’s the struggle? He’s in a weird space where he’s capable of prototyping solutions/things, but are problematic long term.

We’re a really small team, so it’s hard to justify pushing him towards alternatives like writing tests/docs. I would love to get more automated testing though, maybe I’ll revisit the topic.

I’ve been trying to. The giant pull requests are his own self-inflicted pain. He’ll massively expand the scope of the original ticket – or does everything all at once rather than one piece at a time. It’s something we talked about, again, on Thursday because his current ticket was supposed to be a quick 1-day thing that’s now 2+ weeks. The additions are good ideas, but easily should have been their own tickets/done afterwards.

(I was on vacation when he was assigned the task; it’s too late to course correct)