I used to live in Montreal. Cabs there need to get a safety inspection like every 6 months.

Talking to some cab drivers there, many of them remarked that the people doing the safety exam -had- to find something. Your car could have been fresh from the mechanic, they’d find something to complain about.

So, starting about 6 weeks out from their next safety, if something went wrong but the car was still drivable, they wouldn’t fix it. So the safety guys had something to find, and they were going to pay to fix it anyways.

I think we can be a bit less cynical about this behaviour, at least in some cases.

Perhaps a fresh pair of eyes is always going to notice a bunch of potential changes, which would improve things from their subjective point of view. But humans are notoriously bad at absolute scales (see Thinking Fast and Slow by Daniel Kahneman) so it's hard for us to decide "I can see a bunch of issues but they're all below the threshold for changing". The top of the scale is always what is most important out whatever issues are left. Adding the duck reshapes the scale so all those other things seem (correctly) trivial in comparison.

To put it another way, if the deadline is tight and the program kept crashing, maybe they wouldn't have even asked to remove the duck! The scale would have changed again, and the bit with the duck on it would have been compressed below the threshold.

I tend to interpret this as a sure sign of a manager who secretly knows they're useless.

If you're the manager, your job isn't to do my work. Your job is to optimize my (and the rest of the team's) ability to do our own work. If I've missed something that should be part of a procedure, that should be in a checklist I should have reviewed before submitting my work. You shouldn't have to tell me to tweak it.

If I'm handing the work off to a team that is responsible for small stylistic choices, they too should have a set of standards, but at least if they change their minds about something, that's their role and their job.

I remember an interview from Soviet cinema director Georgii Daneliya, mentioning that to make their movie pass the approval committee intact (what you'd call "censorship"), they'd make absurd and provocative "sacrifice" episodes (like "sacrifice bolts"). The episodes were fought over and finally seceded to the committee, but the rest of the film went into the theaters.

(Movies had to pass two such committees: one before production, approving the scenario, and the other one approving the final cut.)

I learned of this from "New Programming Jargon" a decade ago on codinghorror: https://blog.codinghorror.com/new-programming-jargon/

I still regularly refer to Smurf naming conventions, Stringly typed, Protoduction and others.

I used to work at a startup whose clients worked on behalf of large corporations. I once tried to automate some things to make the company more money as our clients were rather inefficient at their settings but got a lot of push back. Then I talked to our clients and they said that unless they had knobs to turn to "prove" they provided value they'd be fired by their clients (the large corporations). If they got fired then they'd stop spending money with us and so we'd actually make less revenue due to second order effects. It was an enlightening experience.

When I was finishing my PhD thesis, the suggestion was to insert some low-hanging fruit for the reviewers who would be doing only a cursory review but would need to find their "duck". Didn't do it because my committee was excellent and didn't want to show any disrespect.

Man, I loved Battle Chess as a child. I would play with the aim of finding new mach ups I hadn't seen, rather than try to learn strategies for winning in chess.

And of course Youtube got us covered today: https://www.youtube.com/watch?v=N7ccs3dRhW4

The flip side is equally true. People don't usually internalise suggestion at face value unless they are in the right situational mindset. For example, telling your colleague directly that making a smaller pull request would make the review process easier may fallen to deaf ears. But someday, maybe having reviewed other colleague's PR, or maybe reading a blog of a famous professional, the same colleague may suggest back to you the very same thing you suggested 3 months ago.

There is nothing wrong people giving suggestion or opinion. It takes taste to discern which suggestion has merit. And it take experience to build up taste

“You have to give an editor something to change, or he gets fretful. After he pees in it, he likes the flavor better, so he buys it.”

— Robert A. Heinlein, _Stranger in a Strange Land_.

I’m dealing with this in almost daily basis. People are afraid of not having an opinion and appearing stupid.

A prior thread: https://news.ycombinator.com/item?id=9137736

When asked to review something, I like to use a version of Brené Brown's question, "What does support look like?"

I can rubber-stamp, LGTM, proof-read, rip to shreds, etc. You tell me what you want.

This is closely related to the “hairy arm technique” (it’s known by multiple names). This is where some people find it is necessary to nitpick everything even when it is unnecessary and the solution is to purposely make one aspect of some plan obviously bad, dumb, or nonsensical.

The person will then insist that be removed, ensuring the actual underlying work isn’t impacted by their incessant pickiness.

I’ve had to use this technique myself a few times, mostly with micromanagers/agile fanatics/product owners and the like.

Quite often the person believes they are helping with their suggestions (or at least that's what I believe when I'm the one doing the suggesting). But there is certainly better and worse ways to make those sort of suggestions.

On the other hand, I quite often don't bother rounding the corners of boxes when working on a web UI until one of the last things. That way anyone who just wants to make their mark can just suggest rounding the corners :D

When I do code reviews I always try to find something to comment on, even if it is just a optional suggestion or question.

If the code review system has a lot of approvals from me without comments in the code review system I suspect it will hurt the organization's perception of my work.

Yup, I call that Wolf Management for the same reason.

It would have been better with the duck left in the game. "Why is there a duck there?" -> "Great story, no one on the team was the sort that bikesheds things" -> "omg, your team was the luckiest like ever!"

Why is the PM the meddling one here, and not the artist who (presumably un-prompted) added a duck to the game? Seems clear to me that the artist was the one who wanted to leave their mark in this story. Are some people allowed to and others not?

As someone whose job includes big components of both technical work and project management, I can’t help but wonder:

How frequently am I shown ducks?

Bad form to remove the duck. Basically every project manager ever. Somehow, “A.I” doesnt seek to replace them.