I love learning the what, why, and how of new open source projects, especially when they gain popularity in the DevOps space. Classification as a "DevOps technology" tends to mean scalable, collaborative systems that go across a broad range of challenges—from message bus to monitoring and back again. There is always something new to explore, install, spin up, and explore.
That said, you don't have DevOps without principles. Some of these concepts are intuitive truths we have known from the start but needed a movement to help us adopt them. Others are quite different and help us acknowledge and grow beyond our cognitive biases.
While not strictly DevOps, one principle that changed everything for me is kanban. The simple idea of work being visible and optimized for flow was radical for a chronic multi-tasker like me. To this day, I keep work in progress visible, and it's been a huge relief to not worry about losing a task along the way. Not only that, I no longer celebrate work in progress: I celebrate completed tasks.
To find out what things have influenced my colleagues, I asked members of the Open Source DevOps Team to share their thoughts on this question:
What is one DevOps concept (practice, principle, pattern) that changed your career?
Here's what they had to say.
Fail fast, fail early, fail as frequently as you possibly can. Before I clued into this amazing concept, I was toiling miserably in vain under the traditional waterfall model. My career was a series of botched projects; all of them commencing with the "failure is not an option!" cheer. It is an extremely tiresome way that always results in working inefficiently and lurching from one frustration to the next.
Embracing the fast and furious flurries of failure was the best thing that happened to my career. Frustration got replaced by the feeling of soaring. That lead to the wholesale adoption/embracing of TDD [test-driven development] practices and to the realization that TDD is NOT about testing, it is about DRIVING!
Culture hacking. I had no idea there was a name for the method I had (subversively) used to change a culture, but then I saw Seb Paquet's "Ignite Montreal" video and rejoiced that there were others out there.
Continuous improvement. Until I was introduced to continuous improvement, I was not really looking at ways to improve in my job or in my career. Continuous improvement made me realize that it was up to me to challenge myself with learning new things and getting out of my comfort zone. That led me to start contributing to an open source project (Fedora) and then led me to work for Red Hat. So that definitely changed my career.
It started with The Lean Startup at my first Code for America Summit. In 2012, I distinctly remember a career-changing moment. Eric Ries, author of The Lean Startup and Code for America board member, was on stage with Tim O'Reilly. The topic they were talking about was hacking on code, and culture and failure as validating learning. My biggest takeaway was discovering The Lean Startup. I downloaded the book and read most of it on the plane ride home. It changed how I approach my work and how I lead my team.
The biggest change I made was to incorporate feedback loops. This was a critical difference in how I transformed my work style and my team. I shifted my team habits to making data-driven decisions and sharing information and insights to create those feedback loops. We hold weekly health-check meetings and constantly examine our processes and assumptions. In addition to that, we experiment with new ideas and evaluate how those experiments went. We'll conduct start, stop, and continue sessions to help us understand what to tackle next or what didn't work so we can move on.
During a two-month sabbatical in 2018, it dawned on me that the fear of failure had paralyzed my energy and passion for software engineering, a career I used to love. Realizing that failure is not bad, but an enabler for innovation, collaboration, and continuous learning that fuels DevOps, was a key moment in my career. Transparent collaboration, progressive exposure, hypothesis-driven development, test-driven development, and continuous delivery of value are some of the core practices that generate frequent opportunities to fail fast, inspect, and adapt the solution (and the career) we are working on.
There are so many ways DevOps can teach us without ever opening a terminal or user interface. So, I ask you the same question: What DevOps concept made the most impact on your career? Please share your thoughts in the comments.