Ask HN: How to work with people who push back forcefully?
94 comments
“Never wrestle with a pig because you'll both get dirty and the pig likes it" - the source of disagreement here is about whether or not policy needs to be followed, not about the details of the policy, so stop trying to argue the policy on it's merits. You need to do a quick review of roles and authorities, clearly lay out (ideally mutually agreed upon) standards, and identify the implications of not following the policies - i.e 'if not xyz as agreed, then the PR won't be approved' or 'if sarcastic/bad attitudes in meetings, then I'll work with [the people manager] and create a PIP'.
Empathy is super effective in this situation - use the magic words 'it seems___' and get their reaction. 'It seems like you're trying to get as much code done as possible and see these policies as busy work'. 'it seems like you don't think the quality of the team's output is how you'll be measured'. Sometimes there is legitimate misunderstandings (were they told they need to write x lines this year to be promoted?), other times they're missing an implication and need a reality check.
Empathy is super effective in this situation - use the magic words 'it seems___' and get their reaction. 'It seems like you're trying to get as much code done as possible and see these policies as busy work'. 'it seems like you don't think the quality of the team's output is how you'll be measured'. Sometimes there is legitimate misunderstandings (were they told they need to write x lines this year to be promoted?), other times they're missing an implication and need a reality check.
This is great, to add to "it seems" is also the "It feels". So for OP it's something like:
It feel like you think this policy doesn't apply here. It does and we're looking for Teamwork. These policies are for the Team, skipping them disrespect everyone (not just OP)
Then PIP and boot of you have to. The bad attitude spread and bring everyone down.
It feel like you think this policy doesn't apply here. It does and we're looking for Teamwork. These policies are for the Team, skipping them disrespect everyone (not just OP)
Then PIP and boot of you have to. The bad attitude spread and bring everyone down.
IMO this person needs to come to Jesus or be fired.
> I'm the tech lead but not manager
You need to have a conversation with the manager. Document the violations of standards and company policy. The manager should review this with the problem employee, in writing, and the employee should sign an acknowledgement that the warning was received and understood.
If the employee does not improve he or she should be terminated. Such people are like cancers if they are allowed to remain unchanged.
Ideally the "large, famous" software company already has defined an HR process for managing situations like this.
If you can't get backing from the manager or the manager's manager then you need to think about whether you want to stay in a company that isn't giving you the support you need to be "responsible for the technical execution of the team and the success or failure on that level."
> I'm the tech lead but not manager
You need to have a conversation with the manager. Document the violations of standards and company policy. The manager should review this with the problem employee, in writing, and the employee should sign an acknowledgement that the warning was received and understood.
If the employee does not improve he or she should be terminated. Such people are like cancers if they are allowed to remain unchanged.
Ideally the "large, famous" software company already has defined an HR process for managing situations like this.
If you can't get backing from the manager or the manager's manager then you need to think about whether you want to stay in a company that isn't giving you the support you need to be "responsible for the technical execution of the team and the success or failure on that level."
I will add to this that the OP should seek out or ask their manager to find a principal/staff level engineer that can take on the individual effort of helping the renegade engineer fall in line. That may be more in line with their responsibilities than a team lead.
Aren't lead and staff basically the same thing at a lot of places?
Not at all, at least at FAANGs I was lucky enough to observe from the inside myself.
Team lead there is essentially a middle ground between the engineering manager and IC devs. Sometimes teams do with just ICs+manager, sometimes it has that TL layer in-between (usually on larger teams, either in the number of people or the scope of work). TLs can be either senior or staff engineers (only seen seniors as TLs though). Both senior and staff engineers can be either ICs or TLs.
Often, I see TL positions being either just a stop-gap for transitioning to being an engineering manager or as a lite test-drive of whether the person would actually like being in a management position (as opposed to an IC).
Team lead there is essentially a middle ground between the engineering manager and IC devs. Sometimes teams do with just ICs+manager, sometimes it has that TL layer in-between (usually on larger teams, either in the number of people or the scope of work). TLs can be either senior or staff engineers (only seen seniors as TLs though). Both senior and staff engineers can be either ICs or TLs.
Often, I see TL positions being either just a stop-gap for transitioning to being an engineering manager or as a lite test-drive of whether the person would actually like being in a management position (as opposed to an IC).
This is the correct answer. CtJ or hit the bricks.
> The person said things like "how would anyone find out", "what does it matter", "everyone does it"
To me, this reads as a toxic person who would try to get away with these things if they hadn't been caught, and who could lead to a massive shift in ethics and morale if allowed to proceed unchecked. That's really alarming. Imagine if a person with this attitude was in a position where they were responsible for code safeguarding PII or other sensitive data (and arguably, this may already be true, e.g. if they were to introduce a security hole in their component). It's essential that you document everything contemporaneously (or as close to that as possible), ensure the person's manager first knows your concerns in private - and if they don't take any action, give them the heads up that you'll need to escalate to your manager about potential ongoing legal risks. It will be annoying to navigate the politics, but it will be much more annoying if the wound festers.
Frankly, there's a lot of talent out there right now with great ethical compasses and experience with large codebases, and allocating headcount to a toxic person simply isn't optimal in that context. And even if you're in a situation where a dismissed team member won't be replaced e.g. due to hiring freezes... this person may very well be having a negative effect on the team. Just first make sure that they're not someone's kid... and good luck!
To me, this reads as a toxic person who would try to get away with these things if they hadn't been caught, and who could lead to a massive shift in ethics and morale if allowed to proceed unchecked. That's really alarming. Imagine if a person with this attitude was in a position where they were responsible for code safeguarding PII or other sensitive data (and arguably, this may already be true, e.g. if they were to introduce a security hole in their component). It's essential that you document everything contemporaneously (or as close to that as possible), ensure the person's manager first knows your concerns in private - and if they don't take any action, give them the heads up that you'll need to escalate to your manager about potential ongoing legal risks. It will be annoying to navigate the politics, but it will be much more annoying if the wound festers.
Frankly, there's a lot of talent out there right now with great ethical compasses and experience with large codebases, and allocating headcount to a toxic person simply isn't optimal in that context. And even if you're in a situation where a dismissed team member won't be replaced e.g. due to hiring freezes... this person may very well be having a negative effect on the team. Just first make sure that they're not someone's kid... and good luck!
First two of these examples may be on the religious or yak shaving end of debates, where the best practice is probably not an absolute.
1. There are code bases and PRs where coalescing many small changes into one "this changes how we do this" commit is encouraged when it's a semvar level change requiring coordinated edits to keep working, rather than a purely iterative change.
2. Most research shows universal unit test coverage is lower ROI than judicious coverage of intefaces and risks.
If many of your discussions fall in this zone, it's possible you, yourself, may be taking guidelines as too black and white.
Meanwhile ...
3. That one is just bad.
1. There are code bases and PRs where coalescing many small changes into one "this changes how we do this" commit is encouraged when it's a semvar level change requiring coordinated edits to keep working, rather than a purely iterative change.
2. Most research shows universal unit test coverage is lower ROI than judicious coverage of intefaces and risks.
If many of your discussions fall in this zone, it's possible you, yourself, may be taking guidelines as too black and white.
Meanwhile ...
3. That one is just bad.
> If many of your discussions fall in this zone, it's possible you, yourself, may be taking guidelines as too black and white.
I have very mixed feelings about this. On the one hand, I’m no fan of following process for the sake of it.
On the other, the way to address policies that need an update is to sit down with the lead/manager and propose changes with evidence as to why.
Deciding to just do things your way and then arguing about it is not the way.
I have very mixed feelings about this. On the one hand, I’m no fan of following process for the sake of it.
On the other, the way to address policies that need an update is to sit down with the lead/manager and propose changes with evidence as to why.
Deciding to just do things your way and then arguing about it is not the way.
If you can automate the rules, do it. If you can’t automate the rules, don’t try to enforce them, just ask why.
I worked at a place where 10k LoC PRs were the norm. At my next place, I’d open a 1k PR and people would lose their shit. They’d ask for it to be broken up into smaller PRs and my response was “it’s already ridiculously small”
Personally, I’d rather see the big PR and spend time reviewing that than trying to figure out what they’re trying to set up and do. As long as the big PR is coherent and well-written. If it’s spaghetti monster, I’ll pass.
I worked at a place where 10k LoC PRs were the norm. At my next place, I’d open a 1k PR and people would lose their shit. They’d ask for it to be broken up into smaller PRs and my response was “it’s already ridiculously small”
Personally, I’d rather see the big PR and spend time reviewing that than trying to figure out what they’re trying to set up and do. As long as the big PR is coherent and well-written. If it’s spaghetti monster, I’ll pass.
I mostly agree due to the nature of not all code is straight up assembly/c/cpp, LOL. Knowing your target audience is key. In this case the team size, company size, ect.
I would be okay with larger PRs especially for configuration as code like ansible and terraform hcl. Hoping that people actually use comments and keep code chunks in relevant sections (I've begun paraphrasing ansible to use more whitespace between different "sections". This of course becomes more acceptable when one playbook or hcl folder is copied to another area for promotion purposes, but of course using tooling to check for diffs is crucial here.
I would be okay with larger PRs especially for configuration as code like ansible and terraform hcl. Hoping that people actually use comments and keep code chunks in relevant sections (I've begun paraphrasing ansible to use more whitespace between different "sections". This of course becomes more acceptable when one playbook or hcl folder is copied to another area for promotion purposes, but of course using tooling to check for diffs is crucial here.
IME it’s pretty much impossible to change rules adopted by a bureaucracy if you are just a cog.
Do you have source on item #2? I've been looking for some to back this point, but can't find any.
I would honestly find #3 a tough pill to swallow as well, and where do you draw the line? If I copy a line of `arr.map()` and use my own variable names does that count? Direct copying from SO can be bad generally but also adding all the license hoop jumping overhead just seems annoying.
The first two are fine though as long as there is room for interpretation, but if the person is pushing back every single time that’s just obnoxious.
The first two are fine though as long as there is room for interpretation, but if the person is pushing back every single time that’s just obnoxious.
The "license hoop jumping overhead" is a legal requirement. If it ever comes out that your software contains code copied from some random web site, you're asking for a copyright infringement lawsuit. If you stick GPLed code in your code base, then your entire codebase is GPL and you're required to give away the source code on request. Even if something is MIT or BSD or similar license, you probably need to give the author credit in your software (this is why so many games have an "Open Source Licenses" option where you can read the licenses of various open source libraries they stuck in the game). If you forget to credit the author of the MIT licensed library you used, that's also a potential lawsuit.
In short, don't play loose with software licenses. The legal system has about as much interest in debating whether a company has to follow intellectual property laws as the tax collection agency does in debating whether you have to follow tax laws.
In short, don't play loose with software licenses. The legal system has about as much interest in debating whether a company has to follow intellectual property laws as the tax collection agency does in debating whether you have to follow tax laws.
Yes I do understand the legal requirement for these kind of things, I was more trying to be understanding of why there was push back from the person the OP is describing. I also think anyone would be hard pressed to find an engineer who has _never_ copied anything from SO without attribution.
Plenty of us coded before SO, but I think you're being too general. Using SO to see examples of syntax is completely different than copying a chunk/function/page of original code someone wrote to solve a problem.
I absolutely have never put stack overflow code into a prodiction code base and I dont think Ive heard anyone talking about or seen anyone do that. I dont think that is typical all.
I use stack overflow to understand a concept or a technique frequently, but always type my own code from scratch.
I use stack overflow to understand a concept or a technique frequently, but always type my own code from scratch.
What I don't hear is what you've done to understand their p.o.v. Some questions that you should have clarity on:
1. Why are they pushing back on it? Have you asked them what they consider up to standard? If they don't have high enough code standards and think it's OK to push crap, then there is a clear expectation gap that you should identify to them and tell them they are not meeting the bar.
2. Did they have any say in these standards? Sometimes you can turn an enemy into an asset simply by having them own a piece of the standard (and holding them accountable if that standard doesn't hold up)
3. What do they suggest in lieu? Maybe it's a stylistic thing, maybe it's a quality thing. Maybe they don't understand the difference, or maybe their impostor syndrome is making them defensive.
My summary is that you need to ask probing questions to fully understand their perspective. THis is difficult because they sound defensive, which is reasonable - your approach sounds a little like an attack due to your frustration. I can assure you they are frustrated as well!
Finally, keep in mind to set up the right context. When the light is red, stop pushing. Find a way to have an open and constructive dialog - you will have to bear that responsibility, but once you can find that, you will probably have better luck.
And document each of these steps, in email, to the person. Then when you go to leadership, you can share what you've done. If they ultimately just don't meet the bar or expectations, they should be let go.
1. Why are they pushing back on it? Have you asked them what they consider up to standard? If they don't have high enough code standards and think it's OK to push crap, then there is a clear expectation gap that you should identify to them and tell them they are not meeting the bar.
2. Did they have any say in these standards? Sometimes you can turn an enemy into an asset simply by having them own a piece of the standard (and holding them accountable if that standard doesn't hold up)
3. What do they suggest in lieu? Maybe it's a stylistic thing, maybe it's a quality thing. Maybe they don't understand the difference, or maybe their impostor syndrome is making them defensive.
My summary is that you need to ask probing questions to fully understand their perspective. THis is difficult because they sound defensive, which is reasonable - your approach sounds a little like an attack due to your frustration. I can assure you they are frustrated as well!
Finally, keep in mind to set up the right context. When the light is red, stop pushing. Find a way to have an open and constructive dialog - you will have to bear that responsibility, but once you can find that, you will probably have better luck.
And document each of these steps, in email, to the person. Then when you go to leadership, you can share what you've done. If they ultimately just don't meet the bar or expectations, they should be let go.
Hard to say without more info about the relationships and company structure. It looks like this person is pushing back on your judgement with their own judgement. If you can't fall back to finding a mutual understanding then you're at battling for power. If you have the seniority you can just say "No, this is the standard that the team agreed on and we enforce, your PR is not being approved until it is fixed", and if you don't then I think you need to involve someone who is one level above you to resolve the judgement dispute.
If you're not willing or able to clash, you'll have to try find some compromises that improve the situation but make for an undesirable choice for this person. eg. In the PR example, require that large PRs require an in-person walk through.
If you're not willing or able to clash, you'll have to try find some compromises that improve the situation but make for an undesirable choice for this person. eg. In the PR example, require that large PRs require an in-person walk through.
Bluntly, I’m not sure why this a conversation. I’m all for productive disagreements (even on small things!), but there’s not a substantive point being argued here.
Try being more blunt & concise. Instead of explaining, just say “please add unit tests and I’ll approve,” and then disengage. They’re the one who needs their PR approved - not your problem.
The key here is escalation path. He’ll have to bring it up to his manager, and then the conversation is with his manager, and then you can have a broader “he can’t just ignore every standard” conversation.
Try being more blunt & concise. Instead of explaining, just say “please add unit tests and I’ll approve,” and then disengage. They’re the one who needs their PR approved - not your problem.
The key here is escalation path. He’ll have to bring it up to his manager, and then the conversation is with his manager, and then you can have a broader “he can’t just ignore every standard” conversation.
> and then disengage
Seriously, you don't owe anyone your time to have a pointless debate. Boundaries are important, as is not wasting your own time. You explain the rules, you're done, conversation over.
Seriously, you don't owe anyone your time to have a pointless debate. Boundaries are important, as is not wasting your own time. You explain the rules, you're done, conversation over.
The only thing will accomplish is demoralizing your team and having then turn in the bare minimum workong code. You clearly don't care about what your team thinks, so why should they care about going above and beyond when writing their code?
'I didnt ask you to do it, I'm telling you to do it. Are you going to do what I am telling you to do? I will take any answer other than an explicit confirmation as a 'no'.'
Do you find this type of answer to actually help you accomplish your and your organizations goals? I don’t think many people would react well to that type of military style order frankly.
IMO of the three examples only the last one is a clear case of a company policy that can and should be followed even at the expense of productivity, and if their argument is really "how would anyone find out" you need to kick that up the management chain--this person could be putting your company at risk. For the other two your rationale is essentially "doing it the standard way makes the team more productive", but clearly comes at the cost of making this employee less productive, and your argument is empty--they are already seeking to be as productive as they think they can be. Assuming this person on net is more productive than average just assign someone else to backfill their unit tests and learn to live with the overly complex PRs.
In the past I've been told to hire specifically for the personality trait of being willing to push back hard. Though stubborn people might be difficult sometimes, I really appreciate their presence when requirements are unclear or unrealistic.
With that said, code quality, F/OSS license policies, and testing should be something the whole team talks about and comes to an agreement on. There's a big difference between pushing back and failing to meet the team's basic standards, and at a certain point it becomes a performance issue.
With that said, code quality, F/OSS license policies, and testing should be something the whole team talks about and comes to an agreement on. There's a big difference between pushing back and failing to meet the team's basic standards, and at a certain point it becomes a performance issue.
There’s a difference between stupid stubborn and technically competent stubborn. I’ve worked with people who are very smart and absolutely can’t suffer a fool (or some arbitrary rule). They can be annoying to work with because they push against the status quo and sometimes you just want to get the review done and move on. But they are fundamentally right and often times push back hard enough to where things actually change for the better. I don’t mind this too much and sometimes I wish I was more like that. Sure, they could have applied some social grease to make things roll more smoothly , but whatever, people are people.
Then there’s stupid stubborn where it’s just laziness or lack of capacity, or something else. This guy sounds more like that.
Then there’s stupid stubborn where it’s just laziness or lack of capacity, or something else. This guy sounds more like that.
I think it's good to have at least 1 person in the team like this. Sometimes a higher up makes a mistake and suggests a terrible idea. If the team is all yes men (or women), then that bad idea is implemented and in the end, causes a lot of pain down the line. The worst part seeing that look in your teammates faces. They KNOW it's a bad idea, yet no one says a word.
Upvote
After seeing great folks laid off from FANG, i would also question if you should care so much about these things. IMO, us SWEs tend to care so much about writing idiomatic code for corporate overlords when in reality the effects of mildly sloppy code won’t be realized for a decade, it’s okay to leave it to the next poor soul that has to deal with it 10yrs down the lane and just enjoy your weekend :-)
Unless you switch jobs every <2 years, the next poor soul is most likely yourself. 10 years down the lane? You'd be shooting yourself in the foot by writing bad code if 6 months later you have to troubleshoot a bug related to the spaghetti you created yourself.
Plenty of bad advise here.
It sounds like you already made up your mind about this person and came here to enforce your confirmation bias.
Since I've been on both sides of this story, I'm going to be the devil's advocate.
> I try as much as possible to explain _why_ practices are what they are, the effects on our project, the team, etc. Any suggestions for these conversations in the future?
How about showing the hard evidence that those practices are beneficial and a net positive? Let me guess, you don't have that. If you had, there wouldn't be a debate. My bet is you don't even have metrics to look at in the future that will prove your practices are beneficial.
> Sending a large PR that changes many files at once because their changes kept growing in scope as they were trying to figure out how to do something
Is this a one-off you're looking to attack them on, or a consistent behavior? Based on the description I suspect it's a one off. If it's consistent, it is pretty bad. Since it looks like you're already got off the wrong foot, you'll need other team members to advocate for smaller PR.
> The benefits of unit tests are so fundamental
Ah, the cargo-culting. The benefits of testing are fundamental. But testing is hard. Unit testing is a way for lousy engineers to pretend to do testing.
https://kentcdodds.com/blog/write-tests
> On Friday, I discovered a chunk of code copied from Stackoverflow ... The person said things like "how would anyone find out"
Was it a 2-line or 100-line snippet? Context matters.
The person you're describing might indeed be a toxic asshole you want them to be. But it is also quite possible that you are the asshole here, mischaracterizing them to confirm your bias.
It sounds like you already made up your mind about this person and came here to enforce your confirmation bias.
Since I've been on both sides of this story, I'm going to be the devil's advocate.
> I try as much as possible to explain _why_ practices are what they are, the effects on our project, the team, etc. Any suggestions for these conversations in the future?
How about showing the hard evidence that those practices are beneficial and a net positive? Let me guess, you don't have that. If you had, there wouldn't be a debate. My bet is you don't even have metrics to look at in the future that will prove your practices are beneficial.
> Sending a large PR that changes many files at once because their changes kept growing in scope as they were trying to figure out how to do something
Is this a one-off you're looking to attack them on, or a consistent behavior? Based on the description I suspect it's a one off. If it's consistent, it is pretty bad. Since it looks like you're already got off the wrong foot, you'll need other team members to advocate for smaller PR.
> The benefits of unit tests are so fundamental
Ah, the cargo-culting. The benefits of testing are fundamental. But testing is hard. Unit testing is a way for lousy engineers to pretend to do testing.
https://kentcdodds.com/blog/write-tests
> On Friday, I discovered a chunk of code copied from Stackoverflow ... The person said things like "how would anyone find out"
Was it a 2-line or 100-line snippet? Context matters.
The person you're describing might indeed be a toxic asshole you want them to be. But it is also quite possible that you are the asshole here, mischaracterizing them to confirm your bias.
Pretty much this. Context matters so much. Even at a higher-level, imagine this at a FAANG vs. startup finding product market fit. The situations are completely different.
The answer is: there are rules adopted by the team, and the only accepted way to change them if they are not optimal from the point of person described in the post is by challenging the rules explicitly, not by trying to violate them.
You describe your workplace as academically-inspired, yet experimentation and large PRs are discouraged. In you shoes, I'd double-check to make sure the "small-PRs-only" policy is in alignment with the company values before making that a real point of contention.
The small PRs thing literally came out of things like "The Principles of Product Development Flow", which talks extensively about Queuing Theory, as well as the findings from Accelerate which came out of academic research. So... I can very much see how it would be aligned?
> "What does it matter?", "It's already done.", "It would take too much time to break up.", "I'll do that next time", etc.
These mainly seem like lame excuses that are being used to shut the discussion down. You don't need to let that succeed, you can potentially engage politely but firmly.
"What does it matter?" => It matters because its easier to review, revert, reason about in the history, it's our convention that was discussed/communicated earlier...
"It's already done." => No, it's not, it is a PR pending review and feedback. This is my feedback. If you would like feedback from the group earlier in your development process, feel free to approach any one of us for input as you are making your changes, there is no need to wait until you feel that your change is "done".
"It would take too much time to break up." => How much time do you feel it would take to break this up? Are you familiar with the git operations to perform this task? Would you like me to help, or break it up for you? Realistically, it should probably only take a few minutes to perform this task for someone proficient with their tools.
"I'll do that next time" => Since you understand the rationale and benefit, why wait until next time, let's do it this time?
"Well it's so simple. It's not worth testing." => Great, since it is so simple, it should only take a few minutes to write the test.
"I'll add a test later" => Ok, when in particular were you thinking you would like to do this? Add a ticket for that, with a due date, so it doesn't get forgotten? Perhaps it's easier to just do it now, what do you think?
These mainly seem like lame excuses that are being used to shut the discussion down. You don't need to let that succeed, you can potentially engage politely but firmly.
"What does it matter?" => It matters because its easier to review, revert, reason about in the history, it's our convention that was discussed/communicated earlier...
"It's already done." => No, it's not, it is a PR pending review and feedback. This is my feedback. If you would like feedback from the group earlier in your development process, feel free to approach any one of us for input as you are making your changes, there is no need to wait until you feel that your change is "done".
"It would take too much time to break up." => How much time do you feel it would take to break this up? Are you familiar with the git operations to perform this task? Would you like me to help, or break it up for you? Realistically, it should probably only take a few minutes to perform this task for someone proficient with their tools.
"I'll do that next time" => Since you understand the rationale and benefit, why wait until next time, let's do it this time?
"Well it's so simple. It's not worth testing." => Great, since it is so simple, it should only take a few minutes to write the test.
"I'll add a test later" => Ok, when in particular were you thinking you would like to do this? Add a ticket for that, with a due date, so it doesn't get forgotten? Perhaps it's easier to just do it now, what do you think?
> Some examples: - Sending a large PR that changes many files at once because their changes kept growing in scope as they were trying to figure out how to do something.
I'm the most senior developer in my team. Normally I block the PR with a change request and say exactly what I want, i.e "Please commit X and Y, in a new PR" and I give exactly the commands that this developer must run. Then, after this small PR is merged, I ask the developer to rebase the huge PR with the master, and do that until the initial PR get as small as possible. If you are not the manager or not team lead, the easiest way is to lead by example, mostly by doing together. Sometimes it can be frustrating, but I'm sure I bring those stuff up when I'm negotiating my salary raises...
I'm the most senior developer in my team. Normally I block the PR with a change request and say exactly what I want, i.e "Please commit X and Y, in a new PR" and I give exactly the commands that this developer must run. Then, after this small PR is merged, I ask the developer to rebase the huge PR with the master, and do that until the initial PR get as small as possible. If you are not the manager or not team lead, the easiest way is to lead by example, mostly by doing together. Sometimes it can be frustrating, but I'm sure I bring those stuff up when I'm negotiating my salary raises...
It can be hard.
The key is to
1) not engage in conversation
2) add mechanical tools that fail the build if coverage isn’t enough!
A lot of times people argue that it’s stupid to have a “target” code coverage. I used to be one such person until I saw what happens when you leave it to people. Most people would still keep quality bar high, but one rotten fish spoils the pond and the tools that mechanically measure quality metrics are very effective in pushing back on bullshit like this.
Oh and whatever you do, don’t engage in debate on this. They /will/ wear you down.
The key is to
1) not engage in conversation
2) add mechanical tools that fail the build if coverage isn’t enough!
A lot of times people argue that it’s stupid to have a “target” code coverage. I used to be one such person until I saw what happens when you leave it to people. Most people would still keep quality bar high, but one rotten fish spoils the pond and the tools that mechanically measure quality metrics are very effective in pushing back on bullshit like this.
Oh and whatever you do, don’t engage in debate on this. They /will/ wear you down.
> add mechanical tools that fail the build
I wish this wasn’t so damn effective.
Anecdata says that people who are too stubborn to adapt to other people’s best practices often don’t mind the practices, only the way they are conveyed.
I wish this wasn’t so damn effective.
Anecdata says that people who are too stubborn to adapt to other people’s best practices often don’t mind the practices, only the way they are conveyed.
> I'm the tech lead but not manager of my current team and I'm responsible for the technical execution of the team and the success or failure on that level.
I’ve been here.
Resorting to authoritative measures (giving commands) is the only way. If you don’t need to pull the manager in, it works better. When they simply refuse to do the task you’ve agreed to and just do something else, you go in and solve their task, and you raise a concern with the manager. But to the extent that you can have the dialogue directly and make them sound spoiled will carry more towards equipping your own authority.
Ultimately, they are measured by their ability to solve problems they’re asked to in the ways requested.
I’ve been here.
Resorting to authoritative measures (giving commands) is the only way. If you don’t need to pull the manager in, it works better. When they simply refuse to do the task you’ve agreed to and just do something else, you go in and solve their task, and you raise a concern with the manager. But to the extent that you can have the dialogue directly and make them sound spoiled will carry more towards equipping your own authority.
Ultimately, they are measured by their ability to solve problems they’re asked to in the ways requested.
The chunk of code copied from SO is a legit legal risk for the company, not a code quality issue — you need to either revert that or escalate it quickly.
The rest of it, I’d follow Galxeagle’s advice. Lay out the standards, lay out the consequences, have empathy, do not argue with them. Humane, but firm.
The rest of it, I’d follow Galxeagle’s advice. Lay out the standards, lay out the consequences, have empathy, do not argue with them. Humane, but firm.
While you are the party in the right here and others have given sound advice, some part of me is rooting for the guy.
It sounds like someone jaded, maybe well into burnout. He might not have been like that always, might be worth exploring why.
I've been in similar situations throughout my life and always overcame them, but over time it gets harder to care enough to lift yourself up without any help.
Does this person respect certain people in their environment? Why, on what basis?
It seems something makes this person tick but it hasn't been figured out what that is.
It's not about the contents of those disagreements. It's about them not being in a collaborative mode. It might be lack of creativity, lack of autonomy, lack of perceived excellence.
Just my two cents with the little info I got here.
It seems something makes this person tick but it hasn't been figured out what that is.
It's not about the contents of those disagreements. It's about them not being in a collaborative mode. It might be lack of creativity, lack of autonomy, lack of perceived excellence.
Just my two cents with the little info I got here.
This is typically the role of a manager to sort these things out. Your role is:
1. review the PRs and don't accept them if your requested changes aren't done
2. report to the manager
1. review the PRs and don't accept them if your requested changes aren't done
2. report to the manager
On the specific point of small PRs, how long does it take to get code reviews on your team? One force that pushes people towards large PRs is slow reviews.
If this is happening consistently and the person has been told consistently but still doesn't do it, then it is time for management to step in.
If they start getting their performance reviews taken down a rung or two explicitly due to not doing what was expected of them and communicated to them (repeatedly) then they might get the message. "You didn't get a pay rise this year because you didn't do what was asked if you on <occasions>, which led to extra work for the rest of the team. This was discussed several times with you on <dates>. You can improve by following the coding standards and listening to your TL when they ask you to do something multiple times. If you don't, then we may need to think about formal pip."
If they start getting their performance reviews taken down a rung or two explicitly due to not doing what was expected of them and communicated to them (repeatedly) then they might get the message. "You didn't get a pay rise this year because you didn't do what was asked if you on <occasions>, which led to extra work for the rest of the team. This was discussed several times with you on <dates>. You can improve by following the coding standards and listening to your TL when they ask you to do something multiple times. If you don't, then we may need to think about formal pip."
My advice for you is different. Kick the ball up the chain. Ask the higher ups to send a reminder on company policy or to implement mechanical tools. Do NOT put yourself in the firing line, especially in places with an "academic-inspired" workspace. You don't want to be the bad guy, you don't want to be known as that "difficult" tech lead. You are not high enough up on the food chain to safely pull rank on your team without repercussions. If there's a license violation, make sure there's a clear email chain that your higher up is aware. If they ignore the issue, then there's nothing you can do.
In many companies, policies are guidelines for management to cover their ass. E.g. "Giving gifts to political leaders in third world countries is prohibited and illegal". This is complete nonsense, every MNC above a certain size have no choice but to grease the wheels when operating in developing countries. That's just how it is. The policy is there so the lowest ranking middle manager in the chain of command can get thrown in front of the bus if for whatever reason there's regulatory scrutiny. Same thing here your situation, if you gain a reputation for being difficult, then if the projects fails for whatever reason unrelated to engineering, your colleagues would be happy to point their fingers at you. Don't be that engineer with poor social skills. No business manager appreciates a stickler for rules outside of legal and compliance departments.
In many companies, policies are guidelines for management to cover their ass. E.g. "Giving gifts to political leaders in third world countries is prohibited and illegal". This is complete nonsense, every MNC above a certain size have no choice but to grease the wheels when operating in developing countries. That's just how it is. The policy is there so the lowest ranking middle manager in the chain of command can get thrown in front of the bus if for whatever reason there's regulatory scrutiny. Same thing here your situation, if you gain a reputation for being difficult, then if the projects fails for whatever reason unrelated to engineering, your colleagues would be happy to point their fingers at you. Don't be that engineer with poor social skills. No business manager appreciates a stickler for rules outside of legal and compliance departments.
>In many companies, policies are guidelines for management to cover their ass. E.g. "Giving gifts to political leaders in third world countries is prohibited and illegal". This is complete nonsense, every MNC above a certain size have no choice but to grease the wheels when operating in developing countries.
Exactly! It is also not limited to developing countries but in developed countries as well. Just that the criminals are in suits and they use a more sophisticated lobbying instead of the cruder bribing.
I really don't understand how people are so passionate about corporates. It is "work" and they really have to pay me well to get me to do this bullshit.
Working on personal side projects gives me a creative outlet as an engineer to work on things I love without all this bullshit.
Exactly! It is also not limited to developing countries but in developed countries as well. Just that the criminals are in suits and they use a more sophisticated lobbying instead of the cruder bribing.
I really don't understand how people are so passionate about corporates. It is "work" and they really have to pay me well to get me to do this bullshit.
Working on personal side projects gives me a creative outlet as an engineer to work on things I love without all this bullshit.
Get this person off your team however you can. When the sh*t hits the fan over one of their own special exemptions (like something fails in production that should have been caught in a unit test) it will NEVER be their fault. They will point the finger at everyone else and complain about how someone else should have done something, etc. Fortunately for you, this person is probably going to leave on their own soon anyway, because they know better than everyone else how things should be done and they'll jump ship.
Short of that, manage up - tell the team manager that this person is a drag on the team by not following standards, demanding special treatment, being generally disagreeable. it hurts team morale even if the junior team members don't say so (they may not even realize it themselves, but it is a real thing).
In the shortest term, as others have said, don't engage. Pick the rules you enforce, and enforce them. Request the additional changes on the PR to meet style guidelines and don't take no for an answer. Don't get into discussions or arguments about the merits of the standards, just say "These are the standards and we're all expected to follow them." If the standards are written down (and if they're not, then they aren't really standards) then cut off any discussion on the merits of the standards with links to the written standards. Use a "chore" conventional-comment (https://conventionalcomments.org/) to indicate that it's just a thing that has to be done.
If you can, make it someone else's problem. Refer them to the standards committee or whatever senior architect is responsible for guiding the standards, and let them handle the argument.
Short of that, manage up - tell the team manager that this person is a drag on the team by not following standards, demanding special treatment, being generally disagreeable. it hurts team morale even if the junior team members don't say so (they may not even realize it themselves, but it is a real thing).
In the shortest term, as others have said, don't engage. Pick the rules you enforce, and enforce them. Request the additional changes on the PR to meet style guidelines and don't take no for an answer. Don't get into discussions or arguments about the merits of the standards, just say "These are the standards and we're all expected to follow them." If the standards are written down (and if they're not, then they aren't really standards) then cut off any discussion on the merits of the standards with links to the written standards. Use a "chore" conventional-comment (https://conventionalcomments.org/) to indicate that it's just a thing that has to be done.
If you can, make it someone else's problem. Refer them to the standards committee or whatever senior architect is responsible for guiding the standards, and let them handle the argument.
Enforcement by means of CI is a fairly simple approach for many issues. Issues should have a minimum set of requirements including suitable testing. No colleague should approve a PR unless it ticks the necessary boxes.
Our CI does a check to see if Terraform was correctly formatted prior to push and will fail before any "init" / "plan" / "apply" step is reached.
Our CI does a check to see if Terraform was correctly formatted prior to push and will fail before any "init" / "plan" / "apply" step is reached.
I'll ask because we're struggling with this now. What do you do to reduce the risk of an auto applied TF change going sideways? Our current workflow involves a manual review/approval by devOps.
Our teams all control their own infrastructure so there is very low risk of two pipelines trying to alter the same resources.
Step 1 plans, and outputs the changes to a local plan file.
Step 2 prompts for a human approval after viewing the above potential changes. Declining the approval simply ends the pipeline.
Step 3 applies step 1 using the plan file.
Step 1 plans, and outputs the changes to a local plan file.
Step 2 prompts for a human approval after viewing the above potential changes. Declining the approval simply ends the pipeline.
Step 3 applies step 1 using the plan file.
Ok, human involved in the loop, thank you!
I also think there should never be more than one source of truth for TF, but I have seen two devs fight it out in the development environment. Each add their own SNS topic with similar names, get very weirded out by how it seems to magically change as the other dev applies and deletes the first one and replaces it!
I also think there should never be more than one source of truth for TF, but I have seen two devs fight it out in the development environment. Each add their own SNS topic with similar names, get very weirded out by how it seems to magically change as the other dev applies and deletes the first one and replaces it!
Yes, the code is treated no differently from any other language. A human has to confirm changes which will impact others.
The key is to act quickly when presented with a plan. It's advised to decline stale pending approvals and kick off a new pipeline for freshness.
There's no magic unfortunately :(
The key is to act quickly when presented with a plan. It's advised to decline stale pending approvals and kick off a new pipeline for freshness.
There's no magic unfortunately :(
I've a similar issue with foreful pushback, but different circumstances. In this case it's someone who sticks blindly and rigidly to rules (often dictated by him) that are not bad persay, but can and do impact productivity. For example, designers should not write tests, that's for verification. If they do write tests they must use the (complex) verification env, not not a simpler unit test env. Compext checkin hoops to jump through, Many other items like this that make devopment beureaucratic and slows things down. It's really frustrating as I'm in architecture (previously implementation) and he's in implementation so he pushes back as 'it's his area'. He then complains we don't have enough resources, and schedules must push out. The sad fact is we did similar projects before with a team half the size, but just more efficiently, but he wont listen to that at all.
[deleted]
Generally, I view people who push back as valuable, but the caveat is they have to be correct or at least providing a valuable alternative viewpoint. If they're not, and actually just being lazy, then collect some objective documentation if necessary and get to work on firing them.
Since said person doesn't want to listen you and you don't have the direct authority over that person, I think it's reasonable to ask the team manager to deal with it.
Say something like the following. Just remember to include specific pieces of evidence that support your claim.
"Person X doesn't seem to care about company policies regarding the code quality. On following occasions: <list of offenses by person X> he/she did something sloppy that was against the policy A and refused to even acknowledge it during the review. Can you explain him/her why following these policies is important"
Say something like the following. Just remember to include specific pieces of evidence that support your claim.
"Person X doesn't seem to care about company policies regarding the code quality. On following occasions: <list of offenses by person X> he/she did something sloppy that was against the policy A and refused to even acknowledge it during the review. Can you explain him/her why following these policies is important"
figure out why, do they feel threatened or bullied? Are they headstrong? Are they trying to do something you don't get or care about? Are they actually smarter than you?
If you can adjust your behavior to compensate for what they perceive and you then want to, you can do something about it.
If you can adjust your behavior to compensate for what they perceive and you then want to, you can do something about it.
Can you just reject all their changes from being pushed to production until they meet standards?
If you are the tech lead, don't you review all his changes? Just stop letting him add anything to the production code.
Give them a warning, document the constraints and say: "I am not able to add any of your contributions to the project going forward. We will be reviewing your inputs to the code on an ongoing basis. The quality of the work is unacceptable. I am not going to be arguing with you any further. Here are the standards. Anything that doesn't follow these is going to be rejected. IF you are unable to follow these, then I recommend transferring."
Then let him take a vacation and push no code and then slap him with a PIP.
If you are the tech lead, don't you review all his changes? Just stop letting him add anything to the production code.
Give them a warning, document the constraints and say: "I am not able to add any of your contributions to the project going forward. We will be reviewing your inputs to the code on an ongoing basis. The quality of the work is unacceptable. I am not going to be arguing with you any further. Here are the standards. Anything that doesn't follow these is going to be rejected. IF you are unable to follow these, then I recommend transferring."
Then let him take a vacation and push no code and then slap him with a PIP.
Please don't take offence at this, but... really try to avoid thinking about this on the weekend, absolutely not worth it. And try to be nice to this person even if you find them annoying. As Steven Covey says, “Seek First To Understand, Then To Be Understood.” -ironically that's mentioned in a sibling HN article today. (I have to admit to failing to do that myself of course... ;) ). I'd hazard a guess they might be finding it a rather intense work environment that's stressing them out, hence, not entirely rational response when challenged about StackOverflow code. Give 'em a way to save face. Be nice :)
When I was working as a team lead, I rejected any PR that was not in line with the rules. I stopped the review immediately I saw the rule breaking line(s).
One time, a manager asked me why I rejected a PR at the end of the sprint, before the demo, and I said, as you wrote above, that it's my responsibility and if he wants to overrule me, he should do that officially by assuming responsibility and escalating to our boss.
Make sure the rules are clear and then stop trying to appease.
edit: I wanted to make it clear that the rules were broken only when a new dev joined the team, after a rejection or two, PRs were extremely rare instantly rejected.
One time, a manager asked me why I rejected a PR at the end of the sprint, before the demo, and I said, as you wrote above, that it's my responsibility and if he wants to overrule me, he should do that officially by assuming responsibility and escalating to our boss.
Make sure the rules are clear and then stop trying to appease.
edit: I wanted to make it clear that the rules were broken only when a new dev joined the team, after a rejection or two, PRs were extremely rare instantly rejected.
Tell your boss to make someone else tech lead.
These examples all say the same thing. You have outgrown that company. I bet you've been there for more than 2 years, hm? 2 years is the average period at a company these days unless you're aiming for management.
My advice: leave it alone. Focus on yourself and your code, improve your skills, and look for another role in another company. You'll be happier in the long run for the only reason that you can only change your behaviour. You cannot help others, I've got the scars and burns to prove it.
My advice: leave it alone. Focus on yourself and your code, improve your skills, and look for another role in another company. You'll be happier in the long run for the only reason that you can only change your behaviour. You cannot help others, I've got the scars and burns to prove it.
> Company has lots of guidance
Does this mean its an actual standard? You can fail the PR for not following standards.
> Adding unit tests for some piece of logic
Are unit tests required? Fail the PR if it doesn't have the tests. If you decide to allow a "I'll do it later", only do so if they have a ticket, assigned to them, in the backlog.
> I discovered a chunk of code copied from Stackoverflow
Now it's a problem for HR, because they're exposing the company to legal risk.
All of these items are things that should be passed to the manager every time they happen.
Does this mean its an actual standard? You can fail the PR for not following standards.
> Adding unit tests for some piece of logic
Are unit tests required? Fail the PR if it doesn't have the tests. If you decide to allow a "I'll do it later", only do so if they have a ticket, assigned to them, in the backlog.
> I discovered a chunk of code copied from Stackoverflow
Now it's a problem for HR, because they're exposing the company to legal risk.
All of these items are things that should be passed to the manager every time they happen.
I've worked with a couple of these guys at my current company. I spent six months trying to get along with a guy and get some kind of compromise going. After lots of abuse and long, painful workdays I finally asked to be switched to another team. If your management doesn't value the integrity of the workplace and doesn't hold the person in question accountable, there's no use fighting it.
The 'large PR' issue - I've been on the 'violating' end of that, but... there are actually times when a PR touching a lot of files and making changes is called for. I got push back at the last team I was on where this was an issue, and the stated thing was "it's hard to review".
Yet... no one ever - literally - pulled down code in a PR/branch and reviewed it locally, never reviewed any tests (in 2 years I never got one question about a test as in 'you missed use case X in your tests', etc). They literally just meant "reviewing this on the screen in the github UI is hard when there's more than a handful of files - it's hard to tell where the changes are or what they effect". This is why I would also have tests and (sometimes extensive) documentation in the PR, to help a review. Never happened.
I had "large" PRs (by someone else's labelling) about 10-15% of the time. I would get pushback - "this is too much - it's too confusing".
Me: "OK... let's schedule some time to review - maybe you can help me cut it back some, or you can assist me in some way in this work?".
Others: "don't have any time for that - this is just too much work".
OK, so... complain about the work, but when I ask for help to conform to your standards... I get a refusal.
I point blank asked multiple times when this was lodged as feedback - "what steps could I take to have made this smaller?"
The only substantive thing that would have made it somewhat easier to roll out some of these "larger" changes in smaller chunks would be to have had a more comprehensive feature-flag system in place.
I put a basic flag system in over a weekend - some server side, and some hacky method to respect the flags in client side code as well. It was done over about 3 hours, and was never improved. Again - very hacky. I had an "improvement" ticket in for... about a year, begging for more than a few hours to devote to tightening up "feature flag" system to be a bit more comprehensive, documented, etc.
Every "sprint planning meeting" it was the same "there's no time for that, it's not that important, quarterly deadlines, blah blah blah". But if/when I'd do things that were 'unticketed', that was met with accusations of being passive/aggressive, or being subversive, or 'not a team player'. "If you've got time to do that, you could have been helping out people who were behind". The same people who didn't write tests or documentation, and refused to meet with me when I asked for assistance in trying to accommodate their calls for "smaller PRs".
First year on the project was good, but as it grew, policy/procedure/scrum/agile got in the way, with more process and less ability to get useful stuff done. Second year was far less productive (at least, compared to what it could have been - I'm sure some people just saw forward progress as 'good', but we were greatly slowed by more process and ceremony over time).
Yet... no one ever - literally - pulled down code in a PR/branch and reviewed it locally, never reviewed any tests (in 2 years I never got one question about a test as in 'you missed use case X in your tests', etc). They literally just meant "reviewing this on the screen in the github UI is hard when there's more than a handful of files - it's hard to tell where the changes are or what they effect". This is why I would also have tests and (sometimes extensive) documentation in the PR, to help a review. Never happened.
I had "large" PRs (by someone else's labelling) about 10-15% of the time. I would get pushback - "this is too much - it's too confusing".
Me: "OK... let's schedule some time to review - maybe you can help me cut it back some, or you can assist me in some way in this work?".
Others: "don't have any time for that - this is just too much work".
OK, so... complain about the work, but when I ask for help to conform to your standards... I get a refusal.
I point blank asked multiple times when this was lodged as feedback - "what steps could I take to have made this smaller?"
The only substantive thing that would have made it somewhat easier to roll out some of these "larger" changes in smaller chunks would be to have had a more comprehensive feature-flag system in place.
I put a basic flag system in over a weekend - some server side, and some hacky method to respect the flags in client side code as well. It was done over about 3 hours, and was never improved. Again - very hacky. I had an "improvement" ticket in for... about a year, begging for more than a few hours to devote to tightening up "feature flag" system to be a bit more comprehensive, documented, etc.
Every "sprint planning meeting" it was the same "there's no time for that, it's not that important, quarterly deadlines, blah blah blah". But if/when I'd do things that were 'unticketed', that was met with accusations of being passive/aggressive, or being subversive, or 'not a team player'. "If you've got time to do that, you could have been helping out people who were behind". The same people who didn't write tests or documentation, and refused to meet with me when I asked for assistance in trying to accommodate their calls for "smaller PRs".
First year on the project was good, but as it grew, policy/procedure/scrum/agile got in the way, with more process and less ability to get useful stuff done. Second year was far less productive (at least, compared to what it could have been - I'm sure some people just saw forward progress as 'good', but we were greatly slowed by more process and ceremony over time).
Common denominator of all three issues is bad PRs. You don't say much about company code review process, the central question being, "Who has commit authority?" Clearly the problem child should not.
If it's only you trying to block a merge, perhaps deputize others to co-review. Hearing your same objections from multiple others could make them harder to ignore.
If it's only you trying to block a merge, perhaps deputize others to co-review. Hearing your same objections from multiple others could make them harder to ignore.
Reject changes with a short but accurate description why. Some folks communicate better through text/email/post/etc. Reply all always and cc: managers when necessary. Another rule is never blindside your manager. That’s a sub-rule of, never be the highest ranking person aware of a problem.
If this is the company I think it is, privately contact opensource-licensing, or just cc them on the review.
Make it cost something. Like, force them to watch a training video or something. Schedule a long meeting at a time they don’t like to discuss the issue.
Lastly, consider that maybe they are saying something that should be heard. Maybe they are right and it just appears to be foot dragging.
Lastly, consider that maybe they are saying something that should be heard. Maybe they are right and it just appears to be foot dragging.
> - Adding unit tests for some piece of logic. The benefits of unit tests are so fundamental, but I try to emphasize that there are many people working on the codebase, don't want to accidentally introduce bugs, protect that logic for the future, etc. Generally get push-back like Well it's so simple. It's not worth testing. I'll add a test later. etc
This one is easy to solve. Having automation or, as usual, blocking the PR with a change request and having it blocked until the necessary code get the tests needed. Again: Maybe the developer will add it, maybe you can do it in a pair programming session, or maybe you just submit the tests to the PR and lead by example. Sometimes it can be frustrating, but I'm sure to bring such proactive actions up when I'm negotiating my salary raise..
This one is easy to solve. Having automation or, as usual, blocking the PR with a change request and having it blocked until the necessary code get the tests needed. Again: Maybe the developer will add it, maybe you can do it in a pair programming session, or maybe you just submit the tests to the PR and lead by example. Sometimes it can be frustrating, but I'm sure to bring such proactive actions up when I'm negotiating my salary raise..
This is where office politics come into play.
You build not only a strong list of counterpoints and points (without a single mention of the forcefully person's name) then elicit as many peer supports as you can with that list (preferably on paper that you can take back). Sometimes, I've had to remove the forcefully person's lone point in order not to tip my hand.
Then reveal in a meeting, again without mentioning the forcefully person's name.
I've gotten 100% this way, even the forcefully person's silent resignation and it's "aye" once the consensus is revealed.
Surprise is the name of the game.
If you cannot pull up a decent list and a consensus then you probably should just move on, unless it is a safety factor or a danger to one's life.
You build not only a strong list of counterpoints and points (without a single mention of the forcefully person's name) then elicit as many peer supports as you can with that list (preferably on paper that you can take back). Sometimes, I've had to remove the forcefully person's lone point in order not to tip my hand.
Then reveal in a meeting, again without mentioning the forcefully person's name.
I've gotten 100% this way, even the forcefully person's silent resignation and it's "aye" once the consensus is revealed.
Surprise is the name of the game.
If you cannot pull up a decent list and a consensus then you probably should just move on, unless it is a safety factor or a danger to one's life.
I love it when my post gets downvoted because it tells me that it is probably some disgruntled middle manager who previously got upstaged due to its own idiocy.
On this, I have to say, listen to their POV and weigh carefully.
On this, I have to say, listen to their POV and weigh carefully.
Document (preferably the whole series of incidents) and escalate. It helps if evidence is not modifiable (e.g. review comments are immutable and can't be deleted).
People who refuse to listen aren't worth arguing with.
Route around them, which may include transferring or finding another job.
Route around them, which may include transferring or finding another job.
I’d find a way to get rid of a copy paster.
Just PIP em and keep rolling.
Start a disciplinary process or it will only get worse over time.
.
I mean, the unit test one is open for debate for sure. First one can be more black and white. Third one is a grey area as well
There are a number of people who don’t respond well to “authority” and would immediately see you as someone trying to sabotage them and their position using your own position. For instance, this feels remarkably personal over something that is entirely a personal judgement. What is “small” and do both people have the same meaning? What is a unit test and can it even be tested? For example, you literally cannot test integration points of two systems in a meaningful way.
[deleted]
Yo. Ignore that shit. All this effort over nothing.
In the end it comes down to “don’t negotiate with terrorists”. If they disagree with the policies that’s fine, they can bring it up at a meeting. Call a meeting even, showing you’re willing to listen to their input is important. But you‘ve got to make it clear as day that there will be no going rogue if they disagree.
In the ideal world you would be their manager. Right now responsibility and accountability are separated, which is most likely causing you stress. Bring this up with your manager: tell them your plan to deal with the situation, ask for input and their backup. That way you now have a bigger mandate, and you don’t get in trouble for being tougher than you have been so far. Managing up is as important as managing down.
It might sound odd to have to lay down the law of the land, while simultaneously advising you hear them out. It isn’t. People generally want to be heard more than they want to be right. Show them you hear their concerns. Let them bring all their frustrations out. Tell them you’ll try to improve the situation for them. But also say that you cannot have somebody on the team who doesn’t abide by the policies set, and this behavior cannot continue. The content of the policies is irrelevant to that point, it’s a clear chain-of-command issue.
In the ideal world you would be their manager. Right now responsibility and accountability are separated, which is most likely causing you stress. Bring this up with your manager: tell them your plan to deal with the situation, ask for input and their backup. That way you now have a bigger mandate, and you don’t get in trouble for being tougher than you have been so far. Managing up is as important as managing down.
It might sound odd to have to lay down the law of the land, while simultaneously advising you hear them out. It isn’t. People generally want to be heard more than they want to be right. Show them you hear their concerns. Let them bring all their frustrations out. Tell them you’ll try to improve the situation for them. But also say that you cannot have somebody on the team who doesn’t abide by the policies set, and this behavior cannot continue. The content of the policies is irrelevant to that point, it’s a clear chain-of-command issue.
Several times in that span, I've worked with people who push back quite forcefully on comments or feedback on topics or practices that have either explicit company standards or at least generally accepted best practices.
It seems to me that most people at the company are conflict-avoidant so that when these people push back aggressively, it's often a successful strategy. Ten minutes of arguing and wearing the other person down saves them 20 minutes of writing unit tests or fixing their code or whatever. I've seen in the past that these people effectively carve out an unspoken exemption for themselves because everyone is sick of having the same conversation.
I'm the tech lead but not manager of my current team and I'm responsible for the technical execution of the team and the success or failure on that level. There are a bunch of great people who do great work and are pleasant to work with but there's one person who is so unpleasant to work with. I hate that I have to constantly remind this person of company/team/professional standards and that it feels like every conversation is an argument (examples below). I hate that this is in my head on the weekend.
Questions:
- I try as much as possible to explain _why_ practices are what they are, the effects on our project, the team, etc. Any suggestions for these conversations in the future?
- I can't control this person's behavior but I can control my response. Suggestions for dealing with this personally so I'm not wasting my Sunday thinking/writing about it?
- Other thoughts or feedback?
Thank you so much in advance!
Some examples: - Sending a large PR that changes many files at once because their changes kept growing in scope as they were trying to figure out how to do something. Company has lots of guidance about small changes being easier to review, less bug-prone, etc and how to break them up. I try to emphasize the benefits for the team and codebase, the respect for the reviewer, etc. Generally get push-back like "What does it matter?", "It's already done.", "It would take too much time to break up.", "I'll do that next time", etc.
- Adding unit tests for some piece of logic. The benefits of unit tests are so fundamental, but I try to emphasize that there are many people working on the codebase, don't want to accidentally introduce bugs, protect that logic for the future, etc. Generally get push-back like Well it's so simple. It's not worth testing. I'll add a test later. etc
- On Friday, I discovered a chunk of code copied from Stackoverflow. It was crappy code, which is what caught my eye in the first place. Company has clear guidance that if you want to use outside code, we must verify the license and segregate it from owned code. (If you're curious why: it's hard to know where the SO code originally comes from, maybe copied from a closed-source project or one with GPL license or whatever, and even if it's original to SO, there is a license for that and it wouldn't be considered owned by the company). I was shocked to receive push-back on this. The person said things like "how would anyone find out", "what does it matter", "everyone does it", "it's so low risk, who cares"