I guess it's that time of year again, where I'm starting to see the same discussion points pop up quite a bit once more:
"As a network administrator, do I really need to learn to code?"
"How much to I need to learn?"
"This will NEVER be in enterprise networks"
Well, today I'm here to give some thoughts. As with all my content, I reserve the right to be wrong or not 100% in alignment with everyone else's view of the world.
Do I need to learn code?
Correct, no one can make you learn if you don't have an interest in it.
Okay, but will I benefit from it?
100% yes you will. To what degree may vary, but I think it's worth a look.
Well how much do I need to know?
As the network architect might say, it depends.
Is automation coming for my job?
So what's the right answer here? It depends on what's right for you - what you're interested in, what you think will help you in your job, and what you think will help you succeed.
Yes, it's true that much of the networking industry has been shifting focus to automation & programmability. Open APIs have become much more important in recent years as we seek to expand our capabilities through custom code & integrations. I don't see this slowing down anytime soon.
But will that spell the end of the network engineer as we know it? I don't know that anyone can 100% say definitively, but I'm willing to bet that network engineers aren't going anywhere anytime soon. The role will definitely change & evolve over time (as it already has been, and will continue), but truly go away? I think not.
The benefits of programmability
I'm sure most people are familiar with a lot of this by now, but why should we care about automation? Well there are lots of reasons! For example, here's a few:
- Reducing human error
- Reducing time spent on repetitive tasks
- Accomplishing things that aren't natively possible in a product
- Adding custom functionality or integrations with other systems
- And more!
How much you should learn
This one REAALLY depends. To throw out some ideas, here are some factors that could help determine how much you'll need to know:
- How much you enjoy it
- How much your company cares or has any automation initiatives
- The type (and age) of gear you're working with
- Whether or not you have an in-house development or devops team
So on one side, I think that most people who get into writing Python & find that they truly enjoy it will likely end up transitioning to a more developer-focused role - whether that be a network-centric devops role or pure development role. Or simply just seeking out more ways to focus on programmability within their current network engineering role. These types of people are finding that they love solving problems & being able to have the creative freedom to write whatever code they want to accomplish a task. They've found something that they enjoy - Good for them!
On the other side, even if a network engineer isn't going to write code very often - just knowing the fundamentals can be hugely beneficial. For example, as a network engineer, have you ever had to learn how VMware works? Likely you didn't feel the need to become a VMware administrator overnight - but understanding how a vSwitch works has helped you support those teams. How much easier did it become to communicate with the VMware admins?
With programmability, it's much the same. If you're not going to dive in, that's okay. But you'll likely benefit from a good overall understanding of how things work. For me personally, it was easy to recognize the benefit when I was a network administrator. Application team puts in a ticket saying something isn't working right? Well guess who understands API calls, HTTP requests, and JSON/XML? It suddenly became much easier to help find root cause, and often easier to shift blame away from the network. Plus, when you speak with an application/development team & you can use their terms, they feel like you understand them. This helps reduce friction between teams. In my experience, what I found was that those application teams would then ask for my help more often - because I was willing to go further than "checked the firewall, it's not the network".
In my opinion, whether or not you learn to code & how much you learn comes down to your goals. Can you keep being a network admin & avoid code? Sure - just like you could continue being a network admin & never learn design, business goals, or what other teams in your company do. But will learning those things expand your knowledge & give you a better big-picture view? Yup. Would learning those things give you an advantage? Absolutely.
What happens when you run into a difficult challenge where manual effort would be reckless? Maybe you pass off the job to a development team to write a utility or some custom integration. But guess what happens next? That development team doesn't understand how your network gear operates. Again, this situation really benefits from having an individual who can speak both languages. Even if you don't understand functions & classes, you might be able to read API docs for your network gear and help guide the developer through where to start.
What about that in-between state? Maybe you want to learn to code a bit, but not 100% of the time. What then? Well, could you pull & terminate ethernet cables without a cable tester? Yes, but would you be more efficient with one? Also yes. Similarly, being able to code can just be as simple as adding another tool to your skill set. Would you automate a single port change? Nope. But what if you find yourself making that same port change several times a week? That's when you pull out your Python skills and write a quick script.
And for those who would rather just not do any of it? You're fine. How many parts of the Internet still run legacy protocols? Someone has to support that. And there are companies out there who want commercially supported products, so they have someone to blame. Vendors know this, which is why we end up with big, centralized controllers & complex GUI apps to help slowly pull networking out of the CLI days. But you can't tell me that SD-Access, ACI, or EVPN are simple technologies - companies will still benefit from employing people who understand the underlying technologies & protocols. Let's be honest: automated or not, things still break - and someone will need to have the knowledge to fix it.
So what's the answer here?
It seems like these debates continue because everyone comes from different backgrounds & has different experiences. Some people work in companies that would never entertain the idea of custom code, where others may find their team being pushed to become more agile & learn Python to automate tasks. Neither approach is wrong, but of course our human instinct is that we have to assert that everyone else must be wrong, since their view doesn't match ours. The world is never a one-size-fits-all for every situation, yet for some reason we're all inclined to think it is.
All that being said, companies are going to adopt this stuff at different paces. Some find immediate value in it now, and some are scared or just set in their ways. Again, neither is wrong - but they both have their own advantages & disadvantages.
And that's why I say - if you don't want to learn any of this, you have nothing to fear. There will always be organizations at different stages of the cycle.
But if you do learn? At worst, you gain knowledge outside of your primary domain. At best, you gain a new tool to leverage & find ways to improve your work.
At the end of the day, you have to focus on what's right for you, your career, and your current employer. And that answer is going to be different for everyone.