The Only DevOps Skill You’ll Ever Need to Master
If you’re going to master anything you first have to admit that you are not a master of it already.
– Jordan Peterson
DevOps is the name. Learning is the game.
Buzzwords everywhere
It is no secret, the world is abuzz with the craze that is DevOps. If you are involved in Tech development in any way you have most probably come across the term at the very least, and chances are good that your company has spent a fair amount of resources attempting to recruit someone just like me. That allure of on-demand, auto-provisioned, streamlined, cost-efficient and endlessly customisable cloud-native, production-like test environments. Those automagic CI/CD pipelines that are gloriously reusable and yet completely within the conceptual grasp of every junior JavaScript dev that walks through the door.
And who can forget… Kubernetes 🫠
In truth I am paid what some… including myself there… consider big bucks, to do one thing. A really cool thing in my book, and one that keeps me on my toes and out of mischief (mostly)… and it is the only skill you will ever need to succeed in DevOps.
Fast Learning
Myth: Only some people can learn, others just need to deal.
Hypothesis: Unless you are part of a small percentage of the population who suffer from learning disorders, you are fully able to learn just about anything you put your mind to, no matter your place of origin, gender, background. Evolution has your back!
Ok ok… that’s a bold statement, and clearly it’s not all true. There are some people with superb spatial and technical awareness who automatically find it easier to learn technologically inclined subjects. Others find it easier to memorise reams of facts likes names, places, and dates… a perfect match for a study of history and the humanities.
But hang on… have you ever seen a person drawing and been like “damn I wish I was that talented!”? Next time try asking them if their ability is talent or practice? Try asking them how they take a talent they were actually born with, not just the one you see now, and develop it into something worth looking at…
My job as DevOps Tech Lead is about gathering as much knowledge of the world as quickly as possible, processing it, assimilating it, sharing it with others in my organisation so that we might all together make the best possible decisions and add the maximum possible value with hopefully the least amount of resources. It is also to ensure that everyone on my team is doing the same, to the same high standard. Obviously there is a fare amount of human interaction involved so I am constantly learning how to be more approachable, more understanding, more of a coach and less of a control freak.
The constant search for the best technologies is never-ending, and the world is getting faster and fuller than I have capacity to learn. Being a lead requires learning how to teach, and learning how to learn, and learning how to teach others to learn and teach…
And don’t get me started on the learning involved in organisational politics or contract nogtiations…
I do not think that these are specific to DevOps fields. I do know that DevOps has an extremely wide range of fields that it covers and so there is truly never a dull moment with a seemingly infinite set of worlds you can infinitely delve into.
What the actual stack?
So what about those lists then? You know the ones…
- 10 best DevOps tools of 2023
- The essential DevOps tools you must learn
- The must-have tech stack for any project
- My journey to some tool certification
Don’t get me wrong, respect to anyone who gets those crazy certifications… they are NOT easy. And there is definitely something to be said for the level of competence of a specialist in his given field. Nothing beats focused experience!
That having been said, if all I had was an AWS EKS certification, or only a Kubermetes Operator cert, or some Jenkins partner certification, then where would I be when faced with the challenge of implementing Nomad via Ansible based on Github Workflows in an organisation where they all just happen to be the perfect fit?
Tool stacks and catchphrases are essential, but they are not the way to focus unless you are in a position which demands those specific tools and specialties. A jack of all trades can sometimes add more value than a master of one.
Dragons, not catchphrases
The idea is to look beyond the tool, to the essential skill required to learn the tool… to learn ANY tool… at the drop of a hat… to production standards, and to teach others…
Essentially you don’t need to learn every tool… All you need to learn is how to slay dragons… how to go boldly where no one has gone before and learn the tools available, and being able to distill understanding from the smallest interactions. Coming to a place of confidence with a tool in spite of our glaring inadequacies, and forging a path forward through the feelings of anxiety, our imposter syndrome, and finding the answer and the deeper understanding so that other people can get the distilled abstracted version and continue about their days creating value.
Sometimes this means understanding what you should learn first and what can be left for later. Or maybe the 20/80 principle applies, where 80% of use-cases will be covered in the first 20% of learning. Or even knowing when to get expert help in finding a deeper understanding of some topic. And especially knowing how to let go and allow others the opportunity to learn and teach.
If you want to succeed in DevOps, or Platform Engineering, or actually just any kind of Tech Development… learn one thing at the very least…
Learn to learn
Learn HOW to learn…
Learn the many aspects and techniques to learning, learn to love learning, learn how others learn and learn how to integrate all of this into your life and create your own styles of learning, so that even outside of the workplace the drive to learn can help enrich your life at every turn.
Want to see an example? Just look at kids.
Children are learning machines, they have an interesting approach which is not dissimilar from AI model training… they ask extremely complex questions, sometimes in extremely simple ways, and sometimes we cannot answer them fully, but we can also never lie (I mean you could but who are you fooling?), and so we use age appropriate terms which give a portion of the information and the child is left to deal with a certain level of not knowing… not fully… until the next time the child asks the question and gets a similar of maybe even fuller answer in a slightly different way, and this time is able to maybe understand the language a bit better… aggregating the answers and adding knowledge as they go until the understanding is clear.
Children will attempt to validate their understanding. They will attempt to explain the thing they learnt to someone else, usually their parents or siblings due to proximity and trust. The audience’s response will either be positive or negative causing a corresponding reaction in the child’s hormonal balance and creating a memory for later reference in the child’s brain, in the reward centre. Every time they get something right they get a dopamine hit and their brain says “more please!”.
There are situations where the opposite is true. The child’s brain attempts to learn something and the environment turns hostile for any of a thousand reasons, and then the result is predictably negative. And then an aversion to learning can be created and could last well into adulthood and beyond.
This interaction of hormone and neurone causes connections and pathways to be formed in the brain. And the more a similar interaction occurs, the more said pathway will be enforced and accessible. Additionally said pathway will be easily compared to current events so that similar techniques and responses can be drawn on in varied and seemingly unrelated circumstances.
This is why many developers will tell you that, barring the deepest intricacies, if you know one development language, you know them all. Because there are commonalities that make a coding language a coding language. Once you know those, the variations on syntax will seem like variations of a dialect, maybe difficult to fully understand, but you can kind of get the gist. Similar conjectures have been made related to human language.
Children incorporate a mix of supervised and unsupervised learning models and probably many that we do not yet fully understand 😅😉
All of this is to say that you should be flexible with your approach and allow for, and be comfortable with, a level of uncertainty while moving forward.
Embrace the Failure
Failures give us crucial information so use them as a superpower!
Every failure gives us an opportunity to learn a deeper fact. There is no such thing as a meaningless known failure. The very fact that a failure happened at all is interesting and can lead you down a rabbit hole of discovery.
Failures allow us to find weak points and fix them, like a broken bone they become stronger where the break was.
Edison famously tried hundreds of elements before landing on the final filament for his light bulb.
And trying different things on each failure is the very antithesis of Einstein’s famous definition of madness.
The Literature and Science
Many books have been written about the subject, with many theories. From the 10,000 hours theory to the 10,000 experiments theory, from Information Processing to Multiple Intelligences theories, there are reams and reams of theory to go through on the subject of human (and non-human) learning going as far back as Confucius and probably further…
Much research has been done into how the act of learning itself can assist in prolonging our natural neuroplasticity, the brains ability to adapt and rewrite itself to match the requirements of our environment. Learning can be used to promote neurorehabilitation in patients with brain injuries, and can even lead to neurogenesis (the growth of new brain cells) in previously damaged regions like the hippocampus, a region critical for learning and memory
Learning DevOps
Yeah yeah, ok… so what does this look like in DevOps day-to-day?
The idea is to challenge yourself, even learning those certifications. Anything is learning and no information goes to waste.
Many will tell me that as a DevOps engineer they took the established technology and worked with it, learning how to manipulate it to assist them in their tasks. This is one aspect of learning DevOps. Understanding the technologies currently in-play and what magic can be achieved with them.
Yet others will tell me how they were able to find faults in current technologies and managed to discover or even develop a suitable alternative, and even implement it for their efficiency and that if the projects and people around them… this is next level!
And then there are some who will tell you a slightly more involved story.
“The shortfalls of the existing solution were too much, and so after fully understanding the requirements and limitations, I researched alternatives, compared POCs, presented my findings together with a plan to completion and a cost breakdown, and then implemented, documented and taught the organisation all the newly designed procedures necessary to use the new technologies comprehensively.”
Now that is beast level DevOps right there!
And along the way if you managed to also learn something new about your own learning process, maybe some new techniques or hacks, and maybe even managed to impart these on others along the way… well you might just be mentor material
And the only way to get there is to learn!
