That Time I Taught My First CCDE Training Class

I recently noticed a great infographic floating around the inter-webs regarding the Imposter Syndrome:

It struck me that:

• Everyone I’ve had a meaningful conversation with on this topic has admitted to suffering from this affliction
• No one thinks anyone else suffers from this affliction

And I do mean it -- I have spoken with dozens of people about this topic, from all walks of life. The very best network architects I know may even suffer from Imposter Syndrome to a greater degree than less experienced members of the industry. Perhaps this is a factor in their success; they never feel like they belong (technically), so they continue to study technology and achieve certifications in a quixotic attempt to finally feel like they have accomplished ‘enough’ to fit in.

And perhaps no one experiences this as much as I do. [See what I did there… I fell into the very trap that everyone else falls into, thinking that I have it worse than the rest with regards to this affliction]. The logical, calculating portion of my brain knows this is a farce. I have lots of great experience, many successful CCDE students and multiple high-level certifications that should provide proof of my abilities. In fact, they do, to everyone but myself.

---

So what does this have to do with my First CCDE Training Class (the title of this blog post)? I’m sure you can guess.

About a year after I earned my CCDE certification, I found myself in a classroom, tasked with teaching a group of network engineers how to prepare for the CCDE Practical exam. Well, they weren’t just a ‘group of network engineers;’ they were a self-selected class of fifteen Cisco SEs and NCEs. We began the class in traditional fashion, where I introduced myself and then gave each participant a few moments to do the same. As I recall, every member of the class had at least one CCIE certification, and in total there were over 40 earned CCIEs in the room. Only one of those was mine... Talk about the Imposter Syndrome! As one candidate briefly summed up his background (two Cisco Press books published, developer of the CCIE DC exam, etc, etc) the thought occurred to me — "I got lucky, passed a tough exam, agreed to teach a class I had no business leading, and now I’m going to melt into the floor at a Cisco office in Chicago once this class realizes I’m a fraud."

Fortunately, this class was full of extremely kind and patient students. The materials 

provided by the training vendor were not sufficient to help prepare the class, so I spent several late nights during the week preparing additional case studies. At the end of the week one of the students kindly photocopied my handwritten composition notebook to share with the class. A handful of class members had already attempted the exam and they had specific strategies that they wanted me to help them work through. One wanted to go through a merger scenario, so we worked up something on the whiteboard. As we proceeded through the various topics and designs that could be on the exam, we occasionally reached a topic that I had difficulty teaching. Each time one or another member of the class stepped in to guide the discussion.

At the end of the week, I thanked the class for allowing me the opportunity to assist them with their pursuit of the CCDE certification. I remarked that they had been an incredibly patient group and they had made me, a first-time instructor, very comfortable. Immediately several students expressed surprise that I wasn’t a seasoned teacher. Each of them remarked about how at ease I appeared during the class and how well I handled such a difficult group. My internal read on the situation was exactly the opposite of theirs. Several months after the class concluded, I began to receive emails from students thanking me for the assistance I provided, and letting me know about their success on the CCDE Practical exam. By my count, five of the seven students who ultimately attempted the CCDE Practical passed after our class.

You would think this experience had put my mind at ease, and teaching future classes would be much easier. Well, I’ve taught well over a dozen week-long CCDE bootcamps, and many more online classes, and I still get nervous before I introduce myself at the beginning of each session. The Imposter Syndrome is a part of my professional life, and I’ve come to accept it. In fact, I count on it to ‘keep me hungry,’ so I continue to study the various technologies involved in network design just as I did in 1997, when I truly did not know anything about networking.

---

I do in some ways fear that as the Imposter Syndrome is more openly discussed, it will become less prevalent. This could have the unfortunate effect of causing overconfidence, where everyone who knows about this syndrome thinks they suffer from it, even when they are, in fact, under-informed about their chosen craft. I somehow doubt this will be an issue except for the small minority who never actually had the condition to begin with.

---

Here are a few more references to Imposter Syndrome from @aliciatweet. She appears to be the source of the image at the top of this post, or at least the original infographic that this was based on:

Overcoming Imposter Syndrome - https://medium.com/@aliciatweet/overcoming-impostor-syndrome-bdae04e46ec5

You Don’t Have Imposter Syndrome - https://medium.com/@aliciatweet/you-don-t-have-impostor-syndrome-126e4c4bdcc

---

Jeremy Filliben is a network architect and CCDE instructor. He has assisted over 80 students in their successful pursuit of the Cisco Certified Design Expert designation. His next CCDE Practical Bootcamp class is scheduled for July 25th. More details can be found on his website at www.jeremyfilliben.com. 

Is Network Design an Art?

I get a little worked up when I see network designers describing our craft as an ‘art.’ I understand where the thought comes from; there is certainly a level of creativity required to arrive at an optimal network design for a given set of constraints and business challenges. It is nevertheless my opinion that we are working within a science, not an art. The key differentiator is whether we can judge one network design to be superior to another. With the traditional arts, it not objectively possible to say one song/painting/movie is ‘better’ than another. We can measure them on various points (Rotten Tomatoes [link] scores for movies, sale price for paintings, etc), but how any one individual perceives an artist’s creation is not open to debate. I like Dumb & Dumber more than Casablanca, and no amount of objective information is going to change my mind! 😃 

This is not true with network design. If two network designers review a set of business and technical requirements, they may generate unique proposals. When this occurs, invariably one or more of the following are at the root of the disagreement.

A) They interpreted the requirements differently, or the requirements were defined well enough

With good network designers, this is often the root cause. It is possible that they did not receive the same requirement information. More often, one of the engineers overlooked a key piece of information, such as a customer preference or existing technology choice that must be taken into account. If the requirements were not well-defined, assumptions must be made. These assumptions become quasi-requirements, which lead to different solutions.

B) Have differing personal opinions on the implementation details of a solution

Also known as ‘practical experience’ — These are the biases that we have developed over the years of deploying and managing technologies. Pretty much every network engineer has a preferred IGP, for example. Perhaps you have worked more often with OSPF networks, and therefore you are more comfortable using it to solve most problems. That does not make it the right choice for every proposed network design. This point of disagreement can also result from negative experiences, especially as they relate to implementation-level problems. Remember that Cisco OSPF in IOS-XR bug that kept you up for several consecutive nights, or the time IS-IS ‘blew up’ for you because you added a Juniper router to a Cisco network (hopefully not real examples for you). While implementation-level details should factor into real-world designs, do not let them talk you out of the correct technology solution (especially on a CCDE exam, hint hint).

C) Do not share the same knowledge base / understanding of the design elements

This is the category of disagreement related to the knowledge of our network designers. If one engineer proposes an IS-IS solution, and the other engineer has no experience with the protocol, there is very likely to be a disagreement.

For humble network architects, this should not be a problem. We all have our areas of expertise, and I can assure you no one is an expert in all possible technologies. Those technologies with which I have less practical experience can still be valid solutions to a problem. It is my responsibility as a network architect to have a solid understanding of these options, and if one appears viable I must put in the time to study it to see if there is a place for it in my proposal. I recommend knowing enough about each networking technology to answer the following questions:

1) What problems can it solve?

2) What are the pre-requisites?

3) How well can it scale?

4) How manageable is the resulting design?

That short list is in my experience sufficient to know when/where a technology can be useful. I can quickly rule out those that won’t fit (for example, if L2 adjacency is required, I can rule out L3VPN) and then spend time researching the remaining options to find the best answer.

---

Note that none of these points of disagreement allow us to develop unique, equally-valid solutions to the original problem.  Perhaps in the simplest cases it does not matter if we choose OSPF or EIGRP as our IGP, but with enough probing we should be able to find information that leads us to one specific solution. Maybe we could ask the following questions:

1) Are you concerned with vendor lock-in?

2) What is your convergence requirement?

3) Does your support team have operational experience with either protocol?

4) To what size do you intend to scale the network?

5) Might you deploy dynamically-calculated MPLS-TE tunnels in the future?

After getting honest answers to these questions, two network designers should be able to come to an agreement on the correct IGP.

BTW, I am not disagreeing with the core tenet of Art of Network Architecture, and not just because Russ and Denise are two of my favorite people in networking. The point I am making is that there is a difference between network architecture and design.

---

Jeremy Filliben is a network architect and CCDE instructor for Pristine Packets. Details about his training can be found on his website, www.jeremyfilliben.com. Jeremy has trained over 80 CCDEs in his 7 years in the industry.