For my very last class, I chose not to cover anything in the textbook or any of the bullets on the syllabus. Instead, I introduced my students to systems and network automation. What may seem old news to you and me was brand-new to my class, and I don’t believe this is the exception.

There is a huge  gap between what’s happening in classrooms and in real-world IT, and colleges aren’t preparing students effectively.

I believe the history of technology is important to learn, and I believe understanding foundational concepts is also critical. However, these elements need to be taught within the context of what’s happening in information technology right now. This way, even obscure computer science principles become relevant to the actual work a student can expect to perform in their career.

I know there are exceptions, of course. Students that plan to build careers in pure research should stay focused more on deep concepts and less on how to create a new VM in ESXi. But the majority of young people graduating colleges with two and four year IT-related degrees are getting jobs as sysadmins, network engineers, developers, help desk analysts, and so on. Knowing the foundational principles is certainly important, but does it also prepare them to configure a core switch or create new storage for the applications team?

Some two and four year schools advertise degree programs in network administration, cybersecurity, etc, in what I assume is an effort to provide a more relevant education. Some advertise they utilize the Cisco Networking Academy and Microsoft Online Labs.  But after working in the trenches in some of these programs, I don’t think they are nearly as relevant as schools think they are. And frankly, I believe this is doing a disservice to tuition-paying students.

During my last class, I gave students an overview of systems automation and introduced things like Chef, Puppet, Ansible, and Powershell. We discussed the difference between on-box and off-box management. We talked about what programming languages they should learn on their own, the importance of getting familiar with navigating a Linux file system, and what changes are going on in the industry today.

None of my students knew what the “cloud” was. None knew any programming languages other than the little bit of C++ and Java they learned earlier that semester. None had any idea about virtualization, a 20 year-old technology.

There’s a big gap between what’s being taught and what employers are looking for, and I believe teachers and those who write curricula are the ones to address the issue head on. Administrators have no clue about what’s going on in our industry, and college advisers at best have only a cursory knowledge of what a hiring manager wants to see on a resume.

Colleges need to hire teachers with solid industry experience. They need to prefer adjuncts that are working in the field right now, and then pay them enough to keep them around. Curricula needs to be modified, or in many cases just thrown out. As much as possible, a course’s curriculum should reflect what’s going on in the industry. As budget allows, labs need to be built, and industry news publications need to be part of the course reading list.

This may not be applicable to many departments at a typical college, but it’s vital in IT. Our field lives and breathes change, and it doesn’t need a new generation of job candidates that have months of experience configuring VTP but little else.

For me, it’s not about explaining DNS, OSPF, or what a hypervisor is. It’s much more about helping bridge the gap between someone learning these things for the first time and making the leap to a productive member of an IT department. Sure, that means memorizing well-known ports and learning about data structures, but it also means discussing DevOps, cloud computing, containers, or whatever technology is immediately relevant.

I left my teaching position for several personal reasons, but I hope to get back there one day. I love being in the classroom, and I love working with young people starting their own career journeys.

A real joy for me was making every three hour evening class as relevant and meaningful as possible, and sometimes that meant abandoning the five-year-old textbook and reviewing a recent blog article instead.

Thanks,

Phil

Here’s the website: http://thenetworkcollective.com/

The header image was used with permission from Michael Nelson who was one of the Twitter participants during the first show. Check out his site here.

One day, instead of unpacking our favorite Shakespearean sonnet, I was sidetracked by a student who asked me how we know anything about electrons and how they orbit the nucleus of an atom. Apparently he asked his physics teacher the period before and got a pithy “electrons are the essence of a negativity.”

That made no sense at all to my student. It didn’t to me either. It didn’t answer the question, and in and of itself is a ridiculous statement. After making a Zoolander-esque joke about electrons being the essence of negativity, and negativity being the essence of Mr. Treuber’s physics class, he asked me the same question. So I went on for a minute about mathematical equations I didn’t understand and how it’s more an electron cloud than electron orbits. I didn’t know how to answer, either.

Because English class can lend itself to discussions of philosophy, metaphysics, human nature, and the more profound questions of life, my students were accustom to this kind of departure from whatever literature we were studying. I enjoyed it, too, but saw it as an opportunity to encourage them to respectfully ask their teachers how they came to their conclusions and how some indelible nugget of truth came to be known. I encouraged my students to respectfully ask their teachers, “how do you know that’s true?”

Many moons later, I program routers and play with computers all day. I read a lot of blogs, browse through reddit once in a while, and follow several technology publications. I also get to participate in an amazing social community of network engineers and technology professionals.

The community likes to joke about vendor hype which is both fun and poignant because it makes you think critically about the marketing from all our favorite technology companies. But the community also likes to make evaluations and predictions of its own. I tend to take these more seriously because, by and large, these are engineers writing for other engineers. I feel there is less marketing hype and a level of technical expertise that legitimizes the arguments.

But remember that people in any social environment come to conclusions based partly on the communal narrative. For the networking community, this means there are strong statements being made that everyone sort of just goes along with without question.

Therein lies the problem for me. I clearly remember encouraging my class to ask their teachers “how do you know that’s true?” However, I don’t often apply that to the networking community which is made up of, what I consider, some of the best teachers I’ve ever had.

A few years ago I came across a long twitter thread on why having one access point per classroom was bad design. There was no reasoning I could see, just everyone agreeing in rant form how bad a design it is. I asked the person who tweeted first why he believed this, and his reaction was to defend himself. I immediately told him I was not a wireless expert and was genuinely curious how he came to that conclusion. Rather than tell me that “access points are the essence of wireless”, he sent me a whitepaper he wrote on the topic thoroughly explaining his argument using RF math (which I barely understood) and several case studies.

Now I know why wireless engineers believe one access point per classroom designs are a bad idea.

When an entire social community rallies around a set of bullet points, I get a little skeptical. Where did this come from, and how do I know if this is true? Apply this to the blogs you read and tweets that come across your screen. Rather than blindly jumping on the bandwagon, don’t be afraid to politely and respectfully ask a blogger how he or she knows what they say is true.

Be prepared, but not afraid, to explain your position as well. This is our community’s way of iron sharpening iron. 

Sometimes we can’t find the right words, and sometimes our ideas are so abstract that words just aren’t good enough. For me, I occasionally fumble and hesitate when I I try to explain something in normal conversation. Instead of communicating what’s on my mind clearly and effectively, I discover that I really don’t know what I’m talking about nearly as well as I thought I did.

Writing requires that we take those ambiguous and seemingly random ideas and force them into a logical construct so that others can read them and gain some sort of meaning. The process requires we identify a singular theme unifying our thoughts under one contextual banner. It also requires that we move logically from one idea to the next; otherwise, no one will be able to understand what we’re trying to say. And in the process of writing our thoughts in order to communicate them effectively to others, we actually crystallize them for ourselves.

The process of writing refines our thinking for ourselves just as much as it does for our readers.

The realm of IT is so vast and changing so quickly it requires constant attention to maintain some semblance of understanding. It’s no easy task to wrap your mind around SDN, for example, and immediately come to a settled, definitive conclusion as to its definition, role in modern networking, and the role it will play in coming years. But sit down for a few hours and write a 1200 word piece talking all around the subject and you’ll develop a deeper understanding of SDN than you’ve ever had.

How many times have you heard the term “security best practices” and nodded with understanding while not really knowing what it meant? When I hear or read it, I think of things like centralized authentication, patching servers, anti-virus software, and the policy of least privileges. However, I’ve never really thought through what security best practices really are. I’ve read some articles, heard some people loosely use the term, and I’ve always gone along assuming I knew exactly what it meant. But a recent conversation I had with my students revealed that I had only a vague idea at best.

In order to patch that hole in my understanding, I’ve been reading some whitepapers, blogs and random articles online. However, it’s not until I started to write my own blog post on it that I internalized the concepts.

I know many people struggle with writing and have no fond memories of 11th grade English class. Searching for the right words and where to start can be overwhelming, but the rewards are tremendous.

Writing is difficult but profoundly beneficial.

Write about what a private VLAN is. Explain why you think we should be running layer 3 to the access layer. Analyze the latest SD-WAN solution. Start with an introduction that identifies your theme. Use correct grammar and avoid stream of consciousness style writing. Develop your ideas in the context of your theme and don’t wander off. Write a formal conclusion and tie everything together.

I know it seems like a chore, but the process is incredibly impactful to our thinking. Even if no one ever reads your writing, you’ll have a deeper, clearer, more precise understanding of your own ideas than you otherwise would have.

In short, write something.

I can’t help myself. Even though I couldn’t wait to get out of a teaching career in my mid/late 20s, I still teach a class every semester at a local community college. I don’t plan to ever stop.

In my early 20s I taught high school English and was dumbfounded with how well some of my [older] colleagues knew Shakespeare, in particular. After chatting about it during one of our department meetings I learned they had that level of familiarity and depth of understanding mainly as a result of having taught it for 20 years. In fact, after only five years of teaching much of the standard canon of the American school system, my knowledge of the literary classics increased dramatically. Those few years working in the classroom and writing about literature trained me to decode a text and effectively communicate my thoughts in writing and in a public speaking context. Grad school did that a little. Teaching all day every day for five years did that a lot.

Today I teach classes on Cisco networking and Windows Server, but the result is similar: I have a deeper understanding of the fundamentals of the networking trade because of having to put the concepts into understandable, cogent lessons. Teaching one night a week isn’t terribly difficult, and it’s nice to earn a little extra money, but the benefit to me has been absolutely tremendous.

I don’t think any of what I’ve said thus far is groundbreaking. Teaching a topic causes one to learn it at a very deep level, and I’m sure that’s no great revelation for you.

If you want to become an expert in a topic, teach it.

Rather than expound on that, I’d like to focus on how incredibly rewarding it’s been to work with young people and adults in their endeavor to build a new career in IT. This semester I’m teaching Advanced Windows Server Administration, and every Tuesday night I have the opportunity to get my students excited about our field. Some of my students are right out of high school, but more than a few are adult learners changing careers. When they understand a new concept or become proficient in configuring a particular technology, I know they’re making palpable, relevant progress toward a new career that will help them provide for their own families and ultimately change their lives. Yes, teaching a topic will help you understand it better, but the intangible rewards of helping others in their journey is truly soul-satisfying.

I have the privilege and luxury of teaching others in a traditional classroom setting, but there are opportunities all around us, in the context of our vocation, to enrich our own lives and the lives of others. Coordinate and lead a lunch-and-learn for your co-workers. Come alongside a junior engineer studying for his or her CCNA. Work with some young people at a local vocational school to teach them how to punch down a 110-block. These things will help you for sure and even help you become a better network engineer, but let that be an unintended side-benefit.

Teaching our craft gets people excited, it gives people marketable skills, it changes lives.

A few months ago I wrote about how we work with people just as much as we work with technology. All around us are people who are valuable not just as resources, not just as sources of information, not just as a means for new opportunity, but simply because they’re people. If you’ve had opportunity to succeed in your career and amass a reasonable amount of knowledge and experience, I challenge you to find someone in your life to connect with or a group setting in which you can share your knowledge. There are no rules, no magic lesson plans, and no lucrative contracts, just the reward of helping others.

In short, teach something.

Follow me on Twitter  @network_phil

In my opinion you can do OK focused purely on technical ability and little else. However, I believe that in order to truly succeed in your career, a network engineer must develop an entirely non-technical skill set vital to being an excellent networking professional.

When I say a “successful networking professional” I’m referring to one who’s gone beyond simply the ability to program a router or troubleshoot a VPN. They’ve also developed an ability to interact with others in their workplace to foster friendly relationships, respectful professionalism and reasonable expectations for themselves and others. They have the ability to understand business needs and how to derive appropriate technical requirements. They have the ability to communicate with a manager, co-worker or customer in such a way as to get the job done without sacrificing the relationship.

Maybe this goes without saying, but I’ve worked with enough server admins, network engineers, storage people, developers, virtualization specialists, etc. to know that folks with very strong technical skills can also be deficient in their ability to get the job done efficiently, quickly and without creating interpersonal tension. The ability to work with others and marry technical skills with business needs is what sets apart a truly successful networking professional. In my humble opinion and in my experience, those that have both skill sets are the engineers being promoted, sought after by HR departments and successful as sole proprietor consultants. And I believe that the superstars do this intentionally.

Let me explain where I’m coming from. I think there is a self-awareness that causes a person to constantly reflect on how they’re interacting with the world around them. This is part of being human. We all have a constant stream of thoughts, images and self-conversation going on in our head. We’re self-aware. And I believe a healthy self-awareness of how we interact, moment by moment, with the world outside our own minds is an immensely important factor to being successful in any social context in life including our careers.

So in terms of network engineering, many people can hit the books and learn about packets and frames. Clearly a strong technical skill set is vital to the job, but the ability to then apply those skills in the context of a real office with real people with real customers and with real business requirements is what sets apart the person that knows some stuff about VPNs from the professional that is called upon because they can really get the job done.

I had the luxury of a liberal arts education. Some would scoff at this, and sometimes so do I. But something I value from that type of education is the ability to write emails clearly and create customer-facing documentation that’s coherent. Have you ever had to re-read an email nine times because you had no idea what the sender was trying to say? Have you ever read “professional” documentation that caused more confusion than it cleared up?

I’ve also had the privilege of being an English teacher which taught me the skills to choose my words carefully in the context of a mixed classroom environment and deal with interpersonal issues in a diplomatic manner. That’s standard classroom management and something I developed over a few years in front of a group of students, but it’s been a tremendous advantage for me as a network engineer delivering presentations, meeting with customers and working on a team.

Could any of those lessons be applied during the sales process of a major network overhaul? Could some of those skills be useful during the design and implementation of a huge virtualization solution? How about in daily network operations?

Maybe these skills aren’t able to be taught but instead develop only from experiences. I really don’t know. But I do know that we can work to create those experiences, and in that way we can train ourselves in those ambiguous “soft skills” LinkedIn articles like to talk about all the time.

Ultimately, though, to be truly successful we need to remember that we work with people just as much as we work with packets.

In college I focused on literature and history. I developed that in grad school and turned it into a teaching career. If you’ve read my About Me page you’ll know that a teaching career wasn’t really for me. However, I’m convinced that the skills I developed as a teacher and passion for lifelong learning that grew out of those few years have been vital to becoming a well-rounded network engineer. I still go to school every day, but now I call it professional development.

I use the term “professional development” only because it’s ubiquitous in the IT field. We all have a sense of what it means, but I think it’s somewhat of a misnomer. One of the main reasons I got into IT was for the chance to own my skillset apart from having to play company politics or climb the corporate ladder. I did not (and do not) want to be beholden to an organization to grow in my career and my ability to provide for my family. Though I’m grateful for my job and believe we ought to be respectful toward our employer, I don’t rely on my company to develop my depth of knowledge, income potential and to an extent my job satisfaction.

Professional development, then, is not really the formal plan your boss gives you during your yearly review. Yes, you can definitely progress that way, but it’ll be according to the desires of your employer and at their pace. That may align with your plan, and it may give you a good framework to work with, so I don’t want to dismiss that situation entirely. But in my experience, I’ve never been handed a formal plan. My professional development has been much more personal. My employers knew I was already deep in my own studies. Of course it was convenient that my goals were in line with the direction of the company, but so far it’s worked for me.

I do remember once when an employer gave me a specific directive. A Cisco VAR I worked for wanted me to develop my wireless skills, so they assigned me the task of getting a CCNA and CCNP wireless in one year. They incentivized it, and I earned both within about five months. But understand that this didn’t take away from my plan because I already wanted to round off my CCNP level knowledge in other areas.

I believe that it’s because I already had a personal plan that their directive worked out so well. I reject the idea that I have to wait for my boss to create my career for me. I even reject waiting for my employer to pay for resources before I can make progress.

For a network engineer, a professional development plan is the ongoing endeavor to be a better network engineer. By the very nature of that goal the results will be advancement, more interesting work and more lucrative employment.

I concluded early in my career that I would be a network engineer by trade and not because it was the job I happened to have. That means I would be a network engineer regardless of who I worked for or my precise title. Think about your own career that way. Don’t make it the basis for your identity, of course, but I think it’s right to look at network engineering as our trade: a craft we love, take pride in, and at which we continually improve.

You need to develop your own plan. Where do you want to be in your career in five years? What sort of income do you want? What technology do you want to work with? You need to first take an honest look at the industry and determine what areas of the IT field can accommodate those goals. If you want to earn six figures within five years, then you’re in the right business. If you thrive in an environment with constant technical challenges, the opportunities are there. But if you have no plan and float aimlessly through five years of L1 and L2 helpdesk, you won’t get to the next level.

For me, after one year on helpdesk it was time to get serious, so I set a specific goal with a timetable. Then I became relentless in my pursuit to fulfill it. This is when my career actually began. I decided that I wanted to be a network engineer. My goal was the job title and a certain salary. I tackled the CCNA first which took me almost a year. I started with reading a CompTIA Network+ textbook and watching the DVDs that came with it. The content wasn’t difficult – it was basic network concepts which I picked up quickly. When looking at the CCNA content itself I realized a textbook wouldn’t cut it. I hung around with some of the network engineers at my company and learned how to put together a lab. They recommended Pluralsight and CBT Nuggets, so I immediately purchased subscriptions with my own money.

Now I had a goal and resources, but I didn’t have decent study habits yet.  Remember this was a career change for me and I desired to catch up as fast as I could. How would I get a CCNA in one year when all of this was so new to me? The answer was simple in theory but difficult in practice. I was going to have to work hard.

This is something you have to settle within yourself if you want to advance in any serious manner as a network engineer. You must be willing to work hard.

I set up a lab and got up at 4:30am every weekday to study before work. I studied at night after my wife and I put the baby to bed. I studied every moment I could scrounge. Lunch was studying. Early morning was a CBT Nuggets or Pluralsight video. Nighttime was a lab. I still failed both ICND 1 and 2 the first time before earning the CCNA, but when I got it I was able to get a much higher paying helpdesk job almost immediately.

My second job was also at a Cisco VAR, though it was a dramatically smaller company. I was given all the networking tasks because I was the guy with the CCNA and working on his CCNP. This is important to note. This company was so small that I had the opportunity to work on everything. We didn’t work on huge projects, so it was a perfect environment to work on basic networking skills every day. The concepts became so ingrained in me that advancing through CCNP content wasn’t too difficult. It required a lot of work to learn and lab, but it was familiar. I still got up early to get to the office by 6:30am every day to study, but now the ball was really rolling.

This is something to consider. A smaller value added reseller is a great place to go from helpdesk work to entry-level network engineering because a small company can’t afford experienced high-end network engineers and usually doesn’t have the work for them anyway.  By nature of the small business environment you will learn, learn, learn. 

In one year I earned a CCNP, and the company grew enough that I worked on CCNP level projects regularly. After two years my title changed to Senior Network Engineer and I got a nice raise. This was the fulfillment of my first plan, and it took getting up very early, spending some of my own money, turning off Netflix (the hardest part sometimes), and staying up late reading.

Since then I’ve earned other Cisco certifications, and today I have a new goal, a new plan and new resources, but the same strategy. The best part, though, is that it’s mine. I wasn’t handed my professional development plan. I created it for myself, personally.