Why did NetEng's evolve to drop coding skills?

[Chris Young]

In an effort to try and understand the present and predict the future, I'm hoping for some opinions on the past. :) 

From what I can tell, up until about 1998-1999, Network Engineers were all capable of some scripting. All of the old timers seemed to wander around with some cobbled together perl script that helped them automate basic tasks. As a point of reference, I would put this approx at CCIE 10K and lower. 

In about 1998-99, it seems that our evolution took a turn and we decided, as an industry, that those skills just weren't necessary anymore, and so any coding skills, for the most part, were pruned off the network engineers collective tree. There were exceptions of course, but for the most part, NetEng's have been able to get by for years without any programming skills at all. 

So now we're back to the point where we're discussing whether or not we need these skills back and I'd like those who were around at the time to try and shed some insight as to why we collectively decided to prune these skills in the first place.

Any one want to chime in?

@chris_young

[Nick Buraglio]

I had to learn what we called "sysadmin scripting" to manage the Unix services that supported the network, this basically consisted of hacking existing open source tools, writing shell and perl scripts to make my life easier. Radius, dhcp and specifically DNS were absorbed by the network engineers because if they broke it made the network look like it was broken. 

This is around the same time that enterprises really started realizing that the Internet wasn't a fad and enterprise compartmentalizations came to be. The systems were run by systems people, same for the network, security didn't really exist in most places yet, it was generally done by either the network or systems teams. 

It was now possible to be a network guy without knowing Unix since a lot of enterprises used windows or Novell and not Unix, and Linux was far to green, fragmented and unsupported. It just moved on like that for 10+ years. 
--

nb

--
You received this message because you are subscribed to the Google Groups "network.toCode()" group.
To unsubscribe from this group and stop receiving emails from it, send an email to networktocod...@googlegroups.com.
To post to this group, send email to networ...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/networktocode/e160a22e-93e7-4fe5-ba7a-b83047f9c3d5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Paul Fischer]

I think some of this has happened with all the IT siloing that has happened over the last 15 or so years. When you segment your staff under a technology discipline people will tend to focus on that technology and not branch out and learn how other technologies are managed and deployed. If you are a Unix admin it was really just another part of your job to learn how to script because the OS allowed and in fact encouraged it. Your job would become much easier and less tedious if you could write some good scripting to automate some tasks. 

It is only recently in the network world we are seeing this kind of trend. More open operating systems, open APIs and external control from a number of other automation systems. I love the fact that some network vendors are simply using OPEN and unmodified Linux on their switches because it allows control of the same toolset in the backend. I can now control my servers, applications and networking with the same provisioning, deployment and management systems. I only see this trend continuing which will really accelerate the push towards automating everything.

If I would give any advice to someone that wanted to start in the IT field today i would say learn Linux and the tools/languages that are built around it. 

[Christopher Young]

Hi Paul,

Taking one comment out of context. 

I can now control my servers, applications and networking with the same provisioning, deployment and management systems. 

I guess I still have problems deciding whether or not this is actually a desirable goal.  Servers, apps, storage, networking, virtualization evolved in separate streams for a reason.  I'm all about bringing them closer together and increasing the overall glue between the silos and the practitioners, but I question whether using the same provisioning, deployment and management systems is actually  

A) a good thing and will help streamline and simplify

Or

B) apply a my-way-is-better paradigm where the Linux professionals will be the only ones happy since the other tool chains are dropped 

I think the reality is that there will be a longer term tool chain evolution here where the Linux management tools will evolve to deal with more network centric management domain problems on Linux systems. Linux as the network OS will evolve in network centric instrumentation, etc..  And we will all find something new to pontificate about :)

But the short term leaves me wondering if the white box Linux network pros will be left in the cold without the tools they need to do their jobs. 

@netmanchris

--
You received this message because you are subscribed to a topic in the Google Groups "network.toCode()" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/networktocode/ae8LlURuqls/unsubscribe.
To unsubscribe from this group and all its topics, send an email to networktocod...@googlegroups.com.

To post to this group, send email to networ...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/networktocode/17360c1a-1e02-4f45-bc35-6537a65862b2%40googlegroups.com.

[Willard Dennis]

Hi Chris, et al,

I think there will always be "subject-matter experts" in different IT domains. The trick is, to understand/empathize/effectively-work-with the other SMEs in different IT fields. It's all a part of the same business value chain, right? Anyways, knowing the other teammates tooling is surely helpful. If I can't talk about Python, Git/SVN, Gerritt, Jenkins, Jira, etc. (to at least a basic level) then I'm going to have a hard time talking to the dev's on their level. If the server guys are using Linux as the OS, and deployment/orchestration tools such as Puppet / Ansible/ Chef / whatever, i think I should explore how it might fit my workflow as well. or at the very least, learn the basics of the tool so I can effectively talk to the server admin folks. If I *can* use the same tooling to do my deployments / changes, then we really can start to integrate and collaborate effectively. I guess I wouldn't try to force a tool into my workflow if it's really not a good fit for what I do, but if I investigate it and it can work, then I think tool comminality would be a good thing...

My $0.02,

Will

[Marius Cornea]

Hey guys,

I was writing this post[1] about setting up a basic OSPF lab by using Ansible and I was thinking why wouldn't you use these tools. Probably the opensource toolchains require pretty much development in order to get them integrated into production setups and I don't think there are many guys out there willing to take responsibility for something they do not master. 

But what about test environments? I'm pretty sure everyone needs a testing env for trying some functionality or getting prepared for a certification. How about starting using them in these kind of environments? Since there are many virtual networking appliances provided by vendors I guess you could get a setup similar to production running in a virtualized environment. This way you could also eliminate testing on production. I'm sure one will see the advantages pretty fast and want to go deeper in the subject. 

I think that in order to get more and more people interested in these tools the community should provide tons of examples of how to do stuff and that's what it's lacking now. 

[1] https://remote-lab.net/ospf-lab-provisioning-on-ios-with-ansible/ 

( any kind of feedback would be really appreciated :) )

--

You received this message because you are subscribed to the Google Groups "network.toCode()" group.

To unsubscribe from this group and stop receiving emails from it, send an email to networktocod...@googlegroups.com.

To post to this group, send email to networ...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/networktocode/3f2523d3-ee02-4030-88cc-e04885f4fe68%40googlegroups.com.

[Jason Edelman]

Hi Marius,

Really nice work here!  Agree totally that starting with labs and dev environments are always a great start.

Thanks for sending it out.  I'll be going through this in more detail very soon!

-Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/networktocode/CAE7X1kbh0%3DBOw%3DGWcUy0bp-YGCLP2EyZUxpw8j_P934u46uugg%40mail.gmail.com.

[Pablo Lucena]

Hey Marius,

Awesome post man! I like the creativity =) 

On Thursday, February 19, 2015 at 6:15:19 PM UTC-5, Chris Young wrote: