This week I was reading through various RSS feeds, and ran across a couple that fell within the scope of last week’s topic. So, rather than moving on to more practical concerns, as I had planned to do — well, I thought I should respond to some common lines of thinking.
First of all, the IT space is in constant change, and the speed of change is just increasing. That change manifests itself in new technologies coming about, and new processes associated with the technologies. Secondly is work experience: What you’ve done in the past is not necessarily useful for the future. Like in the financial realm, where it’s recognized that past performance is no guarantee of future performance, it’s also true in the work environment. When you look at past experience, it’s already dated, from a technology perspective. –IT Business Edge
Now, I’m not one to argue with the idea that the IT world is always changing. Certainly new technologies come, and old technologies go. As the saying goes, legacy just means what you’re currently installing. And certainly there will always be a need to learn the new language, the new command line, the new hardware choices, the new performance numbers. I don’t want to start a war, or pick on someone, but… I’m going to disagree. My first grounds of disagreement will be covered here, my second in next week’s post (because I just looked, and this post is 1100 words! Yikes!)
The article makes the point that the IT world should be more like the assembly line world — there are some people who design the cars, and some people who make them. There are some people who need to be able to create new algorithms, and others who just need to be able to use them, to put it in more IT terms.
A four-year college degree is useful, for example, if you want to get into the depths of designing algorithms, or writing complicated code that is close to the operating system, or writing programs for distributed processing, or if you want to come up with a new search algorithm. That might require a college degree.
To a point, the point is well taken. But I don’t think it’s really as simple as that. The image being set up of manufacturing is one of people who have a specific skill set to run a particular piece of equipment, but they couldn’t actually design the stuff they are building. I, for one, think this is a false picture of how the world really works. I’ve known lots of carpenters and builders in my life, lots of machinists, and lots of coders. I really don’t think that any of them involve the sort of “low level work” we’re implying here. There is a lot more room for craft and creativity, for theory and application, in the everyday life of the average carpenter than we’re giving the job credit for. If you don’t think that’s true, please, frame up a house, or work with a crew framing up a house.
But even if this were true, I don’t know that it applies to the information technology world. In such a virtualized world, the ability to abstract and to understand is always valuable. I’ve never met someone who doesn’t need to understand algorithms and how they work anyplace in the networking industry. Even folks who “just want to do hardware,” need a lot more than learn a high school level skill set and move on.
There is a second point missing here, as well. Let’s turn the question around a bit — how do I stop the firehose? Given that technology is such a fast changing field, and given my current skill set has a half life of 2.5 years (and maybe less), what do I do? Do I go out and retool every 2.5 years? Maybe when you’re 24 and single, this is possible. Not when you’re 60, with kids and grandkids, and are part of a real, thriving community outside of (or even inside) work. How do I solve this problem?
Let me ask the question another way: how have structural engineers resolved this problem? The solve this problem by learning the problem sets they must deal with, then learning how to slot new technologies into those problem sets. We really, really, want to believe that networking is different, that we are special, that we’re always facing new problems that need to be solved. Let me give you a hint — from TAC to Escalation to Principal Engineer, I’ve never met a new problem. I’ve met the same sets of problems at different scales, in different ways, and at different times. But new problems? They are really, really rare.
The only difference between network-focused yammering and the rest of the IT is that everyone else learned to live with the reality instead of claiming that their domain is so broken that they’d have to reinvent all wheels ever invented (although on a second though I’m positive you can find apocalyptic claims in every IT domain).
Let’s look at how other branches of engineering have solved this problem and learn. Yes, there are 5,892,465 different CLIs out there (yes, I’m guessing). Yes, there are hundreds of tunneling protocols. Yes, there are tons of features, and tons of forwarding planes, and… But they’re all solving the same basic set of problems with the same basic set of tools. Which brings me to this point:
If there’s one thing we need to learn how to do, it’s to abstract the principles behind the problems and the solutions, and learn to see and recognize those principles in the problems we face, and the solutions offered. I’ve talked about models in other venues — I cannot emphasize enough the importance of learning models and modeling languages. I cannot emphasize enough the importance of learning to see — to see the patterns in technology, both problems and solutions.
So I don’t believe that we only need a degree if we’re going to “go on to advanced calculus,” or whatever. We can get so wrapped up in the content of our thinking that we forget we also need to know how to think. When considering a degree or a certification, these two ideas must come into your calculations. Don’t overestimate your ability to think because you have a lot to think about, and don’t underestimate your ability to think because you don’t have a lot to think about. I cannot begin to express how much logic and discipline in thinking I’ve gained by going after what many folks would consider an orthogonal degree in theology.