Last week I started reading the book Range by David Epstein, which talks about how specialization and the “10,000-hours rule” may not be the only path for being an effective professional.
Instead, he claims that breadth of knowledge and experience may give you a professional advantage in modern times.
It’s now ok to be a generalist - You don’t have to hide anymore. Malcolm Gladwell will not come to haunt you.
Like with everything, I try and look at it from my professional point of view. In this case, the book touched on something I’ve been thinking about for a while. I even talked about it on the DevOps Squared podcast - What makes for a good DevOps engineer.
Oh, and a little disclaimer - I’m obviously biased so take everything here with a grain of salt.
DevOps is a perfect example of where over-specialization may be advantageous for very limited engagements and where a range of disciplines will give you the advantage in the long run.
I like to use an example from a past consulting client where they migrated their product to Kubernetes. They had a very talented DevOps engineer overseeing this project, but, like always, he was swamped with work.
He struggled with this one particular issue (I don’t even remember the specifics), and he asked for my help.
New to the project, and back then, new’ish to Kubernetes, I set out to solve the issue, and a couple of hours later, I completed the task.
“How did you manage to find a solution?” He asked. I showed him this article that outlined a similar problem, and the solution applied here as well.
“I read this exact article multiple times and still can’t understand how you got to this solution.”
How did we both read the same article but got two different results?
I had two things going for me:
- Experience with multiple related technologies - more mental models in my toolbelt.
- First principle understanding in these topics allowed me to break down the problem and then build from that knowledge and apply it to this specific issue.
Think about it: DevOps engineers have to have knowledge and experience in many domains, where each one is a world on its own.
It reminds me of the old “hacking” docs (I’m talking BBS text files, user groups, and the such), where they insisted that if you want to be a real hacker and not a script kiddie, you have to be:
- A good programmer
- Understand network protocols
- Linux
- Human Psychology.
In DevOps, you have to have programming skills, understand how teams develop software, network engineering, operating systems, security, and then specific topics such as containers, PKI, logging, monitoring, and more. That’s a lot to cover.
And maybe it’s not that the number of topics we need to know is more extensive than in other fields, but more of how they spread over different domains.
So, where am I going with all of this? I suppose that you shouldn’t feel bad exploring different technologies and going down through weird rabbit holes.
Indulge your curiosity and start a side project with that thing you always wanted to learn.
Do you have to work with Kubernetes all day? Try to build a no-code application. The company that you work for is only using Serverless? Read a CCNA book.
There. Someone on the internet gave you permission.