Programming

17313 readers

252 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]

founded 2 years ago

MODERATORS

[email protected]

221

Other dev won't follow best practices, is this common? (self.programming)

submitted 1 year ago by threedragons_19 to c/[email protected]

54 comments fedilink hide all child comments

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?

you are viewing a single comment's thread
view the rest of the comments

[–] Windex007 15 points 1 year ago (1 children)

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

[–] [email protected] 6 points 1 year ago (1 children)

I've seen this play out a couple time. I agree about a lot of what you said and this is indeed true that you can have very senior and very knowledgeable devs basically "hack" or "bulldoze" their way into a backlog, I would personally argue that this is not a decent or desirable behavior.

There is no such thing as "small finition". Making sure that a change or a feature works all the way through is not finition, it is core to the task, and you can't expect someone else to digest and do the latter half of the work without being in your head.

I guess I am too lazy to type out all the examples with the downfall, but basically if you allow this, you will be shielding a senior from his own butched work, and lets be honest, most people who do this skip the "boring" work for their own selfish reasons. If they want to split the task and have you fix the tests, have them spell it out and justify it.

Management might not understand what is going on, all they might see is a superstar flying through the backlog, while everyone else struggle because they're constantly fixing this guy's shit. This rarely lead to good engineering, or team dynamic, or team management, and of course you end up with this one guy claiming credit for so much shit, while other team members stagnate. Unfortunately appearance is a thing in dev work, as much as I wish it wasn't.

[–] Windex007 2 points 1 year ago* (last edited 1 year ago)

I've seen this play out many times, but only once was it good. BUT ONCE I did see it be good. It was interesting enough that I took the mental notes of why it worked. Huge asterisk because there are still pitfalls around the team having a single point of failure, but that's an issue with many other modes with mixed skill.

Anyhow:

-The whole team was bought into it as a working mode

-There was a QA embedded directly into the team

-The bulldozer was forced, but willing, to routinely re-communicate plans and issues

-The bulldozer became good at proactively communicating "hotspots"

-The bulldozer was not allowed to do estimation, the surrounding team did that.

-The bulldozer agreed to be obligated to prioritize helping the team if they had questions (I think this is what helped him to be so proactive... He was incentivized to avoid this scenario of confusion entirely)

Anyways... I still don't recommend it. But, assuming people are into it, I think there are ways to arrange the right individuals into teams in a way that minimizes the major pitfalls. I'm a pretty big fan of letting/helping teams self-organize into whatever their efficiency maximum is.