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?
This post was originally published on the Coding with Empathy blog
Top comments (24)
Now more than ever, we need to model and demand a culture of courtesy and mutual respect. Thank you for your article.
To reinforce what you're saying, those who equate courtesy and respect with not providing feedback and not requiring quality are not being constructive or logical. It's always good to be nice to others, especially when disagreeing and criticizing.
There are many who cannot be bothered with behaving respectfully. They are usually deaf to any arguments otherwise. When choosing my employers and clients, character issues like this are at the top of my list of factors on which I base my decision whether or not to join them.
Regarding 'git blame', there is no need to add an alias; 'git annotate' has always been a synonym for 'git blame'.
Please continue to focus on the human factors in our field. Happiness in the workplace is such a large part of happiness in life. It's great when people like you care enough to examine and nurture it.
Well put Keith!
Thanks for letting me know of "git annotate".
Be well
To be honest, that's not a bad thing. A diva coder will fail projects even harder. Strengthening of character is what we really need here, because there is a new wave of sociopaths (fresh from overly protective parents) coming to the field, and if we'll succumb to the ways of safe spaces in programming - all but is lost.
So fuck it, your code is shit, you need to do better.
@smoke fumus, By Diva coder I assume you mean a person quite early on the Dunning Kruger graph (wrote a little about it here: codingwithempathy.com/2016/09/20/e...), where they have a limited skill set, but a high level of confidence / arrogance.
You are right that these individuals may have a negative effect not only on themselves and those around them, but also for the projects they work on. I also agree that firm guidance is a good way to help these individuals realise their limitations and potential.
Which brings me back to the conclusion in the article, where there is a plea to the senior developers out there to mentor and train individuals. Guide and lead the way. We don't have to be dicks about it, but we can be direct and candid with our feedback. Be harsh with code, but kind to the coder.
Be well
sometime later meanwhile in google spinless socipaths taken over and google fired an employee for "wrongthink". So yeah, I think i was right all along.
To also paraphrase Uncle Bob, we have a social responsability and an obligation to not release crappy code into the world. Is the day that a bad program becomes responsible for loss of human life the day where we'll finally realize the importance of it all?
I remember the whole culture of shaming as being a sort of noob thing that people go for, that one tends to grow out of as one becomes more secure in their abilities. Remember shaming being such a big thing as a student, with parroting of the likes of "comment why not what" etc etc. One place I worked at had a "dozy duck" which you had to put on your desk whenever you broke the build. These days I see that sort of thing as a bit of a red flag. I've worked with a few really good devs these past few years and none of them bother with that sort of thing.
Yes, there is a natural progression when it comes to maturity and self-awareness about ones skill, and expectations placed on others.
Nothing beats working with experienced developers that understand the trade-offs of decisions, and also when to make those trade-offs. Add a culture of mentoring / knowledge sharing and you create a wonderful atmosphere for others to thrive and grow.
Glad you've found some good people. Maybe you can create feeling for someone else when you get the oppportunity? :)
Have a great day
-Pavneet
Yeah absolutely. Also, another consideration - devs might have young children wearing them out and making them juggle, or maybe they're working their way out of debt, perhaps they're recently divorced, or working from a shack somewhere in a high-risk neighbourhood with a crap internet connection while feeding their parents, who knows. Not every dev's working in the Valley with good paychecks, healthcare and free lunches.
I dig what these guys are doing BTW, setting a good example - any devs building VR apps, who don't have the equipment, are welcome to come to their office at certain times to use their VR gear: binomial.info/
Interesting read, but I don't share the opinion. Being assertive is a very hard skill to attain, most junior devs don't get proper feedback and are left to fail alone. Feedback early is important. I would rather have a broken CI build or a bad code review than a bug in production.
If this industry needs something is more feedback before shipping.
I agree that bro culture don't help but I never heard of stuff like wearing a hat for breaking a build. That's what git branches are for, to experiment and break the build before it affects others. And code reviews are still not that common in the industry.
Not doing ttd won't make you a bad developer, no one ever said that, but it is funny that you quoted Uncle Bob, who defined a very good list of code smells. Whats more shameful than saying that your code smell? He's also a big advocate of TDD btw.
@cthothubo , you are quite right with your observations that practices that uncover bugs / inadequate code before it reaches the end user are essential. Short feedback-loops are important. The angle here is that there are good and bad ways to give that feedback. If you follow the link to "candid feedback", you'll understand what I mean.
You are also right that it is a very hard skill to attain, something that Andrea Goulet speaks about when she says that "Communication is just as important as code": codingwithempathy.com/2016/07/19/v...
In regards to breaking the build, I've haven't personally experienced the hat, but have heard of that and similar techniques. Quick google uncovered this: mindfulhacker.com/who-broke-the-bu... .
Code smells are shaming of code. Not people. There's a difference. Be harsh with code, but be kind to the coder.
Be well
-Pavneet
Thanks for this article, I found it really interesting and a lot of it rang true with respect to things I've seen in my own experience. In particular, I've been banging the drum for respect in the code review process for a good while - making a similar point to you, which is that since the code directly manifests from the brain of the developer, it's all too easy for thoughtless criticism to become personal.
Thanks for writing this. I'm developing a conference talk about "not losing our temper with newcomers" on Q & A sites and other places - very closely related to your topic.
That sounds wonderful. Best of luck.
Where are you planning to hold the talk?
I've submitted to PyCon, will probably give the talk at least one place even if PyCon doesn't want it!
Great stuff!
Would be awesome if you could keep in touch (@pavsaund on all social media) and let me know how that goes.
Good luck!
-Pavneet
Are you sure? Why is it "nothing wrong"? It could be like this or it could be just brilliant and it could be very wrong and be working with enormous effort of support people and developers that inherited it. This cannot be justified by the fact it is delivering value because the costs of maintenance for this code could just be too high. It can also create impediments for further development of the business since it is, for example, hard or impossible to change.
So, how all this makes it "nothing wrong", is it just because you want to show your respect to the people who wrote it? You can respect them and still point out that the code is wrong and must be fixed, otherwise the business is badly hurt.
I think imposter syndrome plays a part. If I know I'm a mediocre dev, and all these other developers need help from me, they must be terrible, right? In reality we're all where we are because we're good and we're all improving all the time.
Assuming other are acting with the best intent in mind has helped me greatly. As well as dealing with my own Imposter Syndrome. My personal experience is that being aware of my limitations, and also my strengths is important. Also being mindful of when my mind starts to wander and keeping away from judgemental thoughts have been valuable.
At the end of the day though, the simple act of blogging, creating and doing things in public has had the most profound effect. Nothing beats negative thoughts than just putting in the work. Then you know where you are :)
Here are a few links you may enjoy.
codingwithempathy.com/2016/09/20/e...
codingwithempathy.com/2016/08/30/a...
codingwithempathy.com/2016/03/15/u...
Be well
Great article. Thanks a lot! :)
Glad you enjoyed it!
Be well,
Pavneet