As developers, we all make mistakes, irrespective of our skill level. What differentiates us is our ability to take ownership and learn from those mistakes. Introspection is a critical skill that will help you grow personally and professionally. This article is about a time when I made a mistake, reflected on what went wrong, identified points that needed improvement and developed better habits and skills.
Oops, I took down the production pipeline
Recently, I made a mistake at work that took down the production build pipeline for a few hours. The production environment was unaffected, but I blocked new deployments. What happened? I was working on updating our GitHub Actions workflows to use the latest version of some of our marketplace dependencies. A few of these dependencies were deprecated, so I had to rewrite those locally, using the public source code of the deprecated packages as a reference. I made the changes, tested them locally, and pushed them to GitHub. But I was rushing the process. Feeling over-confident, I was trying to finish by the end of the day - I was due for surgery soon and I wanted to complete this task before going on leave.
After the incident, I took a look at what went wrong and what I should have done:
- I was over-confident in my knowledge of custom GitHub Actions and rushed the changes. I should have taken my time and carefully reviewed the changes before submitting a PR.
- It was not deadline critical, so I rushed for a personal reason instead of a professional one. I should have communicated my situation to my team and asked for help.
- Testing GitHub Actions workflows is impossible locally, I thought. I should have researched and found a way to test the workflows locally. It is possible.
- My team approved my PR, so it was not my fault, right?! Wrong. My team trusted me to have the code at a certain standard. They look at the bigger picture of the PR, not the minutiae.
- I did not take a change in the production pipeline seriously enough.
Why admitting your mistakes is a good thing
I was feeling pretty bad about the whole situation. We had to roll back my changes, and my team spent the next few hours fixing the issue. I took full responsibility for the mistake and admitted it to my squad. I did not try to blame anyone else or make excuses. I owned up to it, and I learned from it. I also apologized to my team for the inconvenience. Our company has a core value of owning your outcomes. I took that to heart.
It is imperative to take ownership of your mistakes. It shows a willingness to learn and the ability to take responsibility for your actions. It is difficult to admit our failures because we fear reprimand or punishment. We worry that it affects our performance reviews or our chances of promotion.
The opposite is true. Yes, you did something that will affect your reputation, but things happen. Do you know what else people will remember? That you own not only your successes but your failures too. It shows them that you did not try to blame something or someone else for your mistake.
Learning from your mistakes
You successfully identified what went wrong. Now you must learn from it. Take the time to reflect on what happened and why it happened. I like to do an autopsy or post-mortem of the situation. This process can be done on your own or with your team.
When reflecting, be honest with yourself and identify the following:
- The root cause of the problem
- What events led to the problem
- What could have prevented the problem
- How do we avoid the problem from happening again
- Mitigation steps if the same issue arises again
When doing this process with your team, additionally identify:
- Which oversights in your process allowed the mistake to happen.
- New steps in the said process to prevent a repeat occurrence.
Throughout this process, be specific about the details, from analysis to solution. Do not use this opportunity to blame or punish team members. Focus only on the outcomes of the autopsy.
Philosophy of self-reflection with failure
Taking the time to perform the act of self-reflection is a valuable discipline for personal growth. Professional sports and eSports players are great examples of this. They are constantly reviewing their gameplay and looking for ways to improve. They probably play fewer games than you do because they spend more time reviewing their gameplay than playing the game.
Failure is not only a part of life. It is a part of learning. You stop falling off your bike when you fall off enough times to learn how not to. In the words of Jake the Dog from Adventure Time:
Sucking at something is the first step to being sorta good at something.
Being candid about my mistakes has allowed me to receive constructive criticism and dramatically increase the amount of knowledge gained from my peers. All it required was shifting my mindset from seeing mistakes as a possibility of punishment to seeing them as an opportunity for learning.
It is this mental shift that accelerated my career growth beyond normal levels.
Everyone will drop the ball at some point in their career. It’s how you handle it that sets you apart.
Will you brush it under the rug and hope no one notices, or will you clean up the mess and take responsibility for it? Do you cling to your pride and refuse to admit you were wrong, or do you learn and let it go? Do you point fingers at others or point them at yourself?
Although it’s often uncomfortable, I hope you choose the latter of these questions. It’s the only way to grow as a person and professional developer.
Shane Parker is a software engineer from Cape Town, South Africa. He specialises in front-end development and human-centric teams. When not working, Shane plays games with his friends and enjoys exercising and relaxing with loved ones. He co-founded Sitestack and Lineage Systems and currently works for GoDaddy Inc.
This article is also featured on Shane’s website.
- How I Learnt To Fail Gracefully
- How Senior Developer Renaldo Meere Learns by Trial and Error
- How We Use the 5 Whys to Learn from F*ck Ups at OfferZen
- How I Used Technical Assessment Feedback to Ace my Developer Interviews