Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: How to work with people who push back forcefully?

news.ycombinator.com

Post reply on HN
Print view View original

21–30 of 95 posts

Re: Ask HN: How to work with people who push back forcefully?

#21

Post by pelasaco »

> - 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..

Re: Ask HN: How to work with people who push back forcefully?

#22

Post by jacobyoder »

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).

Re: Ask HN: How to work with people who push back forcefully?

#23

Post by curiousllama »

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.

Re: Ask HN: How to work with people who push back forcefully?

#24

Post by itronitron »

SoftTalker wrote: post #9

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 terminat…

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.

Re: Ask HN: How to work with people who push back forcefully?

#25

Post by MrMcDowall »

Terretta wrote: post #12

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 te…

Do you have source on item #2? I've been looking for some to back this point, but can't find any.

Re: Ask HN: How to work with people who push back forcefully?

#27

Post by haswell »

Terretta wrote: post #12

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 te…

> 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.

Re: Ask HN: How to work with people who push back forcefully?

#28

Post by pcthrowaway »

itronitron wrote: post #24
SoftTalker wrote: post #9

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 terminat…

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?

Re: Ask HN: How to work with people who push back forcefully?

#29

Post by femto113 »

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.

Re: Ask HN: How to work with people who push back forcefully?

#30

Post by comprev »

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.

Post reply on HN