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.
Ask HN: How to work with people who push back forcefully?
51–60 of 95 posts
Re: Ask HN: How to work with people who push back forcefully?
#52Enforcement 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.
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.
Re: Ask HN: How to work with people who push back forcefully?
#53.
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.
Re: Ask HN: How to work with people who push back forcefully?
#54Reject 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.
Can you elaborate on "never be the highest ranking person aware of a problem"?
Re: Ask HN: How to work with people who push back forcefully?
#55Does 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.
Re: Ask HN: How to work with people who push back forcefully?
#56My 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.
Re: Ask HN: How to work with people who push back forcefully?
#57First 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 te…
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’…
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.
Re: Ask HN: How to work with people who push back forcefully?
#58In 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.
Re: Ask HN: How to work with people who push back forcefully?
#59In 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…
Upvote
Re: Ask HN: How to work with people who push back forcefully?
#60Earlier quoted context omitted.
> 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 t…
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 t…
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.