I'd much prefer to have GP on my team than you, frankly. I think companies are much more productive when they have people willing to learn from and teach one another rather than bringing negativity.
The last few years, I've primarily been working freelance going in to companies and dealing with crap cleanup left by people who were "positive" about their own abilities, gave a pass to everyone else on the team who could get something to run without too many obvious errors, then left.
So... you can call it negative, I call it realistic. I'm pleasantly surprised when I discover good, well-written code, and it means my estimates can be revised downward - something everyone enjoys. Hoping for the best and getting the worst is horrible - expecting "meh" and getting a positive shock is great, but doesn't happen all that often.
I'd have loved to be at a company where people learned from each other and taught one another - imo, it's extremely rare. I've seen it a couple times in the past 15 years, but more often than not, politics and/or ineptitude takes over, and the 'learning/teaching' thing goes out the window.
As a developer, I had a technical manager over me who'd never coded. I've had a colleague who was hired to 'fix bugs', and has to watch the people who wrote the bugs go rewrite everything in to a 'version 2', rewriting exactly the same problems, because "they've been here longer".
So... yeah, companies that foster teaching/learning environments might be nice, but it takes a LOT of work to get right.
That seems like a false dichotomy. Someone who's a pollyanna even about horrendous abominations is a problem in one way, someone who's indiscriminately contemptuous of reasonably useful code is a problem in another way. Software projects (or teams, or companies) can bog down or die in more than one way. Driving off people who are doing reasonably good work is one way, tolerating unreasonably low standards is another.
And also, correct criticism is not particularly "bringing" negativity. If there is something unacceptably technically bad, and you want to point to the person or people who brought the negativity, you'd do better to point to the original creators and/or the chain of people who have signed off on it since then, rather than pointing to the person who criticizes the problem. The irreverent child did not bring the negativity to the Emperor's famous tailoring fiasco.
Someone who reasonably reliably distinguishes between good and bad is useful. Making the distinction correctly is generally much more important than the style of expression. It's easy to hire pollyannas (or, indeed, to err in the opposite direction by hiring hard-driving abrasive jerks) who don't have the tech skills to make the distinction correctly and just fall back to emoting in their preferred style. It works better to hire the smaller fraction of people who can do a good job, and who can recognize a good job. When you do that, it doesn't solve all style-related abrasiveness problems, but it does help mitigate them. By the time you've worked with someone for a while you learn to translate A's "this is unacceptable" as synonymous with B's "this is flaming rancid goat barf". (And axiomatic though it seems to be to you, in my experience saying "flaming rancid goat barf" is not useful evidence of unwillingness to learn and teach.) Both A and B are useful as long as they're reasonably reliably correct. Much bigger problems are C who says "this is a good effort" about everything, and D who flips between praise and condemnation based on issues other than technical quality (randomness, politics, mood swings, whatever).
My dichotomy was between the parent and the grandparent.
I totally agree that not addressing issues and not bring (constructive!) criticism is a poor strategy. But your persons A and B have the same problem: they're critical without being providing any actual information. Person B just compounds it by also being a jerk.
As a programmer/businessperson, I'm not interested in making people feel good about poor quality work. I'm interested in people who want to improve themselves and the overall product, and ideally, enjoy the process. I just don't see how insulting code or people helps. I think it's perfectly possible to hold high standards on code and respectful conduct, and it's perfectly possible for people to rise to those standards, guided by constructive criticism.
