A big YMMV on what I'm about to say, but: in my experience, the biggest complainers at work are the most responsive and productive people. Because when a new request comes through, they're the ones who have already jumped in. They're mentally working through what it will take to get this done, wrestling with the difficulties and verbalizing them. Others are nodding and smiling but not really engaging with the problem yet.

I think there is something to it. The ones who complain but still trudge through are amazing. They highlight pain points and solve them at the same time.

That's the key: they still trudge through it. I fully agree that those people are indeed amazing. In my experience, though, many complainers toss out every objection possible hoping to make the new project seem so difficult that it isn't worth doing (so everyone will just drop it). Those complainers are toxic and can kill progress. But yes, the ones who verbalize issues just to make sure everyone has a full understanding of a project and the challenges in completing it... but still have every intention to conquer those challenges and stick with it to the end... yes, give me those types of 'complainers' ANY day :)

From my point of view, we get a new project that I think will take 6 weeks because of X, Y Z. Management thinks it should take 2 days, so they say go ahead anyway. The project takes 8 weeks to finish most of the features and doing this effort forced us to drop every other thing we were already maintaining and working on. Everything is late, the targets set for the year miss as we spent 2 months on this other project and nobody is happy.

Those types of complainers are certainly better than the types who don't actually do the tasks. But even better are those who do the tasks without burdening their coworkers with complaints.

As an "old warhorse," I can tell you that I have been labeled a "complainer," because of such "complaints" as "Have you considered what happens when the user does X?" or "I tried pretty much the same thing, last year. It didn't turn out the way I wanted. Here's what happened..." or "Is that thread-safe?" or "Are you sure that will never be called on another thread? You do have a few network closures, here." or "Did you make sure that you let the connection go, after sending that instruction? It will result in power drain, if not."

etc.

Real killjoy.

I'm one of those people and I've been wired that way mostly out of empathy and curiosity combined with a hope to build things for others.

For the most part I've come to understand that complaining had to be used strategically like a tool, mostly devoid of emotions I might otherwise feel.

If you complain because you struggle in various ways, because something is badly managed around you and you're the only one to see it, or because you feel empathy for a colleague who isn't putting in some effort to phrase their struggles fully, then you will expose yourself to more harm than good and often enough lose points in the cause you were trying to alleviate.

You complain about a subject that might bring different people together with their perspectives and perhaps show to a manager the multi-dimensional nature of what you had already worked to highlight. Or complain with intensity about a problem when the scope and impact make it undeniable that the clients/end users/company image are going to be at stake and you have some serious numbers to show for it. Complain with a bunch of suggested pathways and actors you can name at the drop of a hat to engage a more complete process for resolution. In these ways you can fast-track what some meetings and back and forths would do in 10x the time.

At the end of the day I've pretty much always struggled with my own mental health when taking on too much, "caring too much". Complaining can also be a symptom of a need for things to change, whether the environment or the self (or both).

I’ve found that complaining is productive but has a social cost. But I and others absolutely do work this way.

I started opening GitHub issues I never expect anyone else to read to help myself explore and verbalize a problem without having to nag anyone else about it; it’s been helpful and also yields a lot of what is effectively documentation of the “why” behind our design choices. Not sure if it would work as well on public repos or if you work with anyone that tries to max their GitHub stats (eg average issue close time) though.