Hello again, I’m in a situation where the one the senior devs on my team just isn’t following best practices we laid out in our internal documentation, nor the generally agreed best practices for react; his code works mind you, but as a a team working on a client piece I’m not super comfortable with something so fragile being passed to the client.

He also doesn’t like unit testing and only includes minimal smoke tests, often times he writes his components in ways that will break existing unit tests (there is a caveat that one of the components which is breaking is super fragile; he also led the creation of that one.) But then leaves me to fix it during PR approval.

It’s weird because I literally went through most of the same training in company with him on best practices and TDD, but he just seems to ignore it.

I’m not super comfortable approving his work, but its functional and I don’t want to hold up sprints,but I’m keenly aware that it could make things really messy whenbwe leave and the client begins to handle it on their own.

What are y’alls thoughts on this, is this sort of thing common?

  • Windex007@lemmy.world
    link
    fedilink
    arrow-up
    19
    arrow-down
    2
    ·
    11 months ago

    There isn’t enough information here for me to say, but this MIGHT be similar to a self-organising dynamic I have seen before.

    Maybe there is a dissertation somewhere in the dirth of programming team-dynamic books that has given it a name… But I just think of it like a medieval bulldozer.

    Sometimes you have a headstrong dynamo who can and does crush through problems at a FANTASTIC rate. They have strong domain knowledge so everything is functionally correct. There may be some bugs (all code has bugs), but nothing that requires a re-design. But thier velocity is triple or quadruple everyone else’s.

    But… This comes at a cost of things similar to what you said. A general disinterest for the “small things”, a reluctance to break their flow by going back for small bugs they missed. Skimpy test coverage. Since those things HAVE (asterisk) to get done eventually, they tend to pull less experienced devs into their gravity well, and they just end up in thier orbit applying thier full time efforts to patching the holes left behind.

    That’s why I imagine them like a bulldozer in King Arthur’s court. They’re just a machine with the capacity to drive a mind boggling amount of blunt work, but require a small army of “finishers” to follow behind to add the finesse after the violence.

    A few questions I would be mulling over and asking myself if I were in your situation:

    Is this guy able to ship features orders of magnitude more quickly than his peers (regardless of style metrics?)

    Does management seem to be aware but unconcerned?

    If so, this is probably your situation. Your managers have a bulldozer and they figure it’s more effective to just let him do it and have you clean up after him.

    It’s ACTUALLY a pretty sweet gig if you’re getting compensated well. You’re shielded from needing to make tough decisions, design decisions. You’re shielded from time crunches.

    But… It’s maybe not super fulfilling. You might resent being in the shadow. You maybe want the opportunity to stake your own claim rather than just riding in this other person’s wake.

    If that’s the case, I’d generally follow the advice given by others here… But make sure you truly understand the management dynamic before you start making moves that are too bold (such as, say, blocking PR merges that by convention were being merged in the past without anybody seeming to mind)… Because if right now management doesn’t see a problem, and you start refusing to merge PRs management will suddenly see a problem on their radar, and that problem will be you.

    Honestly a frank discussion that you feel like your talents would be better applied to your own parallel work tasks rather than tagging behind the bulldozer in serial is probably the best way to go. You don’t need to shit on or diminish your coworker in order to plead your own case.

    The truth is, as much as everyone in this conversation will hate to hear it, there is probably something you can learn from this person… If only how they were able to bend their environment so effectively into what they wanted