Todayās task is to reflect on a career-related failure and the lessons you learned from it. Failure is a typical part of any career journey. While failure feels discouraging, itās often a valuable opportunity for learning and growth. By sharing your experiences, you can inspire and support others who may be facing current or similar challenges.
Task 26
Reflect on a career-related failure: Take a moment to reflect on a specific career-related failure or setback you have experienced. It could be a project that didnāt go as planned, a missed opportunity, an error at work, or any other challenge that you consider significant in your professional journey. Consider the impact it had on you, both personally and professionally.
Identify the lessons learned: Think about the lessons you learned from the failure. What insights did you gain? How did it change your perspective or approach to your work? Did it lead to any personal growth or skills development? Reflect on the immediate lessons and any long-term effects on your career trajectory.
Share your story: Reply to this topic to share your career-related failure and the lessons you learned from it. By sharing your experience and the lessons learned, you can help others facing similar challenges navigate their own journeys more effectively.
Support and learn from others: Engage other community membersā posts by offering support and encouragement. Share your experiences and insights to help others and grow yourself.
Remember, failure is a natural part of any career journey. By sharing your failures and the lessons you learned from them, you can inspire others to navigate their own challenges and gain resilience and adaptability. We encourage you to complete this task and engage with the community to create a supportive environment for everyoneās career growth.
Why complete this task?
Self-reflection and personal growth: Gain deeper self-awareness, identify lessons learned, develop new strategies, skills, and perspectives.
Learning from experiences: Inspire and support others, foster a sense of community, promote a culture of learning and growth.
Building resilience: Acknowledge and discuss setbacks, demonstrate that setbacks are not permanent, encourage bouncing back stronger.
Career advancement and success: Demonstrate growth, resilience, and a willingness to learn, enhance professional reputation and opportunities for advancement.
Emotional well-being: Let go of negative emotions, embrace a more constructive mindset, promote self-compassion and acceptance.
During my first months as QA Engineer, I checked simple login validation for a banking web app. It turned out that I missed a pretty obvious bug. The bug was that if you use the correct login with an incorrect password, it only showed info about the incorrect password. Given that fact, the login was a userās mobile phone - the bug could lead to a massive enumeration of those phones to attackers. Lesson learned: ask peers and your lead about findings and get feedback.
When I was asked to teach QA Engineer with automation skills I did not clarify with their managers the end goal of this endeavor. As a result - people got their knowledge but did not get time for automation. After some time - all skills were successfully forgotten. Lesson learned: set clear expectations with management and ensure your time and the companyās money are not wasted.
Once, I used Gatling for performance testing of gRPC services. After getting the first nice and fancy reports - I realized that it might be wrong (because no matter which load I used, all the responses were more or less at the same latency). So I dig a little bit deeper. And it turned out that our gRPC services always responded with 200 OK, and only inside the response was info on whether it failed or not. Lessons learned: Learn the technology before applying the tools.
Nothing is a failure if you learn lessons from it and donāt make the same mistakes.
When I was asked to mentor someone I thought just doing my part of the job is all about it.
As a result, the mentee ended up performing poorly. When I reflected back I understood that I just did things my way without hearing to their perspective.
We later sat down and corrected a lot of things and now its sorted.
I havenāt work yet as a QA tester/engineer so, iāll express my experience in the field of web development as a freelancer.
The majority of my failures had to do with the bad estimation of the clientās requirements. I mean that in some cases i started a project in which i wasnāt able to complete some of the requirements because the technical expertise and the related experience that i should have. The lesson i learned is that you have to consider your skills before you start a project.
About nine months into my Quality Career, I joined a new team working with technology I had never encountered before. One day, while testing something with a third-party integration, we decided to route our PRE environment to their LIVE environment. It didnāt seem too risky at the time, as we didnāt think about the potential consequences. Unfortunately, neither I nor my team thought to check we had switched back the configuration to stop PRE from directing to LIVE. It wasnāt until several weeks later that we realised our mistake. How did we find out? Thatās a funny story for another time.
This experience taught me the importance of speaking up and asking questions when unsure about something or its consequences. A lack of understanding is not a sign of weakness but great self-awareness. Since then, I have been asking questions more frequently, especially when I donāt fully understand what is happening. This experience made me feel like an idiot at the time, but I grew in confidence, ultimately giving me the agency to shift left.
When I was at college, I had a module on programming. It was Pascal, and I thought I was pretty good at it.
A friend of mine said his employer was attending a jobs fair, and I should go along and see what roles they might have for me. The production manager suggested I apply for a junior dev role working in their R&D team. I applied for the job and was successful (probably because the salary was so low, and Iād been put forward as a recommendation).
It was a baptism of fire. They developed embedded software which was written in C, and compiled in Hitachi workbench then flashed to an EEPROM. Turns out, I was not a dev.
I spoke to my awesome manager (a doctor of astronomy) who suggested I try testing the software in the instrument instead. I came up with a crude test plan in Word, run it past him, then took to testing the instrumentation. I spent the best part of 7 years doing this, refining my test plans, ensuring traceability, issuing software updates to production, etc.
So in a roundabout way, I fell into testing. I was seemingly bitten by the bug, and here we are 26 years later and Iām still testing software.
Why Do We Fall, Master Bruce?
So that we can learn to pick ourselves up, Alfred.
A story about a team failure is described in the below post. It was probably something unavoidable given the circumstances.
One of my learning stories is about listening to my intuition and not turning away from my heartās calling. After university I went on several job interviews. I really liked one of the jobs, but I didnāt get an answer from them, so I took another job where they were very happy with me, but I had serious doubts about the job description. From the first few days I felt like I was drowning. After a week I got a reply from the second company that I had won the interview. I felt really bad that I was leaving so soon and that they had already invested in hiring me, but I couldnāt help it. But before I signed the contract in the second company, the job was cancelled and I was left without work.
After years, I found myself in the same situation from the other side. I was hiring for my team and I hired a tester who wanted to be a developer, but finally we agreed that she would start as a tester. She had serious doubts and it went badly.
So my learning is to listen to my inner voice and also respect others when they listen to it. It can save a lot of trouble for everyone involved. Now I would not take a job if I really felt bad about it, and I would also think about how a company would behave if they took too long to answer.
āWhy donāt we just ask Phil?ā I said with confidence.
This was probably the fourth or fifth time Iād said this to my developer colleague after the two of us couldnāt work out what was going wrong with yet another bug Iād just found.
The developer flipped out.
āWould you stop saying LETāS SPEAK TO PHIL!!!ā and they speedily walked off, clearly p*ssed off with me.
I went bright red and immediately felt terrible. I had absolutely no idea how my innocent request would make the person in front of me feel. I hadnāt considered the impact it would have on this developer for always defaulting to suggesting we speak to the most experienced developer. All I could think of in my mind was, āWell, we need to get this fixed, how can we go about doing that?ā.
After about an hour I asked the developer if we could meet in a meeting room away from the office. They agreed. I apologised and explained that I hadnāt ever considered their feelings and what impact my request might have on them. That all I could think of was for us to find a way to fix the bug.
They understood my mistake and accepted my apology.
It was an important moment for me. Iāll never forget it.
It switched on an empathy chip for the rest of my career.
My first line of code was written in Pascal! I enjoyed the coursework, but didnāt take another coding course for 25 years when I joined a bootcamp and worked with JS.
My largest tech career failure was not getting the hang of any JavaScript libraries. I enrolled in a coding BootCamp in 2020. Things started off well enough, but I hit a brick wall when we began learning JQuery and React. I felt completely out of my depth in an environment that was sink or swim. In addition to our 10-hour days, I took supplemental coursework, sought out tutoring, and set up an aggressive study plan. By the end of the module, I was completely burned out and no closer to understanding the material. I only passed the unit test by parroting back what we learned with no real understanding of my answers.
I made it through BootCamp, but I donāt retain much of what I was taught. I couldnāt wait to stop coding after I was awarded my certification. I didnāt feel confident enough in what I did know to interview as a Junior developer and burnout made additional learning impossible for more than a year after.
I learned some tough lessons after this failure. I must be extremely careful when choosing work ā learning on the fly in a fast-paced environment isnāt for me. Iām not the type of person that finds building the plane on the way down exhilarating. Not having a solid plan with strategies that work for me is anxiety-inducing. I need room to circle back, seek support, and even fail the first time I try a thing.
I fail every day. Sometimes, more than once a day. But, I also succeed every day, as I am constantly learning from my mistakes. Some mistakes take a few times for me to really learn the lesson, but thankfully I have people around me that let me explore these failures and recognize my determination to complete the process and allow that to play out in a natural way. The most important thing I learned along the way was simply: āThe details DO matter.ā While many occupations can live within generalities and summaries, we in testing have to be more focused on what is happening, why, and if broken, how to fix it.
That really hinges then on taking good notes, and documenting the issues as much as possible before reporting them. I have had many situations where a defect actually exposed much more than initially thought, and it would have been better had I just accounted for the increased scope before filing the issue ticket. Perception is reality.
I remember that in a job that I had, I had to wait for a notification from another person to make an urgent move, but I waited log time for that notification that when I realized the date, it was too late for me and that had monetary consequences for my team. It was very embarrassing and I felt very bad about the situation, that I couldnĀ“t sleep well that day, so the next day I went to my boss and apologized for that. Since that day, when this comes to my mind I feel very bad. Lesson learned: sense of urgency.
One of my regular interview questions is āTell me about something that you missed in testing and the impact it had on users, how did it make you feel and what did you learn from it?ā. Iāve had a few candidates tell me that theyāve never missed anything small let alone with customer impact during testing and theyāve rarely got any further in the process - weāve all missed something, weāve all seen the bug report from a customer and wondered how on earth we didnāt spot it. We canāt find everything, itās more about how you learn from what escaped into the real world and the measures you put in place to prevent something similar happening.
A lot of the time itās going to be a one-off and once itās fixed thatās it. Iāve worked on one system where we added automated tests for every customer reported bug but thatās overkill - if itās properly fixed itās not coming back. Iāve got some generic tests that have been developed following those missed bugs - basic checks that stop similar issues in new code.
The most important thing Iāve learnt is that you canāt catch everything and stressing too much about it doesnāt make you a better tester, itās more likely to make you less effective as youāre not so likely to see the bigger picture.
One of the bigger ones for me was a major release at my previous employer. Within a day, the company got a steaming angry response from one of their largest, most profitable customers (while Iām not giving out names, per se, āDonāt mess with the Mouseā was a common saying at that company - which made ticketing software for amusement parks, museums, and so forth).
The test team was utterly bewildered, until we sat in a teleconference and watched them demonstrate the problem. A few questions later, and we realized what had happened: this customer had an unusual process for handling selling multi-day/multi-entry passes to speed up their purchasing queues, which we handled by a configuration flag. None of our testing covered that flag since we werenāt aware of any customers using that flag.
The end result was that we got a cleansed copy of the customerās data and set up test automation that ran against that data to make sure we never broke their scenario again.
Lessons learned? Document the config flags and who uses them. And automate as many combinations of the config flags as possible (this software had several hundred configuration flags. Itās entirely possible that theyāre still trying to get them all automated).
(with a positive outcome).