Jasmine Tsai
Clover Health Senior Software Engineer
Jasmine worked in investment banking and consulting after graduating from University of Pennsylvania with degrees in Economics and International Relations. She was always itching to create, which led her to Hackbright Academy! She’s now a Senior Software Engineer at Clover Health, improving health outcomes for the elderly & low income.
By Jasmine Tsai (Hackbright Academy alumna – spring 2013 class)
Toxicity is a big, alarming word. This is why I was hesistant to use it for a long time. It seems to suggest a baseline of cuss words, blatant discrimination, negligence or incompetence. It also seems like a particularly big accusation; after all, the word “toxic” has such an electrifying edge to it. I’ve come to believe that it is actually nonetheless possible to have toxicity breed among a perfectly otherwise nice, reasonable group of people.
That’s the most important thing I’ve learned with regards to toxicity thus far: it doesn’t need to imply great evil or even utterly apparent dysfunction in a team. It most certainly does not have to mean that the people involved are fundamentally a*sholes. Although all of the above can be true too, at its most innocuous it simply needs a certain level of carelessness and apathy to thrive.
First, let’s define toxicity. We could try to define this with examples, but that’s boundless and not instructive. To me, toxicity is apparent when an environment regularly takes away your energy to be productive or enthusiastic. This could come from fear, but it doesn’t even have to. We do not need to quantify “just how much” energy it takes away. The bottom line is: if you regularly feel more sapped than energized by your environment, it is probably somewhat toxic.
A lot of toxicity, especially in the tech & engineering world, comes from social factors through gender or race discrimination/micro-aggressions, whether or not intentional. Those are big and real things, but not the issues I want to discuss here because they can fill a whole other post of their own. Instead, what I want to talk about is the core friction and conflicts that arise from doing engineering work.
Hypothesis On Why Toxicity Arises
There is a particular kind of pain (and perhaps, joy, to not be so cynical) that is only known to software engineers: the inevitability of having to work on someone else’s code (whose design you disagree with very much), and to have your code eventually be worked on by others (who will almost certainly disagree with you on something). That is the price of being able to do something cool: to be able to build solutions that replicate themselves and run for an extended period of time.
There is almost no other profession like it. Many professions’ “final-products” are more or less expected to be in a fixed state, whose process and source are treated as disposable after the product communicates its value. Think about all the emails that you wrote which proceeded promptly to heaven.
But not engineering. Not only are you expected to build something complex in a present state, you should also, to at least an immediately protective extent, anticipate the complexity in the future. Working in a codebase is like being mired in a time machine, having to battle mistakes of the past, deal with constraints of the present, and also intelligently mitigate the future. Trying to build this “intellectual fortress” can be challenging work that sometimes feels impossible, and probably is impossible to “get right”.
That kind of mental anguish/taxation, I believe, lends a stage to much of the precursors of toxicity. All of which I have taken part in, one way or another. First — there is the pride that creeps up simply because you have devoted much time and thought to it. It takes conscious effort to battle that when it does not always manifest itself consciously. The effect of pride is both an event and a cumulative process. Over time, it can teach one to believe, falsely, that they are always likely to be more correct than others. Second, there is the impetus of that frustration which lends itself to quick and “justified”-feeling responses, however unjustified that may be. Both of these instincts are easily riddled with insecurity.
What Does Innocuous Toxicity Look Like?
Again, overtly toxic behavior is terrible, but I almost think that those things are easier to pick up and label as “wrong”. That is not to say it’s always easy to stand up against them, especially if you are in an organization that is poorly managed and riddled with fundamentally misaligned beliefs.
But what I really want to talk about is the insidious stuff: the stuff that you feel like you can’t quite put your fingers on. The stuff that you feel like isn’t quite right but you feel like you might be pesky just for bringing it up, or that you feel like you should almost let it slide because it seems utterly human and therefore should be forgotten.
I’ve come to believe otherwise. “Innocuous” toxicity is just as toxic, especially over time — it differs from the truly horrible stuff because it offers no mechanism of dissociation. It feels hard to simply write a certain person or behavior off because “it just doesn’t seem bad enough”. Yet in the mean time, it is taking away just as much of your energy and preventing your growth.
I am talking about: the casual eyerolls when someone mentions “some bad code somewhere”, or the mention of a person’s name whom for some reason the team has agreed as “having a certain style” (code for bad); the talking behind someone’s back about the code they wrote; the quick equating of someone’s ability as a competent engineer to solely their code; the quickness to point fingers at someone almost as a victory when something breaks; the public shaming when you disagree with someone or believe that they are doing something wrong.
These things often feel like you are doing the right thing: you are the guardian of quality! the loud advocate of correctness! But in fact you are just doing the easy thing. It is easier and feels gratifying to point out someone else’s mistake; it is seriously debatable whether that gesture can count as “teaching” and will result in better code over time. In fact, as a result of fear many people are much more likely to stop really asking the questions they need to ask to grow.
All of these things are not exclusive to engineering. They can happen just as much elsewhere. Other forms of toxicity are endemic to other industries. Still, none of that negates the fact that we have some work to do.
How To Battle The Seeds Of Toxicity?
First, stop doing these things yourself. I will be the first to admit that I’ve probably done many of those things, because it made me feel like I got to be part of a club. I felt such an inherent anxiety of being judged (and feeling the high probability of so given what I had witnessed) that I sought to gain a false feeling of protection by judging others. In the end, it really only made me a terrible person, and delayed my own growth because it reinforced my fear in failing. Except for those that I know very consciously try to mitigate this impulse, I have seen engineers at almost every level do this. It’s a thing people really like to do.
Strive for a truly blameless culture. Not just blameless postmortems when things go wrong, but blameless day-to-day. If you are worried about that leading to laxness, I say that humans are more intelligent than that and there should be a way of instilling caution in people without demoralizing fear. If you feel like something could be better, please take the time to teach other people and explain it. I believe that a team should be collectively responsible for each other. There should be a clear sense that growing as a team as a whole shifts the whole curve up.
It’s good but not enough to be simply “blameless” — that can just easily become an interpretation of utter apathy. The pillar of that blamelessness is support. Support via teaching. Support via active mentoring. Support via actually being supportive and generous in your tone and approach. Support via showing that you are willing to invest in someone’s long-term technical and career development. When you hire someone, start with the assumption that they are wildly competent rather than making them prove so; answer their questions without penalizing them.
Get there by playing your part: being a person that doesn’t casually roll the eyes or point fingers victoriously, a person that believes teaching others is what pushes both you and them beyond the local maxima. If you are a leadership figure, take the extra time to voice those values to your team; find out how your team is really feeling, especially because these things can be so difficult to pick up. So much of blame is a habit, often of insecurity. Find out why your team feels a certain way, find out why you feel this way.
This blog post was originally posted at Jasmine Tsai’s blog.