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?
It shouldn’t be up to another engineer to fix their PRs. They wrote the code, they are responsible for making sure it is in a state to merge. If it’s not, request changes and move on to your work.
Soooo much. It’s the biggest of red flags to have to fix other’s reviews.
Maybe take it up with managment. Those kind of profile are a hinder for every other devs that are working with them
breaks tests
leaves me to fix them during approval
I’m sorry, what? If he broke it, he fixes it. There should be guard rails that prevent him from merging his code until all the tests pass, and you as a reviewer should refuse to even start a code review unless the build is green.
Im quite happy to help fix the tests with someone that is willing. This kinda guy, not so much
Yup. Nothing wrong with pushing up a draft PR and asking for feedback; but definitely need to be an active participant in fixing the issues, not just expect somebody else to do your work for you.
That does lead to some sticky inter-personal situations though. Like there’s people on my team that I trust enough to just rubber-stamp a PR that looks good but doesn’t have test coverage etc. Can generally trust those people will let me know if the failing tests uncover some substantial work that needs to be re-reviewed.
There’s other people I don’t trust and will insist their build passes before I review it. Once that person notices they’re being held to a different standard, it can be difficult (but necessary) to have a conversation about what they need to change in order to earn that trust.
Exactly, don’t even strat looking at a PR that doesn’t pass the CI pipeline
I’d start rejecting his PRs lol, why is anyone but the original developer fixing his PRs?
Doesn’t sound like a senior dev to me. Sounds like someone who thinks they are.
Yes, well, seniority tends to be defined quite differently by management – compared to how other devs would define it. A senior to them is a person with a certain experience (at least 3-5 years), who has worked on at least a couple of complex projects (no telling exactly what they did there), shows a “can do” attitude, has good feedback from teammates, and last but not least delivers stuff on time.
Notice how quality of code doesn’t come into it at any point.
Management doesn’t know which code is “quality”, it’s all voodoo to them anyway. A pleasant team member who sounds like they know what they’re doing and delivers working stuff is all they need to see.
Quality of code needs to be defined and enforced on a project-by-project basis (definition of ready, definition of done). If they aren’t defined and/or enforced, but delivery still happens on time, it will be hard for a junior to demonstrate a problem. Some experienced managers will recognize it as a problem in the making by accumulating technical debt, some won’t (or don’t care).
I would suggest that OP explains the technical debt in impartial terms during sprint review and wash their hands of it. Confronting the other dev directly usually doesn’t work well, especially if it’s done remotely.
He causes tests to fail and leaves you to fix them?This sounds insane to me. No one should have to fix another engineers problems no matter their level.
Yeah that’s a major flag for me. If it’s just helping that’s one thing but they’re the senior dev so I’m not sure they should even need the help.
Yes, it’s common. No, it shouldn’t be tolerated. Your boss/tech lead/whatever should be involved. Here is what should be done ideally:
- not following best practices: you MUST implement merge requests (GitLab, GitHub, etc.) and his code shouldn’t be approved which means that his code won’t ever be merged in a shitty state. Force 1 or 2 approvals for each MR, and it should not be possible to merge an MR if it has open comments. The boss should ask every day “why is your code not merged yet?” and he’ll have to explain why people don’t approve his shitty code.
- shitty unit-tests: same thing, the boss should show him how to do this, and the MR shouldn’t be approved.
- breaking unit-tests: it’s the job of the CI to literally block MRs that break unit-tests (whether it’s code coverage or unit-tests).
- leaves me to fix it during PR approval: NO, it’s HIS merge request, not yours.
To sum it up: devs must not approve his MRs, the CI must block MRs that break tests.
I don’t understand why you’d be fixing unit tests he broke during his pr. It seems like he might be bullying you? Maybe discuss with your manager.
Unless it was directly caused by some code he wrote earlier that wasn’t caught at the time, he shouldn’t even consider that
even if it is an earlier, yet undeteced bug, whoever found it (in this case, the cowboy), should at least log it, if not open a separate PR to fix it.
My opinion: don’t sweat it, either way. I know that’s easy to say from the outside, but it’s still true. Do what you are most comfortable with. It sounds like you have plenty of ammunition if you want to put your foot down & insist on quality practices. Reject PRs that don’t meet best practices, and point to the internal docs you have. If the dev reacts angrily, blame the company & say you are worried about getting in trouble.
Or if confrontation makes you more uncomfortable, just let it slide. If the shit hits the fan, the senior dev is the senior dev. Just say you were following their lead.
Above all, remember that the company you are working for is not your friend and not your ally. Look out for your own interests first & don’t stress about work as much as possible (I get that’s easy to say and tough to do, but it’s still the best idea!)
Very common.
Don’t feel pressured to approve anything you don’t want to, but still be chill. It’s just work after all. (This duality takes years to figure out, but if you can, you’ll be very valuable)
Get the PM involved. Bring it up in retro and stand up.
Examples.
“I don’t feel this is PR is up to our company standards. Here’s a link to the document. Specifically tests are breaking, coverage is reduced, and your using global variables. If you need help with quality we can code pair next sprint or if I finish my tasks early. Let me know”
“Just a reminder that we have 3 PRs with needs work sitting in the queue. If you’re not able to finish them before the end of the sprint, let the scrum master/PM know in case it’s a high priority”
“We’ve all signed off on a standards guideline, and lots of PRs are falling short. Either we need more training time each sprint to reach it, or were going to have to officially reduce our standards. Let me know which one the CTO prefers”
It’s easy to become a 10x developer when you skip 90% of chores and let other devs doing them for you. If you keep enabling them, they’ll become 100x developer soon enough.
