• 0 Posts
  • 294 Comments
Joined 2 years ago
cake
Cake day: June 21st, 2023

help-circle

  • 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.


  • 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.


  • 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.”


  • 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.















  • jbrains@sh.itjust.workstomemes@lemmy.worldMaths
    link
    fedilink
    arrow-up
    1
    ·
    2 months ago

    If “close enough” works, then it’s nice to have the skill. Having the skill requires occasionally using it.

    Where accuracy is important, since we almost always have a calculator with us now, that’s a no-brainer.

    Maybe more to the point, though, understanding how percentages work is wise. It’s one of the few arithmetic topics that we encounter regularly in life.

    In this case, 23% of 53 and 53% of 23 each have their own little trick, depending whether you’d rather overestimate a little with 1/4 of 52 or underestimate a little with half of 24. I find it handy to be able to think that way, especially for example when trying to get out of a taxi and paying cash.