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?

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

    Another thought came to my mind that might help. It is complex and will require some rambling. I apologize in advance.

    In situations like these, I want to show compassion and reach a mutually-agreeable resolution. I want to avoid passing value judgments about the other person. My experience with that intern taught me not to frame situations like this as “They have ‘it’ or don’t have ‘it’”. Anyone can do this, but maybe some folks can’t do it efficiently or effectively enough to hold a job doing it. Instead, I prefer to assume that a mutually-agreeable resolution lies in agreeing on what we’re going to try to do starting now and what we’ll do when we worry that we won’t be able to keep our agreement. In the case of Bob, the agreement can start as simply as “You won’t use a two-value Enum, but a boolean instead”. We have to start somewhere.

    In order to real a mutually-agreeable resolution, as opposed to making a decree and expecting Bob to follow it (and punishing him when he doesn’t), I typically expect the people involved to feel like someone has tried to understand them and that they have had input into the resolution. This allows them to become “autonomously motivated”, to use the language of Self-Determination Theory. (I promise: no cult. I merely wanted to put a name to it, in case it then interested you to go read more about it.) “Controled motivation” (decree + enforcement) tend to lead to short-term compliance, which often means that they’ll fail to comply at the worst possible time (Murphy’s Law). It’s less risky to cultivate autonomous motivation. There are wide-ranging theories about how to do that, but mine include what I’ve said already in this paragraph.

    We are (typically/often/largely) not trained to listen to people, but rather to wait until it’s our turn to speak by rehearsing what we intend to say. We are (typically/often/largely) not trained to cultivate true Buy-In and Commitment (Patrick Lencioni, The Five Dysfunctions of a Team), but instead to believe in fantasies such as enforcible meritocracies where rational considerations lead us to do everything The Right Way and new people merely have to Drink the Purple Juice and get on board. I mention this because we need to practise these things. We need to practise listening until that becomes a habit. We need to practise cultivating shared ownership of ideas until it becomes a habit. We need to practise seeing contoled motivation as a last resort when the risks of short-term compliance + Murphy’s Law actually seems lower than the risk of our Bobs continuing to do the strange things they do.

    We can practise by role-playing with people we trust, so that we can become aware of when our impulses under stress clash with the behavior we’d rather engage in. Gradually, we see our impulses coming from farther off, so we can step in and choose differently, even under significant stress. This is a life-long pursuit that the general population loosely calls “(emotional) growth”. ;) But what do we do with Bob, whose way of thinking seems so alien that we can’t possibly role-play him effectively? If we can’t practise talking to Bob without risking actually talking to Bob (and falling into our old, unhelpful patterns), then what’s the next best thing?

    When in doubt, be curious.

    Yes, I know. That’s dumb, but it works. If “curious” feels too fuzzy, then be open-minded. Consider more possibilities. Challenge your assumptions about what’s right and good and sensible. Here are two principles that help:

    • The Law of Three Interpretations: keep telling yourself different stories about how Bob (or the other person) is behaving until you have three distinct stories. For now, you might have to do this as post-interaction analysis, but gradually you’ll be able to do it better and more easily in real time while the conversation with Bob is happening.
    • Ask yourself “What would have to be true for me to behave like that?”, then assume that that’s pretty close to what’s happening for Bob (or the other person). Ask questions intended to check this guess and you’ll notice yourself being more curious/open-minded.

    If you do this, then there’s a very high chance that Bob will feel safer to tell you what’s happening and you’ll find more compassion for his choices. For example, I chose an Enum because I know that having multiple booleans can be difficult to understand and lead to defects when combinations of values of True and False can be meaningless or misleading. I know that improving this design means replacing the booleans with an Enum, so I chose to jump to the Enum now in order to avoid refactoring away from the boolean later. I’m not saying that Bob is thinking this, but I’m saying that if Bob were thinking this, then I would understand and have trouble disagreeing with him. I would realize that my preference for already using a boolean is in fact merely a preference and that other people might have other preferences, and although I don’t evaluate the risks the way Bob does, if I did evaluate the risks the way Bob does, then I might find Bob’s reasoning pretty reasonable.

    That’s the benefit of curiosity and open-mindedness.

    Once you’ve understood what Bob is thinking, it becomes easier to suggest or ask for alternatives. “Yes, Bob, I get it. I genuinely don’t think the boolean in this specific case was a risky choice, but I understand your general reasoning. Here’s what I’d like you to do: assume that replacing the boolean with an Enum is not going to be a problem and let us enjoy the simplicity of the boolean in the meantime. We’ll spend a lot less energy tripping over the unexpected boolean and from the energy we save, I’m confident that we’ll be able to handle replacing boolean with Enum in the few cases where that becomes necessary. In fact, I think of that refactoring as so easy that I don’t even thinking about when I do it. (Bob might interject to tell you here that he still gets tripped up by that refactoring, which is why he prefers to avoid it. Reasonable!) If we reach a situation where we regret choosing boolean over Enum, and if we start yelling about it, then we’ll rethink out Sensible Default Choice. For now, however, I need you choose boolean over a two-value Enum. Will you please do that?”

    Now yes, that might seem like a lot of effort to resolve this issue, but it will probably require less effort the next time, then less, then less… Bob will either gradually converge closer to the conventions and preferences of the group (while occasionally asking for his own preferences to become Sensible Default Choices) or he will dig in and resist in spite of your best efforts. If he resists, then you can choose whether to try to explore that using concepts from Dale Emery’s “Resistance As a Resource” or you can get The Firing Person involved as an arbiter. Only you can choose what’s right for you in that situation when you come to it.

    OK. Rambling over. Was there anything helpful in there? I have a cold right now, so although I feel clear enough to write this, it’s possible that my brain is fuzzier than I believe. I tried. :shrug: