There is no toxic negativity

There’s an excellent Medium post by Way Spurr-Chen that has been making the rounds on Twitter and LinkedIn titled “Rage Against the Codebase: Programmers and Negativity.”

I think the article makes many good points about why programmers value negativity and the author posits two possible (admittedly stereotypical) outcomes of such a value system: the “zen” programmer that accepts lousy code as a natural part of the system and the “embittered” programmer that refuses to accept the bad parts and is in constant negative struggle.

It then proceeds to advise how to avoid negativity. At this point, the blog post becomes weak in my opinion, and I would like to present you with an alternative ending. As I said, I agree on many points, although for example, I disagree with the two final stereotypes because I know from first-hand experience that we all flip-flop between embittered and zen modes. It all depends on how much we can influence our surroundings: I can accept that there is always going to be code to fix, but I think it is not acceptable to ignore technical debt when it has a real and measurable effect on culture or productivity. As such, I would rather part ways with a company that shows such a lack of foresight simply because other, better, companies have the understanding needed to do better in the long run.

Teaching people how to be “negative-but-not-negative” by presenting their criticism with a little more respect is in itself one of those ideas which seem common sense superficially but very often turn out to be worse than what they try to solve. I tried to convey this in a tweet.

I so disagree with that. Let's not have a world where code sucks, and we can't even say so otherwise we are too negative. Making problems emerge is not at all being negative. Never complaining about stuff you should be complaining about, instead, is absolutely toxic. 1/2 https://t.co/28VLDiVXJ8

— Marco Cecconi (@sklivvz) May 16, 2019

Negativity is fundamental because it is the only force that allows problems to emerge so we can address them. The alternative is forgetfulness and denial, which makes us helpless and victims of our own mistakes. The problem in insisting on “the correct form” for negative feedback is that this automatically selects the better speakers or, the more articulate developers who become the few that can give “negative-but-not-negative” feedback, but excludes the rest of people who are not so good at expressing themselves but perhaps have incredible skills in finding problems.

Should we give up and not train people on how to give better negative feedback? Of course not, but we must understand that not offending people when giving feedback is necessarily optional. Sometimes feedback offends people. Being “zen” also means accepting this fact of life, which the author does not seem to consider explicitly.

The author says: “I can’t tell you the number of software projects that I have seen (and heard of) get torn down and completely rebuilt at great cost because one trusted software developer had an axe to grind with a technology, a former developer, or a single file they took to be representative of the quality of the entire codebase. It’s also demoralizing and strains relationships.”

Strange, but this seems entirely uncommon. Projects fail because they are poorly lead, teams build the wrong products all the time, or they fail because teams executes them so poorly that they cannot complete them. In either case, negative feedback was certainly lacking.

The answer is not that negativity “should be dosed with other essential human qualities: compassion, patience, understatement, and humor”, although we should certainly strive for those qualities all the time.

The answer is that lack of positive feedback is what makes teams and culture toxic. If that developer that says “this code sucks” is also able to say “this other code is awesome,” then his coworkers are going to learn so much more. They learn twice as fast because now they have positive examples on top of the negative ones. They learn that said developer is giving them feedback, not criticizing them.

Culture is like the air we breathe. While we need oxygen, we also need nitrogen and carbon dioxide. Likewise, we need people to feel safe, to express their negative opinions without fear to be sent to HR, to receive training on how to be more effective communicators of criticism, to be also taught to bring out the positive together with it.

What do I do daily? I advise companies on how to improve their culture and their codebase at the same time. I build a product named Badgie that gamifies the whole development experience to bring positive in the sea of negative in which we live.

Ultimately I’m prepared to bet this will be more effective than teaching negative people to be negative while being courteous. What is considered polite/positive/negative is inexorably bound to culture - focusing too much on achieving a perfect tone implicitly demands cultural uniformity. And this approach is coherent with a very Anglo-Saxon view of the world. I do not expect it to be effective in a lot of different cultures.