Trusting in Non-Linearity as the FNG

I’m officially two months in at Salesforce.com and it’s really kind of neat to be in a non-telecom environment for the first time. I’ve had to really get settled with the idea that I am not going to be “fully productive” or feel the confidence of “understanding the unique value that I own” in my place of work for some time. (I’ve known this all along but getting the gut to catch up with the head is hard work sometimes.)

This is the plight of the new guy. There’s just too much you don’t know and the only way to get to know it is to buckle down and start doing stuff… probably badly. There are three things I am trusting here. I have trust in myself because I have managed to become top-tier effective wherever I have applied myself. I have trust that my team is going to give me the feedback I need so that I can work with them in a way that is congruent with the goal and with their work in progress. And I trust in the non-linear nature of this kind of learning.

What do I mean by non-linear? Don’t make too much fun of my “line”. I was too lazy to use a straight-edge but not too lazy to use a scanner.

Anyway, I trust that as I apply myself to my work, the things I learn will gather, have sex in my brain, and multiply such that I can understand much more than two times what I can understand today when we reach the four months mark. And, hopefully, that translates into smarter results, better output which factors in the many requirements from our many constituents and clients.

“Using a human-to-machine interface for machine-to-machine communication is rarely a good idea.”

— Carl Moberg of Tail-F at Nanog 61

Shared Thoughts on the Path to Network Programmability

I wanted to share a really well written blog post that is based on a presentation about the evolution of Network Programmability. One of the things I tend to like about a strong presentation is that it covers enough history and current context to make the content relevant to its audience. The writer of this article does that amazingly well. I’m glad to share it since I agree with much of what he said and it dovetails with my thinking on the subject.

Here are some of the points summarized: - We need a new model. We need to put into place a methodology that allows us to interact with the network in the same way that we design it. - Purchasing products or building solutions that do the [high level abstractions], without a mastery of [fundamental technologies],.. will inevitably result in failure. - At scale, repetitive tasks are the not-so-silent killer…. These repetitive tasks tend to occupy a lot of time, mostly for those whose time is really valuable… These tasks are prime candidates for automation. - Some kind of centralization will win out. - No, you do NOT need to become a programmer, but you can if you truly want to. - “The truth is that we don’t need all network engineers to learn code. We need network engineers to solve networking problems. We also need a smaller subset of these folks to tackle the problems in existing tool sets and getting the networking discipline to understand how to improve processes for the better.”