I know numerous engineers who decided to pursue a career in networking because they didn’t want to deep-dive into programming. Will that change when the Software Defined Everything takes over the world?
Making a networking expert a reluctant (and potentially bad) programmer makes as much sense as over-promoting him and making him a suboptimal boss (some people, myself included, just aren’t good at managing others).
If you need a custom-tailored network automation solution, pair a networking expert (who knows what needs to be done) with someone with programming skills who can translate those needs into running code – the networking expert becomes just another subject-matter expert (SME) working with the programmers to document the business needs (of networking department).
Will the networking expert become part of the programming team? It depends. For large projects it probably makes sense to embed experts with networking skills into programming teams, for longer-term low-intensity development projects you might add a programmer or two to your networking team, or merge development and operations.
Regardless of the approach you take, remember that you should treat the network automation tools like any other mission-critical application – the network automation requirements have to be properly documented, the project prioritized, and executed using the regular project management and quality assurance tools to ensure you get what you asked for in reasonable timeframe (internal IT projects tend to stay in indefinite limbo as everyone works on more important immediate problems).
On the other hand, if you’re a generalist working in a small shop, then it’s high time you get acquainted with the automation tools, and learn a bit of programming – once you master scripting, your life becomes easier on multiple fronts, including desktops, servers, operating systems, virtualization, and eventually networking.
Jason Edelman published a blog post focusing on the same dilemma a few days ago. Definitely worth reading.