I have to admit, this second post is not as technical as I would prefer, but something that is on my mind a lot. How do we know what we know? How do we constantly work on what is as essential to us as air? Is it the same for everyone, or is this just me being an outlier and weird?
I’ll start with something useful.
USB drives, jump drives, flash drives, whatever you’d like to call them are cool. They are everywhere. Cisco kit has included USB ports for a long time as a useful way to move firmware and configs to/from devices. I’ve used them for a long time. Unfortunately, I had a $10 8G drive that worked fine in laptops, desktops, windows, BSD, and Linux computers but could not be recognized on a router I was working on. I tried several different kinds of formatting, on different Routers, Linux, BSD, and Windows.
Diskpart & Clean were the solution (in a Windows environment). I ran Diskpart, and then selected the “clean” option.
The reason I found out, was a guy working next to me had a different piece of equipment in a previous job that didn’t recognize a usb stick. Just a bit of luck. If I had another guy sitting next to me, I may have never found out. I may have tried a different USB Stick, had it work, and just blamed the manufacturer.
On another occasion, I wrote a Java program to help out with a special kind of modem. The modem stores most of the configuration parameters in a 224-char long string. The Transmit Frequency, for example, was always 9 chars starting from position x and going to position y, with a “.” in the middle. Techs would frequently use excel, notepad, word, or any number of other tools to compare one string to another and make changes. One of the engineers did a brilliant job with excel macros that made it the best tool for creating configurations. Unfortunately, it didn’t decipher the meaning of an existing string. I decided to write a Java program to help with that task. The program functioned (when people had appropriate permissions to run a Java program).
I did have some error messages that cropped up when I was compiling it. I had used global variables. I did not use getter and setter methods correctly. I looked for someone to explain the errors, but couldn’t find the right resources. The answer to this problem happened in my coursework, during a Java Programming class. To be honest, this was my second Java Programming course. My first one was ten years before the second. I am sure we covered it in both courses, but I did not know enough at the time to recognize what the error meant and what the proper fix was.
My third example for this post is when a tech was trying to troubleshoot why his computer was having problems getting to a modem. I looked at the IP config settings and said, “Your subnet mask is wrong.” It was automatic. I just knew. I had done enough IP allocations to just know without any effort that it was wrong. If you play cribbage enough, you know that a double-run of three is 8 points (at least) and just by looking at certain groups of cards, you know how many points the hand is without counting.
My fourth, and last example, about knowing stuff is a work in progress. I have a hundred examples. I want to know and understand something, and really grok it. So I go out looking with the intent of solving a task, fixing a problem, or doing something I think is cool. It doesn’t have to be daunting, but simple tasks don’t usually require driven intense focus or desire. I am going to learn how to set up a 4g connection on a router, in such a way that I understand what and why I’m entering each command. I wanted to know what words I could spell in hex (ipv6), so I started to learn python to write that script. I want to know how MPLS works, and even though it is a long way off, I have purchased some books and go about trying to understand what I can as I go. When we pursue knowing stuff with driven self-determined intense intention, it is a very different experience to stumbling across a fact and tucking it away to use one day. Getting stumped on this track is a lot more painful as well.
A recent Packet Pushers podcast (show 242) mentioned training in the current class of router analysts. Many people skill up to get their certification, but lack the direction to keep going. Three/Five/Ten years from now it will be a different world. It is a constant moving target. So whatever it is that we decide to do, it better be what we enjoy doing. Also, how do we know we are directing our efforts in a good direction? For me, it is a lot of work (although it is fun) in and out of work hours. I know the environment will be changing. I know I do not have the psychic gifts to know exactly how it will change. So far, I have been trusting in my studies when one thing dovetails into another, it is worth giving it a look. Like how ACLs tend to lead into QoS and policy based routing.
I was listening to the Code Newbie podcast, Episode 41, with Sandi Metz. Not a direct quote, but my best take-away from the podcast was: The problem is that it feels like the knowledge I possess seems totally obvious. Anyone should be able to get the knowledge that I have. But the knowledge other people have is a total mystery, especially how they came to acquire it.
A lot of people, myself included, tend to underestimate the effort we have put in and miracle that happens when something filters through from a thought and becomes a foundational block in how we understand the world. The post started out titled “knowing stuff” because what other people know is always perceived as somehow being different to what I know. It is really about “learning stuff”. There are so many ways by which we come across the knowledge we rely on. Sometimes it is accidental or serendipitous learning. Sometimes we learn for a course, certification, or work task. Sometimes we learn things in a completely unrelated area to our profession, but bring in analogies and systems to our design tasks. Sometimes we are totally driven by a need to know how something works; or a need to make something work in line with our design vision. Knowing stuff starts with learning stuff. We can’t depend on accidents for our knowledge. There are some reliable ways to direct our efforts. I am sticking with tracks that look to provide long-term interest, enthusiasm, and passion. That is the only way to keep the energy that makes this fun and prevent getting burned out.
Sorry about not enough technical junk in this post. My next one will be better. The Design and Build (Packet Pusher show 244) about dual stacking IPv4/IPv6 had me wanting to write down and research some more. Specifically, about IPv6 ACLs that address the perceived security benefit of NAT. I can see a Visio coming up too. Thanks for reading, if you made it this far.