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
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
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
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.
