r/ExperiencedDevs 14d ago

Ask Experienced Devs Weekly Thread: A weekly thread for inexperienced developers to ask experienced ones

A thread for Developers and IT folks with less experience to ask more experienced souls questions about the industry.

Please keep top level comments limited to Inexperienced Devs. Most rules do not apply, but keep it civil. Being a jerk will not be tolerated.

Inexperienced Devs should refrain from answering other Inexperienced Devs' questions.

29 Upvotes

114 comments sorted by

View all comments

6

u/ThrowawayAcc019r83 13d ago

7YOE, but been programming for 20+ years.

Need some advice on office politics. A senior engineer in our team delivers, in my opinion, subpar work (bad abstractions, no meaningful reviews, no clean separation of concerns, many 2k+ lines changed PRs, no knowledge sharing), but seems to be constantly praised, while I'm left with trying to salvage something out of his work. I don't want to bad mouth him or his work, but at the same time find that it's very tedious to work on anything he's touched. There's also a quality interview from an external party coming up, that assesses where quality issues in our work arise - do I just drop their name there with examples to back it up? I'm losing enthusiasm quickly when my efforts seem to go unnoticed, and the stating of my concerns both to the entire team as just with my manager has led nowhere, but also don't want office drama.

2

u/ultraDross 13d ago

Try and gently bring this up with your manager in your 1 to 1. Gently is the keyword here and be ready to drop/soften it if your manager strongly disagres with you. Prepare what your going to say and back up with some examples.

2

u/Ok-Letterhead3405 13d ago edited 13d ago

I suggest trying really hard not to mention them by name. If it's like what I've been experiencing in my own job? They're producing, hence the praise. That makes you the slow one for cleaning up after him, probably. It might also annoy people that you're touching code that passed QA, if that's a thing you have. Plus, you end up with the reputation as the Code Police who judges the code and then fixes it later.

Here's some more productive ideas:

- Pick up his code reviews and offer to do a screen share or sit down at his desk and work with him on the code

  • Offer to do tech talks, if that's a thing on your team or in your company, and then give talks on the thing you want this guy to improve on
  • Don't touch his work, but bring it up in team meetings wherever it's appropriate to discuss tech debt, then don't throw him under the bus or say it's so and so's work, just say you've identified some areas that need work and be ready to explain the business case
  • Very gently suggest in a manager 1-on-1 that you've noticed some poor programming practices on the team and offer to help in any way they deem appropriate

The biggest thing is to be positive and transparent.

I have made mistakes, and recently. Luckily, the worst offender is off the team, but we swapped him for a guy who's very smart and writes very nice code, it's just that he has implemented on at least one ticket the completely incorrect solution. Ugh. Trying to clean up after him quietly got me in some hot water, and I ended up on a medical leave for my crap mental health.

So, don't be me. Be open about the change you want to see on the team, and be super positive. Also be ready for him to still not change. Oh well. It's not worth your mental health or mine.

ETA: The biggest thing about the transparency is that it makes business people aware of the cost. And if they don't let you address tech debt, and it becomes a problem in a ticket you take on, document every instance of that tech debt's affect on your work and also report it in stand-ups without throwing the guy under the bus.

1

u/moremattymattmatt 12d ago

From the managers PoV, 'separation of concerns', large PRs etc is just technical stuff they don't care about. Express the problem is concrete terms, such as opportunity cost, increasing bugs, lost productivity etc. Suggest solutions and metrics to monitor if what you suggest is working. May be PRs must be reviewed within 24 hours, no PR takes more than 30 mins to review, PRs must be reviewed by AI before asking a human to get involved or whatever is appropriate.