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?
I’d go for 1 on 1 discussion first. Understand their view. I assume you already tried.
Next level is a team discussion and understanding the team view. If you have sprints I assume you also have Retrospective. That’s what it is for.
It’s also not only for objective criteria and weighing cost and benefit, risk and effort reduction. It’s also about you feeling comfortable with what you approve and ship. Even if not on a general level, at least in the project context with risks laid out and accepted.
Do you have a lead? Where I work senior indicates expertise through experience, with some decision making and guidance expertise. But lead would decide on direction or what is acceptable if it’s not obvious or decidable on a collaborative team level.
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.
Last point is SO painful… I have a coworker that writes so much shitty code OR it straight up doesn’t work… he once submitted a PR that didn’t work when used! Like, I just started the thing and it was utterly broken - both the implementation and the design.
More so, some of his PRs are a giant nightmare of over engineered crap that he, at some point, doesn’t even understand.
Worst of all, he gets angry at me for pointing out that either they don’t work or they are a shitty, complex, mess
Honestly, at some point I started approving his PR and calling it a day; oh we don’t have tests cause reasons, I tried to use TS too but since my boss finds it too complicated we are not using it again for new projects… funny
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”
I would say it’s how most softwares are done. And no, it’s not a good thing, and you should do what you can to improve things.
My boss and his boss told me that it is impossible to keep documentation up to date and too expensive, which is why we don’t have any. Let’s say I’m not the most engaged worker there now.
Why are you fixing his PR’s? Reject them for now following your own practices and link to the documentation about those practices that the PR violates.
You’re not holding up the sprint doing this, he is. As a team, you agreed these practices and everyone needs to follow them. If he refuses, raise it with his line manager.
Either his Line manager will put him in line, or he’ll agree that the standards you decided upon don’t need to be followed. Take your pick.
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!)
There are no complete, general statements that can be made about testing in all cases. How much converge and distribution of unit vs integration or white box vs black box, can not be generalized to all cases. The same is true of code practices.
However, policy can be black and white. And if the policy is to test or code with a specific style, then you need only point to that guidance and reject the patch. No confrontation or negativity needed. “This doesn’t currently meet policy x. Please fix and notify.” A respectable senior will appreciate that, and if they don’t they aren’t.
This stuck out to me too. Why are you fixing things on their PR? If their changes broke the tests then they need to make the changes to fix them before merging
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
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.
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.
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.
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.
Others have given excellent advices. I’ll approach it from management point of view:
If there’s management oversight, such as tech lead/engineering manager, talk to them. Don’t make any accusation. Approach it from the direction of you feeling uncomfortable with how the team is working. They will know how to solve the issue. However, any tech lead/engineering manager should have already dectected the problem and at a minimum acknowledge the issue.
If there’s no tech management oversight, I’d suggest you approach the senior engineer directly. I’d want to emphasize here that it has to be tech management. Non tech management won’t understand the problem and they won’t be able to solve the problem. Sometimes the senior engineer maybe under pressure to deliver and there’s nobody to split the tasks to other team members. I did this a few times in my career before I developed my skill to lead a team.
If it’s neither because the senior is under pressure to deliver, nor there’s management oversight, your next best bet is to seek consultantion with another senior, either in your team or another team. They maybe able help to talk to the senior.
Your last resort would be non tech management, or saying it another way: express that you’re not happy with your job. This won’t be much help unless others in your team doing so as well.
If all these fail, consider finding another offer. There’s no oversight, there’s no willing to inprove from the senior and there’s no chance to improve the situation from other seniors, you won’t learn much there.
I had this happen with a mid level guy (who thought he was a senior) with a cowboy attitude towards code. After many attempts to reason with him, I revoked his permission to touch the main branch and stopped reviewing his code until he started behaving. He left soon after.
In your case with a senior I’d escalate the situation to management.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@programming.dev
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
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
I’d go for 1 on 1 discussion first. Understand their view. I assume you already tried.
Next level is a team discussion and understanding the team view. If you have sprints I assume you also have Retrospective. That’s what it is for.
It’s also not only for objective criteria and weighing cost and benefit, risk and effort reduction. It’s also about you feeling comfortable with what you approve and ship. Even if not on a general level, at least in the project context with risks laid out and accepted.
Do you have a lead? Where I work senior indicates expertise through experience, with some decision making and guidance expertise. But lead would decide on direction or what is acceptable if it’s not obvious or decidable on a collaborative team level.
He is either over-worked and doesn’t have time to abide by team standards, or lazy. If lazy, reject the PR for failing to meet standards.
If over-worked, he needs to talk to his manager or whoever the work is coming from and tell them they need to slow it down
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:
To sum it up: devs must not approve his MRs, the CI must block MRs that break tests.
Last point is SO painful… I have a coworker that writes so much shitty code OR it straight up doesn’t work… he once submitted a PR that didn’t work when used! Like, I just started the thing and it was utterly broken - both the implementation and the design.
More so, some of his PRs are a giant nightmare of over engineered crap that he, at some point, doesn’t even understand.
Worst of all, he gets angry at me for pointing out that either they don’t work or they are a shitty, complex, mess
Honestly, at some point I started approving his PR and calling it a day; oh we don’t have tests cause reasons, I tried to use TS too but since my boss finds it too complicated we are not using it again for new projects… funny
This thread makes me so grateful for working with competent people.
just yesterday I had to drop a lot of his commits cause they broke some core functionality lol
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”
I would say it’s how most softwares are done. And no, it’s not a good thing, and you should do what you can to improve things.
My boss and his boss told me that it is impossible to keep documentation up to date and too expensive, which is why we don’t have any. Let’s say I’m not the most engaged worker there now.
I’d start rejecting his PRs lol, why is anyone but the original developer fixing his PRs?
I agree - if the reviewer doesn’t have the power to reject prs then they aren’t very useful reviews imo.
Right like, if we’re just doing PR reviews to do them ok but don’t I have anything better to do?
Why are you fixing his PR’s? Reject them for now following your own practices and link to the documentation about those practices that the PR violates.
You’re not holding up the sprint doing this, he is. As a team, you agreed these practices and everyone needs to follow them. If he refuses, raise it with his line manager.
Either his Line manager will put him in line, or he’ll agree that the standards you decided upon don’t need to be followed. Take your pick.
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!)
There are no complete, general statements that can be made about testing in all cases. How much converge and distribution of unit vs integration or white box vs black box, can not be generalized to all cases. The same is true of code practices.
However, policy can be black and white. And if the policy is to test or code with a specific style, then you need only point to that guidance and reject the patch. No confrontation or negativity needed. “This doesn’t currently meet policy x. Please fix and notify.” A respectable senior will appreciate that, and if they don’t they aren’t.
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.
This stuck out to me too. Why are you fixing things on their PR? If their changes broke the tests then they need to make the changes to fix them before merging
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
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.
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.
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.
Exactly, don’t even strat looking at a PR that doesn’t pass the CI pipeline
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.
80% of programming is maintaining existing code. His fragile code will be a problem in the future. This is not good .
Others have given excellent advices. I’ll approach it from management point of view:
If there’s management oversight, such as tech lead/engineering manager, talk to them. Don’t make any accusation. Approach it from the direction of you feeling uncomfortable with how the team is working. They will know how to solve the issue. However, any tech lead/engineering manager should have already dectected the problem and at a minimum acknowledge the issue.
If there’s no tech management oversight, I’d suggest you approach the senior engineer directly. I’d want to emphasize here that it has to be tech management. Non tech management won’t understand the problem and they won’t be able to solve the problem. Sometimes the senior engineer maybe under pressure to deliver and there’s nobody to split the tasks to other team members. I did this a few times in my career before I developed my skill to lead a team.
If it’s neither because the senior is under pressure to deliver, nor there’s management oversight, your next best bet is to seek consultantion with another senior, either in your team or another team. They maybe able help to talk to the senior.
Your last resort would be non tech management, or saying it another way: express that you’re not happy with your job. This won’t be much help unless others in your team doing so as well.
If all these fail, consider finding another offer. There’s no oversight, there’s no willing to inprove from the senior and there’s no chance to improve the situation from other seniors, you won’t learn much there.
I had this happen with a mid level guy (who thought he was a senior) with a cowboy attitude towards code. After many attempts to reason with him, I revoked his permission to touch the main branch and stopped reviewing his code until he started behaving. He left soon after.
In your case with a senior I’d escalate the situation to management.