NAE: Some Help Dealing with Brain Block

For years, thanks to the gift of misaligned perception, I’ve been mentally blocked. I’ve avoided things like Machine Learning because my perceived skill with mathematics is weak, avoided programming languages like C# because the perceived uphill hike to get familiar is high and avoided front end web development because of the perceived browser nightmares.

Technology has come a long way since I last touched C# and web development and there are some great ML libraries out there which minimize the requirement for hardcore mathematical skill sets. My perceived problems have remained yet the actual blockers have moved and morphed. I’ve lived on old ideas without re-grouping and forming a refreshed attack. More on my foolish ways later.

For many people and organizations, it pains me to admit that perception of network automation is also misplaced. It spans from “Ansible is the answer, sorry, what were you asking?” to “Python will save the day”, following “The automation is the design!”.

Ivan Pepelnjak as usual has wrote some great content on topic as per usual. Read this post for a rather targeted view on expert beginners. TL;DR: “I got hello-world working for one tool, me now expert”.

Currently I also have a particular bee in my bonnet about terrible design. Severely lacking approaches can be explained through the lens of the psychological manner in which network engineers have traditionally learnt and approached problems. We’ve all been guilty at some point of hacking away at the CLI to get some routing protocol feature working, or to get a dodgy network design stabilized. A new RFC comes out and everyone seems to download a new virtual appliance or operating system patch to introduce it, then hack the thing to death to test. How many of you consume the RFC first, then assess the suitability of your $vendor patch to get the job done? Do you even need it? Network automation is one of those things that is design first and considering tools should be much further down the line once your opportunity is truly understood.

Couple the absolute desire to automate daily, business-as-usual and mundane tasks, with the human need to free up activities during unruly anti-social hours, with the demands of your managers and bosses against the ever-shifting landscape of technologies, breathe and what you get nothing more than deadlocked and really frustrated. As the ways of learning networking do not really compare well with learning automation, network engineers are becoming increasingly stuck when it comes to picking up new skills. It’s not that the community cannot do this, but I believe it’s the way they try to do this.

Recently, our household has got a new arrival. That’s right folks, a bouncing baby Beagle puppy!! The hardest thing about having a puppy is constantly comparing the puppy to a human and getting bent out of shape when the puppy doesn’t behave in the manner I expect or desire. Once I remember he’s a Beagle puppy and start thinking Beagle, his behavior and how to control it makes much more sense. Learning network automation is a different kind of puppy to network engineering, although they both share similar traits like distributed-ness.

Another reference story here, but when I want to learn a new programming library, feature or trick, I create mini scratch tests. Things that exercise the $thing and provide me knowledge. I then take that knowledge further and use it in a project after I’ve explored. One of the huge issues today is, exploration is short and the expectation is because of the familiarity of language and culture, that network engineers should pick this stuff up quickly. Managers assume because it has “network” in the title that it’s a short step away from network engineering and needless to say, it is not. It’s a whole new skill that is both laid over and adjacent to network engineering. Add in to the recipe the mountain of technology that is glossed with marketing and political grade misdirection, standards that aren’t quite standards and moving landscapes like programming language updates and sketchy support, brains are at an all-time high of locked. As a side note, this Tweet I saw from Frank Schroder was right on point on my train journey whilst writing this!

Automation stacks are composeable, they are highly configurable and thus can be fragile. The safety of a static set of network protocols to configure are not present by default and such, the learning curve is compounded by having to know how to build the stacks and explore the stacks. Knowledge in the industry is gathering and whilst automation will never be wholly driven by a single vendor, a combination of materials will realize a wide and deep education.

Close

The best way I find to learn a topic is to do it little and often. Read a bit, experiment a bit, reflect and repeat. With automation, it’s no different. NRE Labs is a platform that allows you to explore technology and tools, exercise them in a meaningful way and without the uphill battle of figuring out how to install them. NRE Labs provides this experience in the form of lessons. These lessons bring back some of the joy of experimentation from shortened feedback loops. No dodgy install error messages and frustration from having half built environments all over the place. The team behind NRE Labs did a great job here for the better of our community and I for one will be contributing lessons as soon as possible!!!

• Tags: Automation
• Categories: Automation