By Roger Perkin, IOD Expert
The short answer to this question is “not really,” but they do need to be aware of the developer tools that are available and adopt a developer mindset.
Let’s explore why.
The way networks and network devices are administered has not really changed very much in the last 30 years. Most network engineers are doing it the same way they always have.
Telnet, or more recently SSH to the command line interface (CLI) of a network device, issue a show command or a configure command, save the config, and log out. The configuration would then be stored on the engineer’s laptop or in a central folder with a naming convention like switch1-config-v2-change293fix.txt.
This process is repeated on every device they want to configure. This process if fine if you only have a few devices to administer, but what if you have 1000 switches to make a one-line configuration change to? If the one-line configuration change takes 30 seconds to perform, then 30 seconds x 1000 devices = 500 man hours to make one change! This process is prone to human error and when configuring multiple devices is very time consuming.
There must be a better way.

Enter the World of Network Automation

Using programming languages like Python or automation frameworks like Ansible, network engineers today are starting to adopt developer mindsets and treating their network infrastructure as code. Utilizing tools like Git & Github for version control with the focus on creating consistent and repeatable deployment models, they are treating the network as a single configurable entity instead of a collection of single appliances.
With project requirements getting more time-critical, the ability to bring up network infrastructure in a deterministic and repeatable manner is becoming a standard requirement. Cloud networking is also advancing at a rapid pace: you are no longer configuring your own physical switches, but a provider’s virtual switches or routers.
So with all these advancements in network administration, do network engineers have to be become developers?
None of these tools or mindsets are a new thing: server administrators have been managing their infrastructure in an automated way for many years and developers have been writing code for a lot longer! What has been lacking is the transition of the network world into the devops mentality, currently referred to as NetDevops (Network Development & Operations). Companies are already automating their infrastructure with their engineers thinking like developers, but they are still in the minority.

What Is a Developer Mindset?

A developer mindset means a network engineer needs to start thinking about repeatable tasks that can be automated and developing the code once to make that happen many times, instead of repeating common tasks over and over.
Now with all this talk of code, a common fear is that you have to become a developer or programmer, but with tools like Ansible–Puppet & Chef are also being used, but Ansible is becoming the standard tool for network automation–you don’t need to learn to code, but just learn how to write playbooks. A playbook is a list of tasks that are run by Ansible to make network changes or discovery tasks that can pull information back from your network. You don’t actually have to write in a programming language.
Ansible playbooks are written in Jinja2, a human-readable language that makes it very easy to get started with automating your network and very easy for anyone else to read and understand the changes that are being made.
Some would argue that network engineers are already coders in that they configure devices using the command line language of Cisco or Juniper, which may be seen as a coding language, but it is not a recognized software development language like Python.
With all that said, there is nothing stopping network engineers from becoming developers and learning Python; however, to use Python for network automation tasks, the level of coding you need is not that in depth and one would argue that a Python developer writing code for a corporate application is more of a coder than a network engineer running a few simple scripts.

Will Engineers Automate Themselves Out of a Job?

The big fear is often the fear of change: specifically, that by automating daily tasks, a network engineer will automate themselves out of job. This is not the case.
Most network engineers never have enough time to actually focus on the work they really need to do, which is optimizing and re-designing the network, deploying new sites with standard configurations, and improving performance. Instead, they spend their day ploughing through endless changes to keep up with the demands of the business. They never have enough time to ensure every network device is compliant with corporate standards and that every device in the entire network is configured to an approved configuration.
By using network automation and thinking more like a developer, network engineers can take the labor-intensive tasks and automate them giving them more time to focus on the more interesting parts of the job.

Network Engineer With a Bit of Developer? Or Developer with a Bit of Network Engineer?

This is the chicken and egg scenario: who came first the network engineer who likes to write code, or the coder who likes network engineering?
The most common route of entry is the network engineer who likes to write code, typically an engineer with many years of experience who realizes the benefit the developer mindset can bring to their job. However, there is a problem here in that the speed of adoption into solid developer best practices is usually slow.
The other route of entry is a developer (someone who has been writing code for many years) with solid experience in programming languages like Python or Ruby and developer tools like Git, Github & Jenkins. But they have zero experience as a network engineer.
They are being told the requirements and asked to develop code without any real appreciation of the live network operations. Developers who are moving into the world of network engineering, though, have a massive head-start on the network engineers in terms of code development and are learning (or being told) just what they need to configure for.
The final point of entry is for a new network engineer who has no knowledge of network engineering or development.  They will not know any different and will start learning both and will probably wonder why the network engineers of today have taken so long to move into the new world of network automation and the developer mindset.

How to Get Started

So how do you adopt a developer mindset and which tools should the network engineers of tomorrow start learning? The way to get started is to begin with small, low impact tasks like taking config backups and storing them in version control. Here is a great tutorial on taking a backup from a Cisco router using Ansible.
Then for version control, Git is the go to solution. Check out this great self-hosted Git solution. 
The next step is to develop configuration templates. These enable you to easily deploy new sites without writing all the configuration files from scratch and also creates a corporate standard for configurations. This supports configuration compliance and security compliance.
Once you have a standard configuration template and you have defined how all your network switches, routers, and firewalls should be configured, you could  then prevent changes to these devices from anything but the automation platforms and then enforce compliance.
A typical use case would be to deploy the standard configuration to your network infrastructure on a regular basis (typically every 4 hours). Any unauthorized changes would be overwritten and reported on. This also leads nicely into security compliance, ensuring that all security best practices are defined and applied to every device.
Finally, when you have confidence with these operations, you can start to push live changes to devices during the day. (Typically, network changes are completed late at night by bleary-eyed engineers being asked to configure multiple devices with the same change.)
Once the process is stable and predictable, this way of working would be the standard practice for network configuration changes. This is the new world of network automation where you can trust your network administrators to think like developers.

Conclusion

While NetDevops engineer is quickly becoming a more common position, there will always be a need for someone to configure the network the old way. Network engineers are not going to be replaced by computers, but if they want to safeguard their career and really embrace what the future has to offer then learning some devops tools and looking towards a developer mindset is going to build a great foundation for their future.