EDUCATION
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.
It’s About Time
I guess I’m semi-famous. Or maybe I’m a moderately sized fish in a rather small bowl. Whatever the reason, a lot of people reach out to me for career advice. Which is okay, of course — I make it a personal policy to answer every email that’s addressed to me, individually, that I receive. It only takes a minute or two, after all, and it drives me nuts when I send an email to someone that seems to go into a black hole. I try not to be the person that drives me nuts. 🙂
So a couple of times a week, I open my inbox to find either an email or a message through some social network (the only social networks I actively use, by the way, are Twitter and LinkedIn, so if you friend me on Facebook, or send me an invite to something else, I’m not likely to accept) asking some variation of a couple of questions. The one I want to address in this post is probably the hardest to answer.
How can I become an architect/really good engineer/really good writer/really successful/etc.?
The snark inside me just wants to answer, “just change your title on LinkedIn, that’s what everyone else does.” But as funny as the snark is, it’s not really helpful when someone honestly wants to know. So let me try to give you an answer here that might actually be useful.
To become any of the above, act like a duck.
Okay, if you’re still reading after that one, you deserve an explanation. How can you act like a duck? We used to have this ritual we used on first time campers in my Scout Troop. They had to squat, stick their hands under their armpits, and attempt to walk around the campfire chanting, “Owa, Tagoo, Siam…” At least until they got the joke.
But first time camper hazing is not what I’m talking about. If you want to become an architect, you need to paddle like crazy under the surface and remain peaceful and patient on the surface. In other words, you have to work a lot while being very, very patient. Look like a duck on the surface, look like a duck under the surface. I think we might all have the paddle like crazy part down (though I think the crazy paddling might be a little better focused most of the time), so for the moment I want to focus on the patience on the surface bit.
I like to tell people that when I started in this business, I was installing VT100 terminal emulation cards in Z100 computers. You know the kind — two 5 1/4 inch floppies and a little bulbous semi-grey screen with green letters? I still own a set of Digital Research CPM on 5 1/4 floppies, in fact. 8in floppies were actually common when I was installing said VT100 cards, as were punch cards and all sorts of other stuff.
But, in reality, I started in network engineering long before those VT100 cards. I started at the age of twelve, getting an Amateur Radio license (WB4YRV — not, it’s not a vanity plate, either, it’s really that old of a call sign). I started working on discrete electronics in old weather and navigational equipment (the FMN-1 had drum memory, while the RVR-400 had dual transistor flip-flops with little light bulbs — of the incandescent type, and the FPS-77 had a dual vacuum tube operational amplifier), and moved to building systems by hand and working on a Xerox Star and the Z100’s laying around everywhere on base and Banyan VINES and Netware and… I started coding in BASIC, and then assembler on a COCO2, and then xBase (dBase and Foxbase specifically), and then Smalltalk, and then C…
The point is this — it takes a lot of time and variety to build of a solid engineering sense. It takes a lot of (what seems to be stupid) repetition to get to the point of being able to understand technology in terms of rule 11.
Don’t be impatient to get to “architect.” It takes time, and that’s okay. Don’t forget to paddle like crazy. But don’t forget to be patient, as well.
Testing to the Cut Score (Certifications)
Tom has an interesting post over at The Networking Nerd on one of my favorite areas of discussion — certifications. To give you a sense —
I think the problem exam writers face is the defensibility problem. The problem of defensibility has been so strongly pushed into my head, from my years working on the CCDE and CCAr, that I tend to apply the problem to just about everything I do any longer. To state the problem, within the certification space, as succinctly as possible —
If someone sues me because they failed this exam, what evidence can I bring forward to prove this specific person should not have passed the exam.
It’s actually not as easy of a question to answer as it might appear. Why is your cut score set to x? Can you prove, statistically, that this cut score actually meets your minimally qualified candidate? Can you prove those who are qualified pass it, and those who don’t, don’t? The defensibility problem means you must be primarily data driven when you set the cut score. As the candidate pool learns more, and as cheaters produce ever better cheats, the cut score must increase in order to maintain legal defensibility. It’s not pretty, but it’s the way it works (by and large).
This cut score problem, however, feeds into a second problem — cheating. There are ways to reduce cheating, of course, and we used many of them in building the CCDE. But anyone familiar with security knows this is a war of attrition and escalation. The solution proposed — to focus on more practical test — might, or might not work. Practical tests are a good way to reduce cheating, but they’re also much more difficult to get right from a defensibility perspective.
Let me put the problem this way: The best way to have an uncheatable test is to have an constantly changing test. But if the test is constantly changing, then you can’t point to any revision of the test as being statistically provable as a “fair” test. We hit a fast/cheap/quality triangle right here someplace, and there’s no easy solution.
If anyone knows how to solve CAP, let me know — I’m all ears. 🙂
Finally, on the point of the vicious cycle of folks using certifications to impress employers, who then end up demanding more and more of the things, while actually causing each new certification to be less valuable — I completely agree. On the point of the stress of the certification cycle — I completely agree.
The problem is I don’t know how to end this stuff. If we didn’t have certifications, people would look for something else on resumes as a “marker.” It might be the typeface used, or whether or not the correct quotes are used, or… Whatever. Humans like to make problems simple through abstraction, and the problem of resume sorting is no different than any other.
The right solution, to me, is to back off seeing the certification, or the degree, or any specific skill, as the “end all be all” of engineering right this second. We automate the scanning of resumes just to keep up with the flood. As with all things, automation has made the hiring process more precise, and more efficient. But automation has also made the process more fragile. Even on a person to person basis, we have a bad propensity to substitute “do you know Python” and “do you know Spine and Leaf” for the real questions we need to be asking when working through the hiring process. But that’s all our faults as much as it is the fault of a certification program.
We’ve ossified around keywords; the people have been lost in the machine, and the machine is brittle. I don’t have any clear answers here, as always (how many balloons fit in a bag?). But we have to find a solution so we don’t break people in the process.
Why certifications make me grouchy
While I support certifications, they also make me grouchy. Sometimes they make me really, really, grouchy, in fact — probably more grouchy than I have a right to be. You’ve probably heard the complaints a number of times.
For instance, there’s the problem of paper tigers, people who gain the certification but don’t have any real experience with the technology, or don’t really understand the technology. Paper tigers are bad, of course, but they’re generally easy to detect through a rigorous interview. In fact, paper tigers exist without the certification; it’s entirely possible for a solid resume to lead to a candidate that doesn’t have the skills advertised. Degree’s don’t really prove much, either, and it takes four years to get one of those (in theory), so I don’t know how much whining about this problem — as real as it is — is going to help.
Tony Li had a counter to this — he used to sit with a candidate’s resume in hand asking questions, and lining through skills he didn’t think the candidate actually had. At the end of the interview, he would hand the resume back to the candidate and say, essentially, “there, I fixed it for you.”
Then there’s the mismatch between skill set and the real world we often hear about — CCIE’s who can’t explain how traceroute works, and JCIE’s who don’t know UDP from TCP. This problem is very real, as well — but I often suspect the problem is overblown in multiple directions. First, we engineers tend to find knowledge about something we happen to be working on right now more credible than knowledge about other things. If we’re in a position to use traceroute a lot, we think it’s pretty impressive the candidate knows traceroute. We might not be so impressed with a wide knowledge of storage systems, for instance, because that’s not particularly interesting to us right this second. Second, I tend to think too many engineers see the interview process as a competition, rather than as an interview.
Or maybe we should discuss cheating, or the fact that certifications qualify to a minimum level, rather than a maximum level (What do they call the person who graduates at the bottom of the medical school class? Doctor!).
There are very real problems here — but can we solve them? We can’t stop people from cheating; the test that can’t either be cheated or socially engineered hasn’t been invented yet (if you invent it, patent it — because you’ve just invented perfect security). We can’t stop people who don’t have a clue about the actual technology, but do have a really good natural memory, from taking the test ’til they pass. Should we ignore certifications, then? Should we abandon college, as well? What about all the rest of the training in the world — is it all useless because every training system in the world can be cheated in one way or another? To ask the question is to answer it, isn’t it?
While these problems often make me grouchy, I’ve been around enough to know there’s no way I can “solve” any of these problems perfectly. Mary Poppins I’m not.
But there’s another reason certifications often make me grouchy — and this is something I think we could do better at solving (even if we can’t make it perfect). To understand this reason, read back through my post on the pie problem from last week. Go ahead, I’ll wait ’til you’re done. Promise. I won’t even peek at your screen while you’re gone.
What mostly makes me grouchy about certifications is the pie problem. There was a time when certifications were loosely held by the companies that created and maintained them — when they were treated as an way to grow the industry rather than as a marketing program. My experience in recent years has, far too often, been the opposite. Vendors have gone down the path of pushing certifications that are designed to drive product sales, rather than to drive the industry at large. It seems, to me, that this is because over the years the ratios have changed; it’s easier to steal customers from your competitor than it is to build new customers.
This seems to me to be a bad thing. It’s a bad thing because we’ve gotten so big, as an industry, that we somehow think the world can’t live without us. We’ve become convinced that things will always be the way they are today, so we can stop focusing on building new engineers, and instead focus on convincing existing engineers that my product is better than yours. We’ve become convinced that we can’t work together to build the industry while also competing in front of the customer.
This isn’t just a problem with certifications, of course — it’s also a problem in the IETF, at conferences, and just about everywhere else you look. Our industry is breaking into small vendor centric camps, pulling apart in dozens of different directions, often ignoring the larger problems in order to make some magical growth number. But it sometimes feels like we’re asking for growth without the seeds, or we’re trying to build a huge building on the slimmest foundation possible.
Individual engineers who really understand the technology are the foundation we need to be building, the seeds we need to be planting. By driving product through certifications, we’re actually making the industry smaller — maybe in bits so small it’s not apparent right here and right now. But dig enough and the foundation can crumble.
There’s no reason IP can’t become the next old line legacy TELCO switch, or COBOL, or BASIC. There is always RIP in the future as well as the past. This is a lesson we would do well to remember — certifications, like all the other larger efforts in the networking world, need to curated by vendors rather than owned by them. Certifications need to be a path to understanding technology rather than a path to push product.
It may be that I’m preaching to the choir, or that I’m talking to the dummy here, but this is what really makes me grouchy about certifications.
Why I Support Certifications
I’m betting that I could take my certifications off my resume and still have a fair chance at finding a job. It’s a guess, of course, and I’ve never tried any sort of an experiment towards finding out, but the point is this: at some point in your career, certifications should become just one more thing on an excellent resume, rather than the focal point of your resume. Given this, why do I still support certifications? To answer this question, I need to back up into the certification development process a bit.
One of the strangest “mind trips” I’ve ever encountered was working with the “psycho’s” (psychometricians, really, but you know how engineers are with long words) through the entire CCDE/CCAr process. The two things we were challenged constantly were:
- What does the minimally qualified candidate look like?
- How do you intend to test for that skill?
Both of these are hard questions.
The first question we turned into a simpler one (again, you know how engineers are): Why do I care? When someone would suggest a particular question or skill, they were immediately met with the counter — Do I care? If I were a designer working on a project, and someone handed me that piece of information, would I care? If the answer was “no,” the question was canned, and we moved on.
The second question is even harder. Think through the fundamental skills a designer needs in the real world — things like the ability to abstract, to ask questions, to consider the alternatives, to manage information overload, and to find relationships between different data points. Now think about how you could test each one. There’s no easy answer for any of these. In fact, I’ve been told that you can’t test for design because these skills are too hard to test for.
But you can test for some of them.
You can’t (really) test a soldier in boot camp for bravery, and you can’t (really) test a doctor in medical school for compassion. That doesn’t mean you don’t test soldiers and doctors, it just means you need to learn the limits of what you can and can’t test — and focus on the things you can test.
To return to the example of the CCDE, one thing it is possible to test is the candidate’s ability to make connections between information scattered in different documents and presented for different reasons. You can break the information needed to answer a single question apart into multiple pieces — like cutting a picture into a jigsaw puzzle — and then putting each piece in a different context. Then you ask the original question and see if the candidate can figure out the answer. To make things harder — to make certain they’ve really grocked the answer, rather than just sniffing out based on best common practices, or they’re just lucky — you can ask them why they gave the answer they did.
This is precisely what the two part “branching” question type in the CCDE was designed to do. First ask “what,” which makes certain the candidate has a clue about what technology or solution fits a particular situation. The situation isn’t always presented “cleanly,” but is often broken apart like the pieces of a jigsaw puzzle, scattered throughout the documentation. Once they have the “what,” right, then you ask them “why.” This is actually the harder part of the two part question, because it’s effectively asking the candidate to show they’ve integrated the information that drove them to the correct “what.” This type of series is what makes the CCDE so difficult.
Given this background, let’s return to the question. Why do I support certifications?
It’s not because I believe they are the ultimate measure of engineering skills — any certification is only going to test to the minimally qualified candidate. It’s not because I believe they encompass the total skill set needed to be a good engineer — there are clear limits on what you can test.
It’s actually because I believe the certification process gives people a motivation to learn, process, and practice at least some of skills they need to be a good engineer.
For engineers without twenty years of experience on their resume, a certification is “good practice for the world.” It’s not the real world, even though one of the differentiators of expert level certifications is they often try to make it as close as possible to the real world. But practice is still good.
For engineers with some level of experience in a single environment, it’s good to broaden skills to a baseline across a wider range of technologies and ideas. Almost every engineer works in a particular environment where specific skills are used over and over again, and other skills atrophy. Certification is a chance to exercise a broad set of skills a team of people with a lot more exposure have decided is a “minimal set.”
The bottom line is this, then — I support certifications because I think they’re good for the industry at large and good for individual engineers. They’re not the end all/be all of knowledge, they will not guarantee you a job, they will not guarantee a “good hire.” But they are a useful part of the industry at large, giving people a broader target than they might experience on a day-to-day basis, and adding some measure of professionalism to the process.
In other words, I see certifications as a way for engineers with deeper knowledge and experience (that’s a nice way of saying “old fogies”) to help mentor and guide younger engineers on a mass scale.
This is the first of a two part series; next week I will talk about the ugly side of certifications.
The Degree or the Certification: Answering the Question
Okay, finally, I’m going to answer the question. For some value of the word “answer,” anyway. I’ve spent three weeks thinking through various question you should be asking, along the way making three specific points:
- Stop asking “should I get a degree or a certification,” and start asking “what do I want to learn next.” Neither degrees nor certifications are a “final point,” in education (terminal, in the vocabulary of the educational world).
- Learn to see beyond the question of specific technical skills — to think about the underlying skills, like abstraction.
- Stop acting and thinking like a widget. You are more than a money making machine.
Okay, so how do I actually decide?
First, ask: where do I want to go? Who do I want to be as a person, overall? This question needs to be a “bigger life” question, not a narrow, “how much money do I want to be making,” question. One of those other turning points in my life as an engineer was when Don S said to me one day, “When I’m gone, people aren’t going to remember me for writing a book. They are going to remember me as a father, friend, and someone who built a community.” It’s okay if the answer to this question changes over time — it certainly has for me.
Second, ask: what am I not very good at today? Do a classic gap analysis here — what do you need to get to where you want to go, and what do you need to get there? This isn’t just about technical skills, it’s also about mental skills, mental habits, and even soft skills.
Third, ask: what motivates me to learn? Do I need a professor in front of my face forcing me to read, or do I need a certificate at the end, or am I okay with just picking up a book and reading it? It’s expected that this answer will vary across different skills.
Fourth, ask: what is the best way to learn this? We often narrow our options down to degrees versus a certification, but there are a lot of other ways to learn out there, including certificates, audited classes, and many others.
Fifth, ask: what will have the biggest financial impact? While you don’t want to turn yourself into a widget, you also don’t want to just waste money pursuing the most expensive educational opportunities available.
Finally, ask: what do I already have today? I don’t want to sound like a killjoy, but I’d rather see two or three certifications along with two or three college degrees, backed up with a variety of other experience, on a resume, rather than 5xCCIE and nothing else. If you have bunch of certifications, consider a degree. If you have a degree, consider getting a certification.
Taking all of these into consideration, you should have a better feel for the right answer.
Two final thoughts before I close.
It’s important to balance financial solvency with passion. I tell my kids that there is some intersection between what you’re passionate about and what will make you the most money — remembering that both will change over your lifetime. Pick a path that will make a reasonable amount of money with the highest level of passion and the widest scope of flexibility into the future in terms of life changes and world changes.
If I had to choose a career path, I would choose the certification and work experience first, and then the degree. While it’s not the easiest thing in the world to finish a degree once you’re working, and you have a family, you’re going to learn a lot more in a college classroom after you’ve had a little life experience, and you pick out the pieces that are important, while just working through the rest.
So the right answer is this: be intentional in your education, from start to finish. Don’t think of it in terms of a degree versus a certification, but in terms of what your goals are, and what you should do next.
Degree or certification? All of the above.
The Degree or the Certification: You are Not a Widget
One of the things that bothers me the most about the Internet of Things (IOT) is how blithely we slip from talking about objects as things to people as things. Among all the things I do not want to be, a “thing,” attached to the “Internet of Things,” is not one of them. What does this have to do with the question of whether you should get a degree or a certification? Simply this: You shouldn’t treat yourself as a widget, either.
Let me explain.
I can’t count the number of times I’ve heard people say, “You should get a certification because it provides more bang for the buck.” In fact, in one rather amusing line of reasoning on the subject, Peter Thiel (who started the Thiel Foundation to encourage smart young people to quit college and take up a career instead), said in a recent interview:
Educational institutions are far too often interested in churning out graduates (i.e., getting their money) without imparting the ability to think rather than just work the system.
To paraphrase, you should opt out of college because colleges are just in the game to make money off you, and you’ll make more money if you don’t go to college. Or something like that. You can’t argue with the line of reasoning if you see college as most people do today: a college degree is mostly about learning a specific skill you can turn into money in your working life.
It’s just about here I want to throw up my hands and scream, “stop it!”
For in asking the question, “how can I make the most money,” or, “how can I be the most successful,” you’ve actually turned yourself into a widget. To this way of thinking, I have one fundamental piece of advice — treat yourself as you would have others treat you. If you treat yourself as a widget, thinking about education as a simple means to get money out of a company or consumers, then they’re going to treat you as a widget in return — treating you as nothing but a set of skills they can make money off of.
You are not a widget. Stop acting like a widget, stop thinking like a widget, and stop trying to become a widget. Yes, there are economic tradeoffs in learning skills. And yes, when it comes to specific skills, choosing the cheapest and most effective way to learn the skills you need is the smartest course. But life isn’t just one long economic tradeoff, and learning isn’t just about acquiring the skills you need to get through the artificially intelligent “buzzword filter,” at the next company you want to work for.
In my next post — probably the last in this series — I’m going to try and bring the two previous posts together (First Thoughts and Learn to See) with this one to provide what I consider the most definitive answer possible on deciding whether you should get a college degree or a certification. I’ll give you a hint in advance, though — it depends.
Part 4: The Degree or the Certification: Answering the Question