Learning to Learn

In network engineering, and really in all of the information technology world, a plurality of people didn’t learn their craft in the traditional manner. In most professions, we go to school, select a degree, then start at the bottom in the career we have chosen. While that is increasingly becoming the case in IT as well, there are a lot of practitioners who learned their craft on the fly, and have gone on to be successful despite the lack of a formal degree in computer science, or often with no completed degree at all. That is a result of the nascent industry we all saw in the 80’s and onward, as the world of IT really grew and became mainstream in almost every corner of the world. That has, however, brought with it some unique challenges.

One of those challenges is that we all tend to want to learn and study the things we find the most enjoyable about a subject or subjects. As an example in my own life, and this is a bit of a segue to be sure, I have taught myself four different programming languages over the course of my existence on this planet. Yet I find myself skipping the same subjects in each language—repeating the mistakes I have made in the past, carrying them with me into the present. Maybe for me, it’s that I don’t enjoy the basics of mathematics and loops, maybe I jump straight into the more complex topics. We’ll get back to why that is a problem in a second.

So if the free-form learning style of going it alone and deciding how you want to approach learning has its weaknesses, so too do traditional college classes. As an example, while college forces a certain amount of rigor in the process, and foists on us the discipline in the process that we might otherwise lack, the information you learn tends to be out of date by the time you graduate, leaving the matter of a degree merely the barrier to entry into the career world, while not necessarily giving you the current skills you need to be truly competitive. You will have a degree upon which your future endeavors may rely for stability, but you’ll likely have to hit the path of learning on your own nevertheless.

This is not an indictment of either path, only an observation on a couple of differences. Ultimately, if we are in the IT world as a generality, and network engineering in specificity, we have already overcome whatever barriers there might have been in our learning methodologies. Learning is a lifetime skill, and you will never become competitive, nor remain so, without constantly refreshing your knowledge. I would argue that everyone in every endeavor in their lives, whether professional or personal, should accept this… but the subject of personal development is a rich topical area and plenty of books have already been written. I’ll leave that for someone else to take on.

Now that we have established that both of paths that most of us in the field take to learn our craft have flaws, there does that leave us? To answer that, I’ll tell you a story.

A couple of years ago I was brought in as a consultant to help an IT team solve some nagging problems in their network. They had tried for some time to remediate the problems they were facing, but had only succeeded in slightly reducing the impact. The network was unstable, brittle, and management had not only noticed, but had become less and less confident in the leadership and structure of the various departments involved. To troubleshoot the network, and to ultimately solve the problems, would require cooperation from multiple disciplines in IT, but also a new approach.

In my first meeting with the team I listened to the problems they were having, and the impacts on the network and the business. When you remediate network issues you frequently have to operate within very confined maintenance windows, which can be hard to come by. You also put tremendous pressure on your staff and lower the overall quality of your services to the organization as you focus an ever increasingly disparate amount of time on troubleshooting. This eventually leads to things being missed, daily tasks and housekeeping not getting done, and an even greater potential impact on the network just from things being overlooked. So I like to spend some time getting a sense of the room, understanding that just by bringing an outside consultant in, longtime staff often feels threatened.

Next I moved on to asking questions as to what had been done to this point, what had been tried so far. And this is where I really began to see the trouble. The tasks that had been tried were, in some cases great, and in other cases not much more than throwing darts at the wall, wild-eyed guessing at best. There was no structured methodology to the troubleshooting, no documentation of what had been tried, and only a vague sense of what equipment had been changed in the process. Additionally, their logging was spotty at best, and only marginally useful to anyone outside the operations team in the NOC.

Without boring you with additional details, let’s just leave with the fact that I worked with their team to apply some best practices, and we eventually found and remediated the problem. But this illustrates the challenges we face in IT with either of the learning methods we discussed above. We can end up learning outdated information in order to get a degree that is stale as soon as we get it, or we can teach ourselves what we need to know, but end up with sizable, and critical, gaps in our knowledge. Either way can lead to the kind of fundamental mistakes, and lack of a disciplined approach, which contributed to the problems with the network I described.

The way we can overcome this as professionals is to develop a passion for learning. We must constantly strive to not only stay ahead of the industry as a whole, but to better ourselves in our craft. We also have to be honest with ourselves about our own weaknesses, and without letting them negatively drive us, work constantly on incremental improvement. It’s not always a perfect recipe, and we all have setbacks, but if we don’t strive for better, we’ll end up in situations like what I’ve described here. All the logging tools in the world are useless if we don’t know how to use them properly.