This sounds like an example of the AZ problem[1].
Hope you find the website helpful! :)
JFYI, and in case you want to add a reference to the chocolate covered banana:
http://web.archive.org/web/20160523201519/http://homepage.nt...
http://web.archive.org/web/20160329162624/http://homepage.nt...
that I have been citing a lot, together with the Yes/No and the Standard Litany:
http://web.archive.org/web/20160527013035/http://homepage.nt...
http://web.archive.org/web/20160604095422/http://homepage.nt...
Will definitely source these, how come the original site is down? Edit: found one that's up: https://jdebp.eu/FGA/put-down-the-chocolate-covered-banana.h...
http://homepages.tesco.net/J.deBoynePollard/
Before being:
http://homepage.ntlworld.com./jonathan.deboynepollard/
all the FGA's are nice, (besides - the technical ones - extremely accurate) if you loved the chocolate covered banana one, you will surely appreciate the "legacy" correct definition:
https://jdebp.eu/FGA/legacy-is-not-a-pejorative.html
and don't miss the note about the secret 7:
Do you know if it belongs to a category of problems, in the same manner that e.g. the "either-or" belongs to the category of logical fallacies and confirmation bias belongs to cognitive biases? I always find those types of categories useful in building mental models.
You kind of put me on the spot here, I'm not sure. I'd have to think about it for a while, but my gut feeling is that, yeah, it probably falls in the overarching category of "not knowing/realizing that you don't know something" -- so the failure point is epistemic.
If this was a code review, the end of the month code in this example should get flagged for its complexity, when it can be replaced with the single conditional "if tomorrow.day == 1".
It's entirely fine to question the specification/request here, and ask why the end of the month. Not because the code that detects the end of the month can be written in a complex fashion, as it was here. Rather it doesn't seem to meet the requirements: The Account Manager doesn't realize that by processing on the last day of the month, rather than after the last day of the month, is going to miss out on some portion of the last day of "accumulated fees" for the month (depending on the rest of the implementation). The Account Manager has requested an implementation detail that doesn't meet the requirements, and now rework is required.
But it's not a code review. It's a frivolous and simple example to show the underlying impact of not understanding the context of a hypothetical feature request. I have a feeling that in typical engineer fashion, you're missing the forest for the trees. Trust me, I've been there :)
Yes, it is a contrived example, that's my point. But it's not the programmer that didn't understand the feature request, it's the entire organization. A questionable decision earlier made by the Account Manager led to an overly complex, questionable implementation that will lead to more code and more bugs. Trust me, I've been there.
In many cases middle managers think they know what needs to be cut or what programs are a waste without all of the facts of the organization. I saw this a lot in government.
For example some organization was on the books for the primary reason of being the focal point for a contract vehicle but was in a holding period waiting protest or something and not doing much for a year or two - so it looked ripe to cut - when in fact it was more of a "lady in waiting" for the broader organization.
If your grand-manager tells your manager "ok, today your job is to cut $X from this team's budget", then she'd better do that. She might know full well you have the time and capacity to do it yourself, but if she passed it down the chain someone might notice she wasn't doing anything.
Which, obviously, is equally dysfunctional. But it can explain why someone who isn't generally a micro-manager is churning up extra work.
Then something changed. Having a softer touch became more important than results. This weird sort of litigation-phobic (pardon my inarticulate explanation) approach to all things took hold. Managers stopped giving clear feedback. They stopped assigning work, merely suggesting it. It’s completely bizarre. Especially when you’ve been in the military and seen real decentralized and self organizing leadership work.
These days as a consultant I go in and basically fill a leadership vacuum at each of my clients. I tell them this too. They shrug and keep shuffling and saying things that mean nothing. So weird. I don’t understand the corporate world.
I consult for the Canadian government from time to time and I see plenty of great managers there. The main difference? Most people there for more than 2 or 3 years are there for life. They get to see the results of prolonged good leadership and they get to learn from leaders that they trust.
With tech you have random 27 year olds as C-levels at eight or nine digit valued companies (that was me some years back) and there's no way that you have the skill or experience or even respect for the position to do it well.
Makes me think of stores about Steve Jobs, and how there would be a virtually endless runaround of him claiming not enough this, too much that.
Like if your manager said, I'm trying to reduce our costs by 10% so that I can get a big incentive bonus personally...
If a manager says "I need to reduce costs by 10%", the specific desired business outcome is clear. Reminding your subordinates that your pay and continued employment is tied to you completely the tasks and requests of the people you answer to doesn't seem needed. This isn't about "some organizations", it's just about efficiency.
Usually the current costs are the cost of business, and if there is an externality ie economic downturn, some crisis, big lost deals, then there may be renewed pressure at which point this has already been communicated by the leadership to the org and everyone is on the same page.
Trying to reduce costs out of the blue is not usual, it suggests some individual thinks there is some inefficiency after studying the issue, or its a management consultant recently hired to explore that, but usually the people being requested for information would be briefed and know exactly the reason and why.
When I could have offered up lower lying fruit if exact cost was identified as the driver up front. The questions weren't easy to translate into actual intent at first. Leadership styles profoundly affect efficiency.
Another student of Carl Rogers was Joseph Weizenbaum, the creator of ELIZA.
Pretty embarrassed about our current state of leadership skills. In my current organization, we call this syndrome "bring me a rock". Like, I bring a rock, and she says "it's too big, or too brown, or whatever". Instead of outright saying, "I need a medium, smooth, grey, rock". I can deliver if you're explicit.