4 kinds of knowledge every IT professional should possess
Over the last few weeks, among other things, we’ve talked about refocusing your career around solutions, and that’s a wonderful top-level mind-set to have. However, over the years, I have learnt that a career is divided into two distinct parts: the first being, the goals we set for ourselves, our career milestones, and all the many exemplary achievements that become our CV’s selling points. The second part involves the little things we do every day, the repetitive tasks, the mundane chores, and the many small acts that in themselves don’t seem like anything, but add up to form attitudes, habits, etc. Everyday we learn about new things, or improve on the knowledge we already have about something. And in my experience, this knowledge can fall into one of four categories:
Knowledge that builds our conceptual understanding of a technology: This knowledge is mostly the theoretical stuff, the definitions and abstract explanations of how something works without necessary telling you how to set it up. Think of the concepts of Switching and Routing, and how a traffic stream flows from a sender to a receiver and the many decisions made in between. Knowing all this doesn’t directly give you the ability to design networks, BUT, it gives you a fundamental knowledge that allows you to piece together why something works as it should.
Knowledge that aids us in designing a solution: So, after understanding how something works, the next step is to understand how to deploy it. Again, using the analogy of a network, all that knowledge that allows you to plan out what IP ranges you’ll use, how large each subnet will be, where to place your L3 functionality, your bandwidth requirements etc, falls into this category. Will I deploy MPLS or simply go with a WAN accelerator? Will I deploy SNMP, WMI or JMX? Each of these decisions ultimately drives us to design conclusions like: “because the problem is ABC and the environment is DEF, taking GHI and integrating it with JKL and MNO is the most scalable, and reliable method of achieving PQR”. This kind of knowledge, like the previous, is not about details, but about a logical representation of what a solution could look like.
Knowledge that allows us to better implement a solution: Quite often I see this kind of information as more of a subset of the design process than something of its own. Because, it feeds into the design process when questions of interoperability, simplicity and reliability have to be addressed. This category of knowledge is where all those “how-to” approaches belong. This knowledge for me is a lot more linear, methodical and clinical as all errors manifest themselves in failures, crashes etc.
Knowledge that helps us maintain and troubleshoot a solution: When I started out in my career, I gauged my expertise on a particular technology based on whether I could or could not configure it, and therefore, setting up an IDE and writing an entire console application made me feel like a pundit, until I was first asked to help optimize code written in C for an embedded system. I hadn’t written the code, and more importantly, this was code that worked just fine. So, how do you find a problem with something that is not exactly broken? I later learnt that the relationship between an operator and a basic data type is not the most efficient, or that reusable code can be expensive depending on how many times it is called, or that loops like for(v=0, v<25, v++) and for(v=25, v–), although achieving the same results, have significantly different resource requirements, And of course these are very simple truths, when you’re looking to answer questions like “why is it slow?”, “why is there a latency?”, “why does it randomly crash?”, these little details make every difference.
Over the years, I have learnt that concepts never change as much, therefore, once you’ve understood them, improvements to technologies are minor revisions that can be summed up in a weekend’s worth of reading. As for design knowledge, it’s as good as a “job on training”, we might know how we want to solve something, but variables are always changing and as user’s feedback to us, we continue to tweak our initial designs, improving our efficiency over time. However, implementation, maintenance and troubleshooting, are often full of unknown results, and personally the bulk of my time at work is spent answering questions around why I ended up with a result that’s not consistent with my designs. Therefore, my notes on these last two have endless threads of revisions outlining the myriad outcomes and how I arrived at that them. #ICTZM
