Finding Opportunities in the Mistakes We Make

Roughly six years into my software development career, I had worked on interesting projects, met amazing people, and had the opportunity to travel to exotic cities. Yet I was frustrated. I was burning the candle at both ends to get things done. I didn’t look back to see if I could improve on how things were being done; I had no time. Deep down I knew it wasn’t feasible. I was working hard, not smart; I felt like I wasn’t working toward anything; I was falling behind with technology. I was burning out.

I started searching for an opportunity to facilitate my technical growth. Two years later I was based at an enterprise client who adopted agile software development methodologies, and everything changed for me. This new world exposed me to a diverse working environment and new perspectives, and encouraged me to ask even more questions than before. This is when I discovered the power of the words “reflect, inspect, and adapt.”

It wasn’t a walk in the park with unicorns and rainbows, but the experience has aided me in officially branding my career as one exciting journey of professional and self-discovery. Now ten years into my career, I realize that for most of that time I have been in survival mode. After looking back, I’d like to share how I found opportunities in the mistakes I made.

Define clear career and personal goals#section2

Computers weren’t a household name when I was growing up in South Africa, but I was lucky to have access to my dad’s Pentium 386. I was amazed at this technology. When we got internet access, I was immediately hooked on the online world. I taught myself HTML and later built my own machine with the money I made from designing a website for the local newspaper.

When I chose my higher education path I had one goal—I wanted to make websites. I didn’t want a degree; I wanted experience. I studied at a college for two years, then excitedly entered the workforce to follow my passion.

As I entered the workforce, I wasn’t prepared for the politics: managers expecting things to be done almost immediately; clients who don’t engage and are unsure of what they want; clients who express urgency, yet wait for the last minute to provide you with everything you need; an increased workload due to colleagues who stay well inside their comfort zone. These are just some examples of the politics that initiated my frustrations.

I wondered if this is where I’d still be in five or ten years and if I would be able to sustain it. I didn’t know the answer to the former, but to the latter it was definitely no.

Coupled with turning thirty, the new perspectives I developed in the agile environment made me really evaluate my future. I realized that I didn’t have goals; I was only chasing my passion. Granted, it is fun and I gained a lot of experience in many different areas in IT, but I don’t have anything tangible to show for it now.

After much reflection, I discovered these goals for myself:

1. Increase productivity. I minimize distractions like email, social media, and uninvited guests to improve my productivity. To make sure I am working on the right tasks, I need to have a clear understanding about what I am working on and why.
2. Develop software that has a positive impact on people. It is important to understand business thinking and impact on users. I need to ask appropriate questions, and I need to guide and negotiate with product stakeholders.
3. Share my knowledge. I can create an online identity (publish articles, blog), possibly speak at events, and contribute to open-source software. I can find projects on GitHub of libraries and tools that I regularly use and create a pull request.
4. Better my craftsmanship. I can learn through code reviews and peer conversations, listen to podcasts, read up on best practices, read more craft-related reference books, and reflect on my implementation.
5. Learn to live mindfully. To have a positive impact on people, I can make small adjustments and engage those around me to help me grow. Meditation, reflection, and motivational books are tools I could use to guide me.
6. Showcase my career. Create a tangible timeline of projects I have worked on including screenshots, descriptions, technologies, and learnings.

These goals feel more defined to me than just making cool websites. I wish I had set some goals a little sooner but luckily — as cliché as it sounds — it’s never too late. Goals give you direction and purpose. Like me, you may have worked many late nights on personal projects that never materialized. It helps to have focus and something definite to achieve. I find what’s best of all is that I don’t feel constrained by having these goals. They represent what’s important to me now but if my values change, I can inspect and adapt my goals.

Put people before technology#section3

For too long, I worked alone on my own codebases and wondered if I was doing things the right way. I had little to no exposure to working in teams and dealing with industry buzzwords like agile, TDD/BDD, Gang of Four, SOLID, code reviews, continuous integration/delivery, DevOps, and <insert your favorite technical jargon here>. I was in a bubble falling further behind in the fast-paced technical world. I was focused on working with technology and never realized how important it is to collaborate.

If you work in a company with a silo-based culture or one- or two-people teams, try not to accept things for what they are:

• Get involved with your coworkers by communicating and collaborating on projects.
• Try introducing knowledge-sharing sessions and code reviews.
• Reflect on what worked and what didn’t and also unpack why, so that you can learn from it.
• Approach management with suggestions on how you and your colleagues can produce more solid and effective software.
• Attend conferences or smaller community meetups. Not only can you learn a lot through the content but you have the chance to network and learn from an array of people with different skills.

Prioritize your tasks#section4

I often worked about twelve to sixteen hours a day on projects with short deadlines. I spent my official work hours helping colleagues with problems, immediately responding to email, attending to people with queries or friendly drop-ins, supporting projects that were in production, or fighting fires resulting from errors that usually came from miscommunication. This left me with very little time to be productive. When I finally got to work on my project, my perfectionism only increased my stress levels. Regardless, I never missed a deadline.

I thought everything was important. If I didn’t do what I was doing the world would end, right? No! The reality is that when everything is important, nothing is important.

This working behavior sets unrealistic expectations for the business, your colleagues, and yourself. It hides underlying issues that need to be addressed and resolved. If you are working at an unsustainable pace, you can’t deliver your best work plus you end up missing out on actually living your life.

The power of retrospectives#section5

The most important ceremony (or activity) I was introduced to in the agile environment was the retrospective, which is “the process of retrospecting at the heart of Scrum (Inspect and Adapt), eXtreme Programming (fix it when it breaks) and Lean Software Development (Kaizen or Continuous Improvement)”.¹

Through retrospection you are granted the opportunity to reflect on how you — and the team — did something, so that you can improve the process. Let’s run through this technique to identify some pain points using the situation I had found myself in:

• Working unsustainable hours because there was too much to do. I helped everyone else before I worked on my own tasks, I worked on things that didn’t add much value, and I thought that all the features needed to be ready for launch. I was blind to asking for help when I needed it.
• Dealing with too many distractions. I allowed the distractions by immediately switching context to help others because it was important to them.
• Key-person dependency. I was the only person working on one of the projects.
• Miscommunication resulting in errors. Communication was done via email and the stakeholders were off-site. There wasn’t quick feedback to indicate if the project was going in the right direction.

Once the pain points are identified, adjustments need to be made in order to see improvement. Large adjustments could take too long to implement or adjust to, which leads to disruptions. Smaller adjustments are better. These adjustments may or may not work in the long haul, so we can look at them as experiments.

• To work more sustainably I need to know what I need to work on — and why — so that I can add value without wearing myself out. Perhaps I could find out what needs to be available for launch and create a prioritized list of things to do. This list could help me focus and get into the “zone.”
• To manage client expectations, we can try open communication. This can also help me prioritize my tasks.
• To overcome some of the distractions I could reap the benefits of being selfish by saying no (within reason). This could help me stay in the zone for longer. If anything must be expedited I can start offering trade-offs: if I do X now, can Y wait?
• To alleviate the pressures of being the sole person able to do certain things, I could have more conversations with my manager and train a colleague so that they are aware of what is going on and someone can take over in the event that I get sick or am on vacation.
• To reduce errors from miscommunication, perhaps we could create visibility for stakeholders. Introduce a physical workflow board and have constant feedback loops by requesting frequent reviews to demonstrate what we have done.

Experiments run for a period of time and need to be measured. This is a grey area. Measurements aren’t always accurate, but it always boils down to the pain. If the pain is the same or has increased, then the experiment needs to be adjusted or a new experiment introduced. If it has been alleviated, even slightly, then there is improvement.

Learning through experimentation#section6

Many of the experiments mentioned above already form part of the agile Scrum framework, so let me introduce you to real-world experiments we did in our team.

Based on the way our development stories were deployed, we experienced pain with testing stories in the appropriate order. We were using Jenkins for automated deployments and each one got a number incremented from the previous one, but the testers weren’t testing the stories in any particular order. If a story was ready to be deployed, they wouldn’t know if there was another, untested story that they were unwittingly promoting to production along with it, or if the story they tried to deploy was being held back by other stories still awaiting testing.

Without waiting for a retrospective we had a conversation to highlight the pain. We chose to write the build number on a note stuck on the story card on our wall and add a comment to our digital storyboard. This created quick visibility on the chronological order of the possible deployments of our stories.

A change control process was later introduced that required details of a production deployment and a rollback plan for that change. We couldn’t quickly access the last few production build numbers, so we started writing them on stickies and put those onto a new section on our physical board. Now we didn’t have to search through email or log in to Jenkins to find these numbers. One day, we were asked when we last deployed and had to go back to email for the answer, so we started adding the date to the deployment number stickies.

These were simple experiments but they added a lot of value by saving time. We acted on alleviating pain as it happened.

Don’t be afraid to experiment if you are not in an Agile world. If you simply run to business with problems and offer no solutions then business will frown at you. The goal here is simple: identify your pain points and find simple solutions (or improvements) to try to alleviate the pain. Experiment, inspect, and adapt often.

Believe in yourself#section7

Survival mode never did me any good. I didn’t get an award for working long hours to make deadlines. Letting my mistakes and frustrations build up over the years made me stop believing in myself.

I was stuck in a rut; technology was changing around me fast and I was burnt out and falling behind. I’d scroll through Stack Overflow and instantly feel stupid. I’d spend time looking at all the amazing websites winning awards on Awwwards and feel inadequate. I didn’t have a life as it was consumed by my obsession for work. I didn’t know what I wanted anymore, or what I wanted to aspire to.

Introspection helped me. By inspecting my behavior, I was able to make minor adjustments that I would then inspect again to see if they worked. This simple activity can show you what you are capable of and lead you to learning more about yourself and those around you. I am applying what I have learned in software in a personal capacity. I have my life back, and I feel empowered and freed.

My final thoughts#section8

I’ve definitely made a lot of mistakes in my career. What I have shared with you is probably only a fraction of them. I don’t regret my mistakes at all; that is how I got my experience. The only regret I have is that I wish I had begun reflecting on them sooner.

When a mistake is made, an opportunity is born: learn from that mistake to do something differently next time. Take time to step out of the subjective into the objective, so that you can reflect and consider what you could do to change it. (And don’t be too hard on yourself!)

My journey has taught me to implement small experiments that can be measured and to run them for short periods of time. If something works, keep it. If not, adjust it or throw it away. By making small changes, there are fewer disruptions. If you too are in survival mode — stop and breathe now! Reflect, inspect, and adapt.