How Changing Code Directly on the Server Impacted My Career

This isn't a tale of recklessness leading to disaster from which I had to recover. On the contrary, this is about how my early experiences shaped my worldview and the surprising benefits of not being aware of the rules.

A New Hope

It was the '90s, the era of CRT monitors and the unmistakable screech of dial-up modems. At the time I was still in high school, but I landed my first solo freelance gig: developing one of the early social networks. Not knowing any better, I was editing the single copy of the code directly on the production server. The stakes were high: a single mistake, and the site could crash instantly—there was no backup, no undo.

Why would anyone handle production code with such recklessness? In retrospect, I cringe when I think about it, but somehow, it worked. Despite the occasional outage and the cascade of user complaints that would follow, the site continued to attract and retain users, and the direct, unfiltered feedback from those early adopters was invaluable. I certainly abandoned this naive approach, but - as you will learn - it also laid the foundation for my future achievements.

The Enterprise Strikes Back

Several years later, armed with my PhD in bioinformatics and stepping into my first job as a software engineer, I faced a stark reality check. My new managers were far from impressed with my 'dive right in' approach. This was when I was introduced to the world of version control and UML diagrams, a realm where long-term planning and predictability were valued over quick fixes and experimentation.

Obviously I quickly understood the value of risk mitigation, it was clear to me that my initial approach was too naive. Yet, amidst these structured processes, I couldn't help but miss the thrill of immediate results and the satisfaction of rapidly solving problems. It felt like a part of what made coding exciting had dimmed. But, as I would soon discover, my early instincts about software development weren't misguided; I just didn’t have the right tools to make them compatible with a professional environment.

The Return of Developer Delight

Back in 2010, concepts like continuous delivery and feature flags were still on the rise, not as widely adopted as they are today. Discovering these ideas was a revelation for me; they echoed the quick, impactful coding approach I had always valued. But convincing my team and managers was another story. At the time, these methods were new and unfamiliar in our environment, and the idea of deploying multiple times a day and giving access to unreleased features to a select group of customers faced a fair share of skepticism. But I was persistent in advocating for these methods, because I missed the profound value of the instant feedback we were missing out on.

Eventually, an unexpected opportunity arose. A critical performance issue needed immediate attention, a fix that couldn't wait for the next scheduled release. My managers reached out to me, and suggested that they would agree to me trying continuous delivery if I’m leading this project. This was my moment, a chance to prove the worth of these ideas in a real-world scenario.

After the pilot project turned out well, we faced a new challenge. My managers - inspired by the pilot's success - were excited to spread continuous delivery to other teams. However, this idea was met with resistance. Some team members were downright skeptical, questioning its scalability and worrying it would lead to constant firefighting in larger projects. Others, while open to the concept, were stuck on how to transform the aspirational visions of the company's leaders into a sequence of small wins.

That's when it hit me: simply talking up continuous delivery wasn't enough. To really get people on board, they had to experience it in action. I needed to demonstrate its value, not just preach it. I was determined to find a way that would transform their doubts into genuine excitement.

The Rise of Lean Poker

Back then, I was already deeply involved in running Coderetreats, which had proven to be an effective way to immerse people in software crafting concepts like test-driven development. This experience inspired an idea: what if I could create a simulated environment where feedback cycles were much faster than in real life? An environment that was complex enough to be engaging, yet not overwhelming, could be the perfect stage for people to truly experience the power of continuous delivery and DevOps in just a few hours, bypassing months of gradual learning.

That's how Lean Poker was born. It was designed to be an engaging experience that leads to revelations of what teams could achieve. To date, we've held over 100 events in 38 cities worldwide. While Lean Poker offers a simplified environment, the impact on the participants has been profound. It's not realistic to expect teams to transform overnight following the workshop, but the thousands of engineers who have participated in Lean Poker events often start rethinking their development processes from the ground up. It triggers teams to ask themselves questions not just about continuous delivery, but about what it means to be an effective software team.

Lean Poker has become a valuable tool for agile and technical coaches, providing initial insights into the challenges faced by teams they are just beginning to work with. It's a catalyst that has inspired teams globally to break free from their routine and significantly amplify their effectiveness.

My initial mission was to help my colleagues experience the transformative power of incremental delivery, a lesson I valued since my days as a '90s script kiddie. But now, my journey has evolved. I'm on a quest to bring this empowering experience to every developer around the world. You can join me on this exciting journey. Sign up for the Lean Poker newsletter to stay updated on upcoming events and to gain insights into the unique brand of incremental software delivery that I practice. Together, we can redefine the way software is developed, one incremental step at a time.