Developer growth, Practice Empathy

Rituals of Shaming in the Software Industry

The career of being a software developer can be a bumpy one. From the very start you are challenged by technical challenges you have no idea how to solve. Some grasp the concepts and principles easily, while others struggle. It’s an uphill climb of continuous learning. Constant failure, and success just a semi-colon away.

One of the biggest challenges during this process isn’t technical, but rather social. Around each turn you uncover new wonders, and new challenges. When you start a new job or position, publish a blog post, submit a pull request or even make a product. There will be people lined up to tell you how wrong you are and as a result; how you’re not good enough. I’m here to tell you, that you are!

I am no expert in shame, empathy, or vulnerability, but I have a voice and a channel to raise awareness. Please keep this intent in mind while reading.

Shame & Guilt

Guilt and shame are two sides of the same coin. They spawn from a similar place, but have completely different results. Let’s get into definitions.

Guilt: The fact of being responsible for the commission of an offense; moral culpability – The Free Dictionary

Shame: A painful emotion caused by the belief that one is, or is perceived by others to be, inferior or unworthy of affection or respect because of one’s actions, thoughts, circumstances, or experiences – The Free Dictionary

In other words: Guilt is feeling bad about what you do. Shame is feeling bad about who you are.

Guilt is something that you can relate to and learn from, where as shaming is something that can make you question your self worth.

Across software development, shame & guilt are used as a powerful and destructive forces. Developers argue and speak condescendingly on social media , Q&A’s and other online arenas. They hold others to extremely high standards and let them know when they don’t meet them. They also make sure to not only let you know that not only is your work not good enough, but how you aren’t either.

Rituals in the Software Industry

Breaking the build

Breaking build shame rituals.jpeg

The norm is to have some sort of continuous integration (CI) or deployment setup (CD) for software projects that monitor every checkin that developers make. The CI process usually builds and runs tests on the resulting build artifact to verify its integrity at different intervals.

Many teams have some sort of ritual where the developer that committed a change that broke the build get called out publicly. Perhaps on the team chat, or perhaps you need to wear a funny hat or costume.

Being called out as the person who broke the build can be unnerving. It may be fun once or twice, but when it becomes a game of finger-pointing then that’s when you start getting defensive about it. Perhaps you start becoming really defensive about how you code?  Maybe you get so defensive, you stop wanting to learn new things? Maybe when the next person breaks the build, you can jump on them and call them out?

A young developer may be devastated by the focus on not breaking things and miss valuable opportunities to learn. Here’s a story reflecting this: “How to apologize when you have broken the nightly build“.

Pull Requests & Code Reviews

wtfm

With any pull request or code review you’re presenting your work for others to evaluate and give their feedback. The problem is when the code review is used as a gatekeeper function, and is governed by senior developers that mandate standards based on their own preferences. Review comments could range from anything like “I’ve never seen this much crappy code in my life” to “Not good enough”.

I’m all for candid feedback, but when a developer get’s harassed when they submit code then you are shaming them. Also, since the work being reviewed is directly produced by the developer it’s so easy to connect that “they are bad developers”. Totally missing a learning opportunity.

If you don’t do X, you aren’t a good developer

Software development is a field that’s moving extremely fast, and so many are struggling with fatigue from trying to keep up. On the one had there are so many programming languages. On the other hand, there are so many techniques and practices to be learned.

“If you don’t do TDD, you aren’t a good developer” – Some developer on the internet

When you then combine this plethora of choice with statements that indicate your value as a developer is sub-par based on things you don’t know, then that’s just adding another layer of shame to equation.

Legacy Code

Many developers believe that legacy code is something of waste, to be ashamed of and avoided at all cost. So any code that has been around for a certain amount of time and may or may not have tests around it becomes legacy. What attitudes like this indicate is that you are shamed into believing that legacy code is bad, and it can then be used as warning.

“You don’t want to write legacy code now, do you?” – M.Scott Ford (speaking about shame)

There is absolutely nothing wrong with code that has been, and is delivering value in production. It may not be easy to understand, but what makes you think your code will be understandable for the next developer in 5 years? Actually, will any of the code you write even be live in 5 years?

In our tools – git blame

Even our tools carry a negative tone with them, like git blame. Git is a wonderful versioning control system that allows you to make wonderful software in distributed way. The commands are simple, yet powerful and there seems to be a way to do almost anything with the tool.

One of the commands, git blame, is especially useful when trying to figure out who wrote a line of code. The problem here is the wording.  You are assuming the mindset of blame before even speaking the developer that did this. Perhaps speaking to the developer is your next step, you then take with you that “blame” in the back of your mind. This in turn could change the mood or tone of that conversation. It’s just a word in a tool, but the word itself has weight.

Diversity

There’s a lot of focus on diversity in the tech industry in both positive and negative ways. There’s a long way to go still, though. When reading articles on why people are quitting the technology industry, it’s easy to think that “they weren’t tough enough” or “they were just complaining”.

The chances are high, that people from a typical minority background are already carrying shame with them before even entering the industry. When met with the exclusive culture above, there’s no real surprise some decide to leave.

Extinguishing Shame with Vulnerability

Human connection

Dr. Brené Brown is a shame & vulnerability researcher, who has spent years digging into these difficult topics. She’s taken her findings and shared them in her books and TED talks.

According to Dr. Brown, shame cannot survive when doused with vulnerability and empathy. Being vulnerable, open, honest and caring are ways to reverse the effects of shame. Allowing for deeper human connections.

It isn’t all bad

I’ve painted a rather bleak picture with the negativity that is in the industry, but there is a lot of hope as well. Diversity and inclusiveness are in the wind, and empathy, compassion and workplace happiness are hot topics these days.

There are podcasts that deal with the non-technical aspects of being a software developer, like Developer on Fire>Code (Greater than code) & Developer Tea. Companies are putting empathy at their core. And there seems to be a certain amount of people allowing themselves to be vulnerable and share their story.

It could be that this is how I experience the general message in my echo-chamber, but there’s certainly a lot of room to improve.

Finally

I am no expert on this matter, but rather a person who has travelled the spectre of shame and vulnerability. I encourage you to check out the work of Dr. Brené Brown.

Many developers develop “tough skin” to be able to get by or even strategies to avoid conflicts. Others are fortunate enough to be part of teams that don’t embrace shaming. At the end of the day it’s about trust and building relationships. When you have trust, then you know where the individual limits are.

We should do better. The number of junior / inexperienced developers in the industry is a lot higher than senior / experienced ones (overheard from Robert C. Martin somewhere). Meaning there are a lot of learnings when it comes to attitudes and mentoring that don’t get passed down to younger generations. We need to improve as an industry to raise awareness on the importance of respecting the individual.

We can all take small steps to reduce shame in our daily work and lives. I know I can do better. How about you?

I hope you enjoyed reading this post. It would mean a lot to me if you shared it with someone else that may benefit. Leave your perspectives, stories and experiences in the comments, or reach out to me directly.

 

  • Thanks for writing that 🙂
    It’s nice too read other people’s concerns about the thin limit between honest feedback and shaming.

    • Thanks @davinov:disqus.
      Giving feedback is hard. I like to think that be honest about both your intent, and reflecting over the type of feedback you are giving will help. But mistakes will happen.

      I guess the main issue is that many don’t have the approach of caring about the other person enough to worry about the impact / context of their words. Which leads to brutally honest feedback that can sting a lot more than help.

  • DataArtist

    Thank you for this article. Very nice! Question: How do you find distributed teams versus face-to-face teams differ in regards to this topic?

    • @disqus_LJJt0IH2po:disqus:
      To be honest: I don’t think that plays too much difference, initially. The main factor is the company / team’s culture, and how distributed teams are organised.

      There is the danger that when you don’t see people you work with, and a company culture that doesn’t proactively work towards bridging that gap. Then it can become an us vs them mentality and things can spin off.

      To be honest, though, I’ve only had positive experiences with distributed teams, where teams are spread across locations, but within the same time zones. 100% Co-locating teams may work to reduce friction of communication, but that also means not being included in the work and development culture. It would then be a sub-culture. Or even a completely different one.

      As with any collaborative team culture though, it takes effort. And the distributed variant also means adding a healthy dash of proactivity, and healthy positive intent when interpreting any form of async communication (emojis and animated gifs convey A LOT of feeling to a boring sentence).

    • Gjermund Gusland Thorsen

      I believe the success or failure of communication in distributed teams vs face-2-face comes from their ability to communicate; by communicate I mean through frequency, energy and vibration; in other words at least some of the distributed teams’ PICs will have to meet to establish good communication patterns; through a meal or playing squash, it does not have to be hierarchical leaders, this could be people working on communicating platforms in which are key to the operation. This I believe can only be done face-2-face. Just like facebook is an asocial media platform people you have met face-2-face are much stronger in their ability to communicate after meeting. Text messages between people you have not met are just text messages, while text messages with people you have met is much closer to actual communication.

  • Pingback: Professional Development – 1/09/17 – 1/15/17 – The Software Mentor()

  • Gjermund Gusland Thorsen

    I believe this is also about sexual polarity in a world that is turning more metro sexual by the day. David Deida wrote good books on sexual polarity( and maybe still does; )
    the ability to give point and direction in life is masculinity, while being able to receive point and direction is femininity. Hence only the metro sexual man is able to receive shaming. While the masculine man will filter “the shaming” as inspiration or hoax
    within seconds.

    These are my personal interpretations; can prove wrong for some right for others.

  • Pingback: Professional Development – 2017 – Week 3 – Geoff Mazeroff()

  • Leena

    Thank you for writing this. All points are relevant. Yes, one can be compassionate and opinionated at the same time.