Thoughts on Certifications
Should you stack up certifications, or should you learn something new? To put the question a different way: should Ethan get his CCDE? This week a couple of posts filtered through to my RSS feed that seem worth responding to on the certification front. Let’s begin with the second question first. This week, Ethan posted:
I think the first part of Ethan’s argument is valid and correct: there comes a point you’ve wrung the value out of a certification (or certification path), and it’s time to move on. But how can you judge when that time has come? My thinking is based around this chart, taken from one of the first posts on this blog:
The point is to intentionally target the middle curve for where you want to be. To quote the second article that caught my interest this week:
In other words, you need to know where you’re going and what sort of knowledge you need to get there. For me, right now, that means a PhD in Philosophy — learning isn’t just a hobby, it’s a path to something else. Whether I eventually go into teaching part time, or if I just learn more about worldview, culture, life, research, and writing in ways that help me as an engineer, then this is what I need to learn now. I’d like to develop, for instance, a certificate program in ethics in the engineering world that runs deeper than a few rules of thumb and some platitudes, or understand the intersection of Baconian Progressivism and technology in a way few people do (my proposed thesis, in fact, is in the area of privacy).
It’s the second part of Ethan’s case I tend to take issue with — the impression that the CCDE is a “service provider” or “large scale enterprise” test, and the implication the test covers skills that aren’t going to be useful in the “average network.” I just don’t believe in the “large scale versus small scale” divide any longer, nor in the “service provider versus enterprise” divide. Networks are networks; interesting problems are interesting problems.
The CCDE is specifically focused on a set of skills that will allow you to do successful design no matter what technology you encounter. The technology is nothing more than a framework for the skill set. Learning MPLS is not the end goal of the CCDE. Rather, MPLS problems provide a useful framework into which to pour overlay design problems. Maybe you’ll never encounter an MPLS network in your life, but you will encounter VXLAN, GRE tunnels, IPsec SA’s, and a host of other sorts of tunneling technologies. Tunnels are tunnels are tunnels are tunnels are tunnels.
In fact, I would argue that if you must learn any and every technology “in detail” to be able to design to it, you’re not doing this design thing right. Much the same way I would argue that if you must know every CLI command in the book to be good at troubleshooting, you don’t really know troubleshooting. Now I think most engineers know this somewhere deep down in their hearts of one’s and zero’s, but we’re so quickly overwhelmed with the bits and bytes, the octets and id’s, that we tend to forget it.
The way I see it is the CCDE teaches something completely different than the CCIE.* I don’t really know if getting a certification in some other technology — unless it’s really a completely different technology area — is what I would consider “broadening your horizons” once you get past the CCIE (the point made in Network World). The value of the CCDE, from my perspective, is that it intentionally teaches something different than every other certification I know of. It steps outside the “technology certification” mold, and focuses on a skill set.
When you consider a certification, don’t think about the technology the certification represents, think about the skill set and where that fits into your “pattern of knowledge.” This is the point we often miss in our scramble to get that next certification. Or even the next degree. I’m not trying to beat up on Ethan here, just pointing out what I’ve always said here: we need to be intentional about what we learn, and why we’re learning it. Doing anything else is just wasting your time in the long run.
Now, to go back to the beginning: should Ethan get the CCDE? Of course I think the answer is yes — but I tend to be a little biased towards the program. Perhaps even a little too biased. In the end, I’m not the judge of where Ethan is going in life and what his goals are, so I don’t actually know — Ethan is the only person who really knows the answer to that question. The first part of being intentional about learning is to know where you’re heading.
* I might be a little sensitive to this because the CCDE is my “baby,” and like most folks, I don’t think it’s ugly. But I don’t really think so — I tend to be pretty good at being objective about the stuff I create, even to the point of calling it ugly before anyone else does.
Russ has spoken from the olympus.
Ummm… Okay. Not really certain what this means. Can you explain?
Thanks Russ.
I want to offer a different perspective if I may. I think the main question is not about whether to go for CCDE or no. or whether to grow sideways or up. I think the main question/problem is understanding your goal. In your post “to know where you’re heading” is the final conclusion, a solution to the problem. I think knowing where to go is the biggest question/challenge. Most of us just drift with the flow making little effort to correct our direction. But even if we do attempt to direct ourselves one way or another, we still lack a clear vision of a final destination/goal. CCIE/DE are a good way to formalise a mid-term goal but not a long-term one. I fully agree that this can only be decided by ourselves but reaching this decision is the hardest part.
Thanks for stopping by and taking the time to comment!
“I think the main question/problem is understanding your goal.”
There are probably three things here, rather than one. The first is simply not knowing what your goal is. I do think this plagues a lot of people. The second is knowing what your goal is, but not knowing how to relate decisions like this one to that goal — frankly, this is a problem I have a lot of times. Even if I know what my goal is, I don’t always know how to achieve it, or I don’t fully understand the implications of any particular decision in the overall plan. For instance, if I have an incomplete view of the goal itself, or of the various options open to me, then I might go down a path I don’t intend, or I might not know which path to take right this second.
The third is another one that plagues my personal decision making all the time — deciding what it is I’m willing to give up to get there. It’s always a risk moving from where I am to someplace else; what if I make the move, and find I simply can’t get where I want to go? It’s easy enough to say, “try again,” but it’s not always so easy to work out of the situation. As much as we might like, there are no easy answers to this set of problems.
So I would agree it’s all about goal setting, but even that seems, to me, to be more complex than just “choose a goal and go after it.”
Interesting Insights Russ. But Let me argue about the path to “Design” in any technology is to spend some time understand the a pretty good portion of technical details behind the technology itself. Designing a car for example, requires a deep understanding of how a car is functioning and operating and the laws of aerodynamics and physics and things can fit together based on sufficient details . I agree on it is not about going very deep to the packet level to design end-to-end network , but I believe a sufficient details is quiet beneficial.
Thanks for taking the time to comment!
I would say that details can be important — the key point is answering the question, “which details.” To give you the classic answer — is it more important to know what the steps in BGP peering bringup are, or that there is such a thing, that it relies on TCP, and how to work with multihop and/or promiscuous mode peering? Both are details, but of different sorts. In the car example, yes you need to know the basics of wind flow, but you’ll probably have someone who specializes in windflow on a real car design team, or at least a wind tunnel to test these things in. You need to know realistic braking power capabilities, but you probably don’t much care about how the fluid runs in the lines to provide that braking power…
You only have limited amounts of time as a human to learn things. The key question is — are you using that time intentionally, or not? I’m no better, honestly, than many others — I spend lots of time learning things that don’t really matter in the long run, and not being as intentional about the shape of my knowledge as I should, so I’m not casting stones here. I’m just noting this is important stuff, and the less we (all) ignore it, the better engineers we’ll (all, me included) be.
🙂
Russ