What Would You Do if You Blew 500k Down the Drain
The Set-Up #
What would you do if you had just blown 500k down the drain?
Admittedly, it wasn’t real fungible currency, imagine you could only spend this 500k at whatever store you desired - but only that store.
You wouldn’t hesitate and loiter around, you’d definitely spend it all in one day, wouldn’t you?
Well, I had my store, it just happened to be Amazon. But not the bookstore, but rather the Web Services.
This is where the story continues after recovering from the early 2020s — a time when the world stopped, and exploration became both physical and mental. Amid the isolation, I found solace in walks through empty streets, the kind of stillness that made me reflect deeply on my purpose and direction.
At the time, I was determined to build a product that could change how people interacted with their urban environments. The project had ambition, but the reality was far less inspiring. After months of late nights, long discussions, and countless iterations, the project failed to launch. The blood, sweat, and tears poured into the vision felt wasted.
The initial sadness of failure was palpable, but within it lay a glimmer of something more profound: the urge to understand why. This became the moment that propelled me to dive deeper into the “why,” “how,” and “what” behind the project’s shortcomings.
The Catalyst #
The turning point came when I decided to confront the painful truth: we hadn’t thought far enough ahead to ensure the project’s success. While we had big ideas, and with me having accelerated my technical journey. We ultimately only had the technical foundation and foresight, but not the manpower, to build something scalable, reliable, and impactful. This realization wasn’t just humbling; it was transformative.
The debate followed: Should I give up on building, or should I double down and learn the skills I needed? The answer wasn’t immediate, but a spark ignited within me—one fuelled by curiosity and determination. On top of learning the frontend and backend sides of software development, I delved into systems design, and even lower levels of software development. Cue my entry into DevOps, it was inevitable.
The Break into Two: Journey into DevOps #
The decision to learn DevOps wasn’t about buzzwords or trends—it was about understanding the systems that underpin successful projects. DevOps presented itself as a philosophy as much as a practice, uniting development and operations to ensure seamless software delivery.
I started small: learning how to set up CI/CD pipelines to automate code integration and deployment for my tiny projects. Every small victory adds momentum. Along the way, I’ve seen myself embrace tools like Docker for containerization and Kubernetes for orchestration of the containers, discovering the beauty of creating systems that practically ran themselves. This would have, in theory, fixed one of our roadblocks to deployment. We effectively didn’t know how to work efficiently using the same repository and our codebase was fragmented across two minds and multiple devices.
The B Story—my secondary journey—was the internal transformation. I wasn’t just learning tech; I was learning to think like a builder. Every failure and iteration brought new lessons about collaboration, scalability, and the human side of software development.
Fun and Games: Finding Joy in the Process #
The “fun and games” phase wasn’t without its lighter moments. As I learnt to get more comfortable learning about automation tools like Terraform and Ansible, I marvelled at the power of Infrastructure as Code. I laughed at my earlier frustrations when I’d manually configured servers, realizing how far I’d come. As much as these were beginner projects using free tiers - this was an insight into seeing how other teams use these “best practices” within their working cultures.
Understanding why working with observability tools that are tracking system performance and catching issues before they escalated, was like playing a strategy game. The stakes are real over here, and the satisfaction is immense.
The Midpoint #
The midpoint of this story was marked by a realization: this wasn’t just about me. DevOps, at its core, is about teams and culture—how they collaborate, iterate, and support each other. My transformation wasn’t just technical; it was philosophical. I began to understand the aspects of human action within the development and continuous deployment loop, and how intentionality drives decisions and builds better systems.
The failure of my initial project had taught me to focus on what matters: simplicity, scalability, and purpose. I saw my past mistakes as stepping stones rather than dead ends.
Ever since there has been a newfound clarity about my goals. The journey has never been linear, but each setback has brought me closer to understanding what it means to build with purpose.
Break into Three: The Comeback #
Armed with these lessons, I push forward. It wasn’t just about solving technical problems; it was about crafting systems that aligned with the needs of users and the vision of the team that uses them.
I guess the theme statement for this post should be: “True growth comes from understanding the why, how, and what of failure, and courageously using that knowledge to build something better.”
Lastly, one shouldn’t let failure define them. And the question of whether to stay in our comfort zones or venture into uncharted territory lies within ourselves and us alone. We all have the capacity to rebuild ourselves into more competent and resilient agents. Ultimately, I implore you to follow the same path, because it’s more fun being competent.