DevOps Engineer: Perpetually in Diapers
Yes, we really don’t know what we are doing (mostly)
Learn Everything Now!
Around a year ago I read a hilarious post in the DevOps subreddit:
The funniest part of the post is how true it is, nearly 500 upvotes and multiple responses confirmed it— we really don’t know what we are doing!
The impostor syndrome is not just a feeling in DevOps, it’s all too real, we are to a certain extent all impostors.
But wait, before you judge us too harshly, just look at this list of tools that can at any time fall under our remmit:
Or this other popular roadmap of what to learn to get into DevOps (it’s longer than this, just didn’t want to scare you much):
Yes, it’s mad, even the most seasoned of engineers will get anxiety looking at those, especially because many of these tools and technologies are not something you can familiarise yourself and run with it in 20 minutes, most take from weeks, to months to years to master — and many don’t stick around long enough before they are replaced by something else! (Bye Puppet!) Spoiler alert: I’ve been working in DevOps type roles for years and I am not an expert in all those things.
No Two DevOps Roles are Alike
That is the problem, that no two jobs are exactly alike — or much alike for that matter! Most professions have a much narrower scope. For example, you wouldn’t expect a pilot to go from an airbus, to a harrier jet, to a helicopter, to a lorry, and after five years back to an airbus. Also, you wouldn’t expect the pilot to fly planes that are still being tested, with incomplete or lacking functionality, and assume that the pilot will either contribute to the engineering of the plane in mid air or come up with a hacky solution to make it fly. And yet that’s what we do in DevOps, every single job is just so different in scope and type of technologies used that by the time you change jobs, you are out of your depth again — in diapers, so to speak.
It’s not at all unsual to jump from AWS to GCP, from ECS to EKS, from EC2 to Lambda, from Python to Bash, or from Terraform to CloudFormation. It happens all the time in a cycle similar to this:
You get good at X after one year, you jump to Y and you are out of your depth, then you get good at Y and later come back to X, but because you’ve been with Y for so long, you forgot most about X. Or maybe X doesn’t exist anymore and Y is on its way out — here comes Z!
And sure, refreshing old knowledge is much easier than starting from zero, but continuous context switching always makes mastery very difficult, even for seasoned engineers.
Stick to what you know — that will solve it, right? Wrong!
Even if you are adamant about sticking to one technology, you will still find that most of the tools we work with move so damn fast, that it is hard to catch up. Also technologies are rarely an island. You just don’t learn Kubernetes, you have to learn loads of things that go on top of kubernetes (like service meshes), and that also changes from role to role — sometimes quite dramatically!
For example, recently a friend of mine started a new role as a Senior Platform Engineer. He is good at his job, he is very good, with years of experience in Kubernetes. And yet now he is out of his depth again working with Kubernetes “screwing up dev clusters” as he puts it. Fumbling around like a baby in diapers, because the company where he is in are using Cilium, something that he has never used before (and frankly Cilium is very rare -very cool- but very niche still)
As a consequence he is constantly feeling anxious about how he is being perceived. “I am supposed to be the senior guy, and I suck at this!”
He really is too hard on himself, because that’s just the nature of the beast — we all kind of suck.
So How do we make this easier?
There are two ways you can tackle this issue:
- You stick strictly to what you know when looking for new roles.
- You Embrace Chaos and go YOLO.
Both of these options on their own are foolish.
The first is a difficult decision to marry to because too often technologies go out of fashion or become obsolete.
The second option is also probably not very wise if you want to keep your own sanity. I enjoy learning new things, but being constantly out of my depth is also not fun at all.
The best option is to opt for three quarters of the first and a quarter of the second. Focus and master a few areas you enjoy the most while making small forays into other areas you want to learn. For example I made a decision that if I have to pick between Azure, AWS and GCP, I will always pick GCP, it’s best for my sanity.
I also will try and pick working in technologies that I feel have a good future based on what I know people need, rather than just picking what’s in vogue, I try to understand what problems affect the industry and what solutions are more likely to solve those issues best.
For example I feel that platform engineering is the most logical evolution of DevOps and hence I decided to veer my career into that path, because I believe in it — I could be wrong, but at the very least I find it easier to be passionate about what I believe in.
But I am New! How do I even Start!?
Glad you asked, even though I said we are continuously in diapers due to the virtually unlimited amount of tech we need to learn, that doesn’t mean there isn’t a solid common base to depart from. I have written a guide on the most important skills and tools to learn, things that are common to every job and that are very unlikely to go away any time soon, like Linux, Git and Bash. Check it out and start with the core skills!
The Future
We are in a post Big Bang era of DevOps, with thousands of half cooked tools that try to solve the same problem in various ways. The future will be more “boring”, when the best ideas win and the implementations crystalize, my prediction is that we won’t have this issue nearly as much. Also tools like ChatGPT will definitely not replace engineers but may make our job much easier when it comes to generating template code, finding solutions, and quick answers to issues where a computer is quicker to fetch all the data and find patterns.
Personally I feel that the future of Platform Engineering and internal developer platforms is bright and it is the logical progression of DevOps because it will make it much easier for developers to work and self-serve their infrastructure needs while leaving more time for the “DevOps side” to engineer solutions for them.
Time will tell, until then, happy fumbling!
