As any software engineer knows, naming is often the most challenging thing we do.
I’ve struggled with naming things over the last twenty months. Here are some highlights.
In January 2022, I wrote “Automation for the Nation“. A book on why automation is a good thing. I completed it (80%), but it’s not yet seen the light of day. At the same time, I launched the podcast – also called “Automation for the Nation”. I also launched a newsletter with the same name.
At that time, I was working for a client in the medical profession and a client in the retail profession. I was doing half DevOps and half project management. The project management content was valuable and interesting, and it led me to discover systems thinking and complexity theory.
Shortly afterwards, I decided that software delivery was really the name of the thing I was working on. Not automation, DevOps or project management but software delivery. I renamed the podcast, and the newsletter and started writing and talking about delivery.
In essence, though, this felt too high level. DevOps or automation is more the thing. Management consultancy and project management is not the thing. Yes, you can read The Goal, but what can you do about it in your daily work?
At that point, I felt Software Delivery was too vague and missing the point. I tried to discover the heart of the problem, and I thought it was legacy software. Unloved legacy was a problem. We didn’t give it enough love. Rename podcast, rename newsletter.
This worked. It felt closer to what I was feeling. I interviewed some great guests about Kubernetes, observation, developer tooling, and architecture and then hit another wall.
What was the line that drew these things together? Why was it so hard to write about things I was passionate about?
Doing Daily DevOps
Around this time, I was reading Test Driven Development by Example and The Unicorn Project. I was working in a development team where testing and automation were poor. And while I was helping it out, passing on what I knew, I had a realisation.
I realised that daily action was required. While it is essential to read books, listen to podcasts, get ideas and talk to each other. None of this matters without daily action.
In July 2023, I got up on stage and talked about QUEST. For the presentation, I made this slide quoting James Clear’s “Atomic Habits”
Daily action in a team helps us improve. Improvement is a habit that must be repeated. Results will not come immediately.
While I couldn’t be in every development team in the world simultaneously, I could provide ideas, support and a framework for daily software quality improvement.
As a development or DevOps team member, you must be able to influence your daily work. Change the environment that you are in. Deliver the quality that brings you closer to the ideal of your customer needs. If your systems are letting you down and you can’t change your systems, find a way to make those changes happen.
This is how I help by getting engineers to make intelligent choices to make better software.
New name, new iteration. You can sign up for my newsletter and find out more about how to build better software together in Doing Devops.