But being a "shit umbrella" is literally part their job. A good manager should be filtering inputs from external sources, tossing out the useless input, and translating useful inputs into actionable tasks or discussion points for the team.

Instead of "stop coding bugs", the manager should be having a discussion about defect escape, test quality (across the spectrum of test types), and doing some self-reflection on whether or not task descriptions are adequate (if they only ever capture the "happy path" and don't describe desired failure behavior, it shouldn't be surprising there is undefined behavior in the software).

I think this means he is clueless in the way that a developer asking "what is a for loop" would be considered clueless. Managing company perception of what your team is working on, and advocating for their work both in terms of features and fixing bugs is like Engineering Management 101. Doing all this "asking questions to find out" stuff is what the manager should be doing.

> My experience is that if the team isn't translating what they are doing, why, etc...upwards, then the boss eventually makes up something to measure.

Again, managers doing this are clueless in the same way that a developer "making up" syntax would be. They should be replaced by better, more clueful managers.

I have absolutely no idea why we as an industry tolerate arduous coding tests and take-home projects for "individual contributors", but have a propensity to give people managers a free pass on obvious stuff like this.

But if the IC is having to dig to understand what a manager means then the manager has failed at one of their core duties, being communication channels through the company. If someone isn’t a good communicator they’re definitely not going to be a good manager.

I mean, in one sentence the author writes:

> Well, that and Kevin needs to learn how to code, so he can then learn just how ignorant “Stop putting bugs in the code” really sounds to a development team.

And in another it's:

> Detailed tellers are so happy that they finally have the power to get everyone to write code “the correct” way. Tellers are especially bad if they have lots of energy and vigor as you can’t just wait for them to go away. This manager type is probably single-handedly responsible for causing software engineers to be reticent about working for a manager with technical chops.

So the manager is clueless if he or she can't code, but also clueless if he or she can and crosses the author's undefined boundary for too much direction and detail.

The message: the author (and her prototypical developer) know it all. Everyone else probably sucks, probably beyond repair.

Yes, bad managers do exist. Exceptional ones are not super common. But the same could be said of developers and I'd say that based on the following, the author exhibits a toxic attitude that every team should look to avoid.

> So, as a developer, what can you do?

> Not much, unless you have a good shot at getting the manager removed without hurting your career. You might be tempted to somehow educate your manager, and if the skill gaps are pretty small, and the trust level is high, the managing-up school of management can be effective. However, most development manager skills gaps are on the scale of the Grand Canyon.

As someone who started as an engineer, moved up to management and then started my own companies, I've seen first hand that very few things hurt an organization more than employees who think they know it all and that everyone else is a problem that can't be fixed. You can (usually) fix bad code. You can almost never fix a toxic attitude. This post contains way too many of the toxic attitude red flags.