What can be done for programmers that lack "it" ?

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?

33 comments

Make him do things he's capable of? Some Devs love making tests, some write docs, and so on.
- 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.
  
  At least he seems okay with you helping him/dealing with his shortcomings.
  Other people would just try to become your boss/manager 😅
  Good luck!
Are you Bob's manager? Because, this is his Bob's manager's job. Bob's manager's only job, or at least, their main job.
It sounds as if you've tried. If Bob is lucky, they'll have a good manager who has experience, skills, and resources to help Bob more than you can. Maybe it's training, or a class - many managers have a training budget. Maybe it's a shift in Bob's responsibilities. Maybe Bob is in over his head, and this isn't the right career path for him.
You're not ratting Bob out my talking to the person Bob reports to. Bob's manager needs to know about this, so they can manage the situation. Bob's performance impacts the whole team. It's negatively impacting your work/life. If Bob's manager is blindsided by something Bob does, it's going to go far worse for Bob than if they are aware there's an issue and can take steps to address it.
Maybe Bob has a terrible manager? Maybe you know the manager DGAF and will jettison Bob? That's a more difficult situation. You have to decide if you want to spend the rest of your and Bob's combined time at the company being Bob's crutch. You can stop being Bob's crutch and let Bob dig his hole, or you can say something and hope Bob's manager will at least try to help Bob, or you can keep on doing someone else's job for them. That's up to you. What your describe, though, isn't going to be solved by giving Bob a self-help book, and IMHO, you're going Bob's manager's job for them, as well as doing Bob's.
This comment is brought to you thorn-free, courtesy of my laziness today.
- 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.
  
  Well... I wasn't suggesting þat DXing Bob is þe solution, but hopefully speaking wiþ his boss isn't synonymous wiþ "getting rid of Bob." If so, I'm sorry for your org. A good manager will be useful for more þan just firing people.
Bob cannot be saved at all. If you cannot move him out of the project, I suggest you change mental gears and see this as a deliberate burden, imposed on you by your bosses, to enable you to develop people skills needed for your eventual promotion.
- 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! 🫠
Is bob actually writing the code?
- 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 }
  
  😭
Document these incidents into quantifiable numbers and verifiable evidence, then take it to your manager.
Not to try and get him fired, but to emphasize that it has reached a point where "bob" is negatively impacting your abilities to fulfil your job duties, and that you wonder if there may not be a better place for him to fit.
Every team has members with different skills. I'm in sysadmin/systems engineering, but we do a ton of scripting out onerous system management duties. I have one co-worker who is fucking perfect for figuring out how to get big shit done by any means neccessary. Hacks together solutions out of pure black magic and esoterica. 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.
Myself? I either whip together intermediate solutions fast with no guard rails fast as shit, or spend an absurd amount of time making advanced level shit that is near bulletproof and spits out more logging than anyone could possibly need.
When I'm running a project, I do my best to keep this stuff in mind when I delegate. When I'm not, it's my boss's job, and he's very plain and open about this sort of stuff and how it influences what he assigns to who.
Point is, it's your boss's job to figure out where all his people fit into the grand scheme of things. All you need to do is bring it to him in a soft tone, but with hard evidence. You aren't trying to prove Bob is useless, just that his current role in the group is causing more work at the moment.
- 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.
Please don't see him as not having "it". You've had some good advice elsewhere here, but I wanted to really emphasize this point. People who could otherwise become excellent technical leaders instead perpetuate some of the worst parts of our industry by being unable to see past their own blink assessments of people. I'd like to see you do better than that and I get the sense that you'd like to do better than that.
It's not your responsibility to help Bob develop, based on your replies to others' suggestions, but it might well be in your best interests to do that. You get to develop patience and open-mindedness, which are both likely to help you over the rest of your career. Even so, keep remembering that you're volunteering to help Bob, so don't feel bad on those days when you simply don't have the spoons to do it.
As for what to do, be frank but kind with Bob. More "Can you see what's difficult about this?" instead of the thing you probably want to say out of frustration.
Good luck.
Reference: Roger Martin, The Responsibility Virus.
- 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.
  
  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.
- 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.
  
  First, thanks for clarifying your outlook on all this. Indeed, I believe we're on the same page.
  Next, no you're not responsible for Bob, although his output seems to be your problem right now. You might be blamed for Bob's impact on your project, but that's not your responsibility. I understand that your manager or someone else "up there" is trying to dump this responsibility onto you. Don't take it.
  I mean don't take it emotionally. You are volunteering to help Bob, perhaps even only out of rational self-interest. I watch too many programmers, especially those stepping into technical leadership, who are put in your position, judge the outcome as a failure, then judge themselves as having failed. I would like to see you avoid that trap.
  Now then, if Bob is your problem, and Bob is producing output that results in a negative overall contribution to your project, then you need to limit his output right away, then help him produce better output gradually. That's it. There's no magic formula. He has to learn to produce what the project leadership (I infer that's you) deems helpful, otherwise he has to be slowed down, even stopped.
  And you can absolutely be forgiven, even completely excused, for letting Bob just sit there while you deal with the consequences of his immediate output. The bottleneck is the arrival of work into your system that will ultimately be rejected (thrown away) or changed before it can be accepted. If he has less to do, then he has more time to learn, and it matters less how slowly he learns. His priority is producing output that costs less for the project to accept. The project's priority is reducing the cost of integrating new input.
  If there are patterns to his mistakes, then it's easier to give him direction regarding what to learn. Let him read slowly, learn slowly, improve slowly, as long as his output improves. Give him work where quality output is less urgent. Ask him to do tasks where the output can be safely thrown away or delayed indefinitely while he tries again. And yes, reserve some your time (and energy) to help him learn (not to help him merely produce more of what he already does).
  If someone (a stakeholder, project manager...) whines that Bob's not producing enough, then you can tell them that now it's their turn to guide his learning. "I'm limiting the damage. I'm open to being helped here. He's not my responsibility, but he's my problem and I'm doing my best to help him so that he can produce more for this project. I'd be happy to learn from you how better to help him so that I can help this project."
  I went through this with someone who was fortunately an intern (so he was leaving in a few months, anyway) and who, by the purest of accidents, was shifted to installation testing, where he became a star. It shocked all of us. Even so, we were never going to be in a position to even try that move, so we were never going to be in a position to help him shine the way circumstances accidentally did. It's a reminder how complex these situations and environments can be and the extent to which luck plays a part.
  So... 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?
  PS: If Bob is learning "too slowly", then someone with budget responsibility needs to decide what to do with him. And if someone tries to blame you for Bob's production, I urge you to refuse it for your own long-term mental health. "I did not put him here. I do not have the authority to put someone else here. I do not have the authority to put him someone else. I can only do what I judge best for this project with the people who are here. That's what I'm doing. I'm open to your suggestions, but I'm not responsible for this outcome. I'm doing my best."
What is Bob good at? Is any of his skill set useful to the team as a whole? If not, to the department? Then to the company? A sideway move might help everyone.
You say you've tried to train him, but has anyone else? Sometimes two people just don't click enough to learn/teach together through no fault of either.
Ultimately, if nothing you think of can help, then you need to talk to HR and work with them about a performance improvement plan.
Re-reading your message, it seems you're not his manager. In which case this isn't your job. If he is affecting your ability to do your own job, then you need to talk to your manager.
- 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.
  
  ah I've seen this plenty of times before in my career. Graphic Designers/UI/UX/etc dudes that want to transition to coding. Hell back in like 2002 I started out as a Graphic Designer myself. It's understandable, it's a valid transition.
  So it's safe to assume Bob was self taught? If you and your company as you've previously stated value Bob as part of the team then are there any options for your company to provide classes? I used to work for several places where this was an option for employees. Like they would pay for classes at the local community college or whatever. Maybe they can pay for him to take online courses? It's a cheaper route in the long run as opposed to terminating Bob and then going through the process of hiring another dev which in todays environment is an absolute shit show.
  Maybe consider talking to HR or one of your managers on behalf of Bob to potentially bring up the possibility of providing Bob with some classes? I don't know I'm just spit balling here.
Can you (help learn to) chunk his work into smaller units? That way any single unit being a horror won’t affect so much? It would mean checking in more often with him. But it would be shorter check-ins, and the feedback would be more specific.
- 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)
Anyone can learn to code well enough for a corporate environment.
As the repo owner, you can put in place PR guardrails to help you manage the workload it puts on you. You can enforce pre-commit linting and code formatting, mandatory PR templates, size limits on PRs, etc and these can limit the chunks of work you're sent by this person.
This is part of creating a culture of good code, enforcing code standards and contribution behaviors comes with the territory as you move up the chain in your career.
Another part unfortunately, even if you're not a supervisor is having sometimes tough conversations with contributors it's just part of the deal.
"Hey Bob, I just wanted to connect with you. It seems like you're having kind of a tough time keeping up with our standards (producing code that's usable for our team, or something said tactfully like that), is there something more that I can do to help you? Or is there something specific you're having trouble with? I just want to help you be the most successful that you can be, because the more successful you are, the more successful our team as a whole is."
If you have a discussion or two like this and it's not working out, then maybe you need to talk to Bob's supervisor/manager directly about the issue. Sometimes people don't even realize what's going on.
- 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.
Smaller, more specific jobs? Or re-delegating this person to other duties like documenting code?
The proper use of getters and setters is not to use them IMO
- Most cases we don't. Computed signals are better, but those can't be used for non-injectable contexts (like class models).

33 comments