Very often we get things wrong, and nobody likes to have faults pointed out. I live in Britain now, but I’m not that “stiff upper lip” kind who will just trudge along through a failure. In my second job in the UK we have an annual “events” company from the USA come and try to stir up some excitement. A thing that British people never truly are “public at” in expressing either joy or disappointment. Not being British, I find I am allowed to celebrate more, and this means celebrating my victories, and my failures as chances to learn. Anyway… This “events” company from the USA had a funny idea though, celebrate your failures. Probably a bit like Thomas Alva Edison did, using them to learn from mistakes. The popular story goes, that he had to fail at making a working lightbulb 99 times! You can see I am looking for a way here for us to all see failure as a positive thing.
This week I failed. And I’m only sharing it because I think people need to know that even if you have been in Software for 30 years, you will make simple mistakes. Don’t let it get you down, rather use it as a chance to share. OK So what did I get wrong?
I was asked to re-test a thing that I had tested a week ago when the devs actually fixed the bug. So because it’s a lot of setting up of other bits to test this I took a long while setting up all the bits of tooling, and completely forgot to update the test machine to the latest build.
Second guessing myself. I had already tested this, there was no need to test it again, but the person asking me to testy again was on holiday last week, so I was humoring them. Sometimes there is nothing wrong with re-testing.
I find the original bug, that was fixed, but because I’m not paying attention I log the different broken behavior in a new Jira. I’m tired and distracted now and after a 2 page long Jira showing the original bug, but just in a slightly different perspective, I start letting people know, maybe we have a problem.
Come home-time, it finally dawns on me that I had the wrong build installed on the test machine. It’s actually more humbling and embarrassing for me than what I just described. But I figured, this must happen every so often to others. Let’s not kick ourselves, but lets remind people, it’s OK to fail, just, do it with grace. When last did you fail and learn to be just that bit more diligent when raising a defect ticket?
At first, glance Celebrating Failure seems like some cringe that HR came up with, but in reality, it can literally happen to anyone to screw up big time. My recent biggest failure was in my last job, where I was supposed to compare some business-critical data (coming from two different sources), to make sure it was consistent, it was time-sensitive and I misunderstood what I was supposed to do (I slept poorly a few days prior to that) and I just did half of the work thinking I was done.
Personally, I think highly of people who are not afraid to admit and own their mistakes, for people who claim that they never make mistakes I sincerely doubt their honesty.
Cool concept and thank you for sharing. I will change the format only slightly:
This week I learned that I should read the instructions a more carefully before trying to fix things that I am unfamiliar with, otherwise I might cause permanent damage
A few side notes, during the recruitment process we always asked people to share a failure and a success, and the main thing we looked at was how they used we or I in those situation. Like I worked in a project and everyone else was so bad so I failed / the project failed. Or I made a mistake which caused a failure. And for success, I did this so it was great vs. we succeeded with this. Own your failures and share your successes.
Also we have a saying in Sweden “One time is no time, two times is one time too many.”, basically we all make mistakes, the important part is not be afraid of making them, but to learn from them.
Can definitely echo that saying about “once is a mistake…” , and how that reinforces the taboos around failure. So much so that if I get asked this kind of question in an interview, I once replied with, “do you understand how asking this innocent sounding question in an interview oversteps the boundary?” and went on to share a short pre-rehearsed response, which I hope they found helpful. But, to be honest, the world is changing and companies want to hire people who are flexible. So we need to expect this kind of interview question. And I guess in that @ola.sundin you have pointed out something for me to takeaway too. Dealing well with failure is a superpower, while not using chances to learn from an experiment that might fail is perhaps a weakness.
When I get the interview question about failures I have plenty of situations to talk about - I usually discuss one of the complex projects where the team was missing crucial information and didn’t find out in time for the project to succeed, then go into what I’d do differently if a similar situation should arise.
I usually also mention that I rarely make the same mistake twice, but there are infinite ways to make mistakes so I’m always learning from my mistakes.
One thing that does help for those who aren’t stuck in a toxic work environment is to own your mistakes when they happen and apologize for them. Then offer suggestions to help prevent it happening again.
I hit that one the last couple of weeks: in preparing the list of user stories that were targeted for deployment, I managed to miss one. Nobody else caught that I’d missed it, so we deployed without a critical change to functionality that one of our biggest customers was expecting. Once we found the thing, we had a mad rush to get the change and data cleanup deployed, followed by working out what we could do to prevent another case like it. I admitted that I had no idea how I’d managed to miss the user story in question, and offered a couple of suggestions to help prevent it happening again.
This is actually an area that I try to implement in teams during retrospectives. Identifying something that need to be improved or changed is not super useful without coming up with a good strategy to actually implement it. So by having sensible Definition of Ready and Definition of Done for instance allows you to say for the DoD checklist add this item. Like “Code is reviewed” instead of just saying “We should review code more”.
