Toward the bottom are several books that I’ve read much more recently, including books about network automation and machine learning in networking. Personally, for anyone seeking to get into network engineering or to become a more well-rounded networking professional, I recommend topics around automation and ML as well.

I’m sure you can think of many books that have been foundational for you that aren’t on this list, so please feel free to drop a book title in the comments or on social media.

1. Routing TCP/IP, Volume 1, 2nd Edition, by Jeff Doyle and Jennifer Carroll

2. Routing TCP/IP, Volume 2, 2nd Edition, by Jeff Doyle

3. Optimal Routing Design (Networking Technology) 1st Edition, by Russ White, Alvaro Retana, Don Slice

4. Practical Packet Analysis, Third Edition, by Chris Sanders

5. Machine Learning for Network and Cloud Engineers: Get ready for the next Era of Network Automation, by Javier Antich

6. Network Warrior: Everything You Need to Know That Wasn’t on the CCNA Exam 2nd Edition, by Gary Donahue

7. Computer Networking: A Top-Down Approach, by James Kurose and Keith Ross

8. Computer Networks, by Andrew S. Tanenbaum and David J. Wetherall

9. Network Programmability and Automation: Skills for the Next-Generation Network Engineer 2nd Edition, by Matt Oswalt, Christian Adell, Scott S. Lowe, Jason Edelman

10. Mastering Python Networking 4th Edition, by Eric Chou

I believe a networking professional, whether in pre-sales or working in the field, should have a deep understanding of networking concepts and strong technical experience. But also important are the soft skills necessary to build trust with customers, encourage strong relationships with account managers, and develop camaraderie and collaboration among teams. The words “not my problem” undermine those relationships and therefore shouldn’t be on the lips of a networking professional, let alone any sort of professional.

When I’m working with a customer, I’m often asked to take a look at some issue not related to my project. More than once I’ve had a customer at his wits end struggling with some unrelated issue desperate for advice.

Sometimes the person coming to me is a co-worker on another team. It could be a pre-sales engineer asking me to look over a design for a project to which I’m not assigned. Maybe it’s a project manager asking for help on a project for which the engineer just quit.

The cavalier words “not my problem”, or any comparable phrase with the same sentiment, shouldn’t be my first reaction. Though it may technically not be my problem, expressing that sentiment can be interpreted as aggressive, callous, and in my opinion, unprofessional.

This is true in any relationship such as with the sales team, with project managers, with pre-sales engineers, with the warehouse team, and even with the lowly intern. It also includes relationships to the customer – whether that be the C-level individual signing the purchase agreement or the meek Network Analyst assigned to help me on the project.

Instead of a callous “not my problem”, why not make it my problem? That doesn’t always mean taking complete ownership of the issue, but it can mean offering a helping hand or pointing someone in the right direction.

I understand that sometimes we just can’t help at that moment, and it really could be completely outside our purview to do so. But that doesn’t preclude us from being kind to others as professionals and decent human beings. Doing otherwise hurts relationships which in turn hurts ourselves in the long run.

Here’s a quote from a silly movie:

“…good manners are just a way of showing other people we have respect for them. See, I didn’t know that, I thought it was just a way of acting all superior. Oh and you know what else he told me?…I know, I mean I thought a “gentleman” was somebody that owned horses. But it turns out, his short and simple definition of a lady or a gentleman is, someone who always tries to make sure the people around him or her are as comfortable as possible.” (Blast From the Past, 1999)

Yes, it’s a silly movie and doesn’t serve as my moral guide in life; however, I thought these few lines captured the spirit of professionalism pretty well. I can’t solve everyone’s problem, and sometimes it really is so far outside the scope of work that I’m obligated to politely decline. But inasmuch as I’m able and is appropriate, when someone asks me for help in a work context, the decent thing to do is to try – try to help or try find someone who can.

To me, saying “not my problem” when someone needs help is unprofessional and indecent. Instead, remember that people are more than line items in statements of work.

Thanks,

Phil

Recently I had a conversation with my friend, Jordan Martin, about how we’d love to see these technical conversations brought into the public square. This is something we’ve both been thinking about lately, so the timing was right to start something new.

It started a few weeks ago as I was following a group chat when one of these great discussions unfolded before my very eyes like some bit of high theater. These were some of the best engineers I know, and they spoke their lines with wit and technical eloquence.

As I followed the group chat, I felt like I was sitting in a networking bootcamp, and I made the comment that I wished others could experience it as well. Jordan mentioned he wanted to start a project to bring these discussions to the public square, so this was music to my ears.

A few minutes later Eyvonne Sharp added her voice to the growing triumvirate of nerdness. She had some deep technical topics she wanted to explore as well as some serious thoughts on the networking profession as a whole.

Within five minutes of Jordan mentioning he wanted to start something new, we were putting the pieces together. Later that day, we had Network Collective.

Since we were already on the same page, the idea developed quickly. We wanted something organic and community-driven. I don’t mean organic in the sense that we wanted to wing it every time we hit the record button, but in the sense that we wanted to have engineers discuss technical topics without a net. Jordan suggested we go with a video-first format, and the roundtable idea was floated to maximize community involvement.

We believe a video roundtable format will, by virtue of having a group of participants, facilitate a dynamic discussion and the opportunity for ideas to be explored with a variety of perspectives.

If you haven’t seen the introductory video Jordan published a few days ago, please view it here. Our goal is to get all levels of network engineers working in the trenches to come together and share war stories, discuss design ideas, and debate technical solutions.

We’re not really interested in discussing new vendor products or industry news because there are already some amazing podcasts that do a fantastic job with that. Instead, we want to focus on small group technical discussions.

I’m excited. It’s a group of five or six people which means the conversation is less predictable. It’s video which means everyone will see me fumbling with my notes as I pretend I know what I’m talking about. It’s live which means there’s no safety net.

Who knows what’s coming down the road. For now, though, we’re full speed ahead with bringing to the public forum a community-driven, video roundtable podcast with a technical focus by engineers and for engineers.

Please visit thenetworkcollective.com if you’re interested in participating, and please check out our first live stream on Tuesday, April 11 at 7pm EDT. We’re going to try to publish something every couple weeks or so starting with next Tuesday when we’ll be discussing our best networking blunders and the lessons we learned from them.

Thanks,

Phil

Click on the network-y activity to listen, and make sure to have your sound at a decent volume. Most of these tasks take longer than the length of one typical song, so usually I’m listening to the entire album.

Keep in mind that these links open a YouTube window. Feel free to refute, agree, or suggest alternatives in the comments.

1. Hacking out ACLs for an ASA cutover

2. Racking a pair of massive data center core switches

3. Mission Critical Site-to-Site VPN Troubleshooting

4. The moment you’re in the middle of CLI drudgery and you begin to sense the entire 2am cutover starting to go south

5. Rebuiling a Call Manager after hours from an old backup

6. Mounting a couple hundred access points

7. Bouncing data center core switches back and forth during a code upgrade

8. Configuring routing and seeing adjacencies coming up perfectly on every router

9. Spending the afternoon placing hundreds of access points in Prime

10. Troubleshooting some gear while suffering from the flu and sitting in the cold part of a data center

11. Driving home in the middle of the night in the summer with the windows down and moonroof open after a gloriously perfect cutover 

12. Putting the finishing touches on an AMAZING IDF re-cable

13. Working on documentation

14. Driving home in the middle of the night tired and hungry after only a meh cutover

15. Cranking out emails

My thoughts aren’t based on a formal research study, so please keep that in mind.

Over the last 18 months or so I’ve had more than a couple conversations with friends and acquaintances who believe the CCIE is not as relevant or meaningful in this new age of software defined networking and community-driven technology. The conversation usually centered around trends such as SDN, automation, open standards, and a community-driven networking development model.

The argument I’ve heard has several premises:

First, current trends in networking require network engineers develop new skills other than those found in Cisco certification curricula. Therefore, the CCIE in and of itself is less valuable.

Second, the CCIE certification is more Cisco-centric than it used to be. This means it is intrinsically less valuable as a validation of fundamental networking skills.

Third, we’re fast approaching the 60,000 mark of CCIE numbers making the certification more ubiquitous than it’s ever been.

Fourth, the proliferation of open standards in networking precludes vendor lock-in making any vendor-specific certification obsolete.

Yesterday, I tweeted this:

What I’ve found is that that I’m not the only one who thinks this way. I had a couple good interchanges with folks including this comment from Daniel Dib (@danieldibswe):

I also put the question out there for my CCIE study group and got a variety of responses that centered around a central theme captured succinctly by Nick Russo (@nickrusso42518):

Current trends in networking require network engineers develop new non-Cisco skills, but hasn’t that always been the case? The most successful network engineers are those who have solid networking chops but also know a thing or two about Windows Server, Linux, VMware, project management and how to write a paragraph. Today we can add Python and Ansible to the list. For the vast majority of networking jobs, all of these skills are and always have been important; therefore, the need for engineers to develop programming skills doesn’t diminish the value of the CCIE.

Most networks I’ve worked on were Cisco-centric. Even during my short time working on GE’s infrastructure, all I did was work on Cisco gear. Maybe we need more vendors in the mix, but that’s not really the point I’m trying to make. Most networks run Cisco equipment, so it doesn’t bother me that the CCIE exam is Cisco-centric. Furthermore, I feel that I have a reasonable grasp of networking concepts, and most of my formal training has been through certification pathways. Though the CCIE is certainly vendor-specific, studying for it has also helped me learn more deeply the fundamentals of networking apart from specific vendor technology.

I don’t care too much what the current CCIE number is up to. Not all people who’ve earned it are still actually in the workforce, and of those that are, not all are practicing network engineers. Therefore I don’t believe the market is as flooded with CCIEs as some would suggest. This fast growing number of CCIEs is dispersed throughout the entire world which means there is currently little danger of CCIE saturation in a single geographic area. I understand the point that any certification has the potential to become so ubiquitous that it loses its value, but I don’t believe that’s where we are with the CCIE in 2016. Not even close.

Another friend in my CCIE study group, Katherine McNamara (@kmcnam1), explained that “the CCIE number used to crawl because there was only one kind of CCIE in the beginning, fewer testing centers, and fewer seats.”

In the early days of the CCIE certification, there was one track, very few testing centers and even fewer available seats for actual testing. As a result, the number increased slowly. Today there are multiple tracks, more testing centers, and a much greater awareness of the need for strong networking skills. To say that the number is too high or growing too fast is to suggest the climate for networking technology and the need for engineers with strong skills is the same now as it was in 1993.

The proliferation of open standards in networking doesn’t mean the CCIE is less useful and we all need to become developers in order to get a job. This just means that engineers need to adapt and learn some new skills. Logically, the need to learn Python doesn’t undermine the validity or relevance of the CCIE just like the need for a roofer to learn Excel to better manage his business doesn’t undermine his skills as a roofer. Ultimately this is a straw-man argument that presupposes that a CCIE knows little outside routing and switching. Sure, there are specialists who focus in on a specific technology, but generally speaking I believe that great engineers have deep and broad skills.

Vendor lock-in is not necessarily a concern for me. I don’t think people are truly as concerned about it as they say they are. I think the actual argument is more a matter of bitterness than a logical conclusion. For example, in my naive experience, many of those who wax eloquent on vendor lock-in also subtly and sometimes overtly make fun of those not using a Mac. I know they’re not exactly the same thing, but it suggests that they don’t really have a problem with a little vendor lock-in.

I don’t live in Silicon Valley, New York City, London, or some other global center of commerce and technology. I live in a small city with very few extremely large companies. Hiring managers in my area are looking for candidates with solid networking skills represented by project experience spelled out on a resume. The vast majority of networks are not webscale infrastructures, so pay attention to the hiring managers of smaller and medium-sized businesses where most networking jobs can be found. Sure – the largest and most progressive companies may thumb their noses at resumes and instead ask to see GitHub contributions as a means of vetting a candidate,  but by and large this is simply not the case.

In the last two years I made a few job changes to increase my income. That means I have a lot of interviewing experience in my recent past. Every company I spoke with except one encouraged if not required I pursue the CCIE, and all but one said they’d pay for it. Never once was I asked for my GitHub information or a portfolio of open source projects. I’m not speaking against that sort of hiring process; I’m simply observing that it’s not the method espoused by the majority of companies. Maybe it will be one day soon, but it isn’t today.

Often, the arguments I’ve heard about the decreasing value of the CCIE were made by current CCIEs. These are people who have reaped incredible rewards for earning their number. This doesn’t logically negate the argument, of course, but it doesn’t sit well with me at all.

My early background is in academia, and I have a deep appreciation for formal, traditional education. I don’t value the CCIE over a college education or over real-world experience, and I’m aware that Cisco has developed vendor-specific certifications in large part to guarantee their strong presence in the marketplace. However, I disagree that the CCIE itself is becoming increasingly irrelevant or meaningless.

For us plebeians living in smaller cities and working on networks serving only a few thousand end-users, it still opens doors, and it still provides a convenient pedagogical framework to learn networking.

The CCIE is not becoming irrelevant.

Several of these tweets made light of the fact that network automation is merely deploying some scripts to push configuration to a small (or large) number of network devices. Therefore, a misplaced comma or some other minor typo in the code would devastate the entire production network. This would be my conclusion as well if the premise was completely true, but I don’t believe it is.

I’m sure there are some network engineers out there that are quick to write a sloppy script and push config into production without proper review, testing and validation, but that’s not at all part of the network automation movement as I see it. NetDevOps applies the DevOps paradigm to network management which means there is great value placed on continuous improvement, testing and validation, collaboration and community. Yes, there is also the no-blame concept which may decrease the level of accountability for any single network engineer, but that’s more than matched by the emphasis on peer-review and built-in client-side mechanisms to prevent the network from blowing up. Therefore, the original argument that network automation is too dangerous battles against a straw man that has little to do with what’s really going on in the network automation trend.

Next, to say that network automation is clever but too risky to use in production presupposes that managing network devices via SNMP or directly on the command line one device at a time poses much less risk. Trends in network automation seek to decrease human error by eliminating human interaction with individual boxes. Assuming that proper measures were taken to test and validate configuration, this means that proper use of network automation techniques would actually decrease the likelihood of error, not increase it. For example, copying and pasting 10 lines of config into a router has no built in validation or rollback mechanism if the configuration doesn’t work right. Some lines of configuration would apply, though, resulting in an ugly effort to figure out what commands did take and then go back to delete them one by one. This is in contrast to pushing configuration objects to an open NX-OS device. If there was some problem with any part of the configuration, the rollback-on-error option would automatically rollback the entire configuration if a mistake was found.

I also understand that part of the concern is the awkward balance between efficiency, i.e. managing many network devices at once, and keeping the failure domain as small as possible, i.e. managing network devices one box at time. This tension makes sense to me because I’ve been in the dreaded network down scenario enough times that I know to avoid it at all costs. However, the cause of most network outages I’ve witnessed was human error at the command line. Therefore, decreasing the potential for this is a step in the right direction, not a move toward nuclear annihilation of the network.

I know that I’m making a small pile of assumptions as well. I assume that the network engineer utilizing Python, Ansible, open APIs and the variety of other means opening up to us is using them skillfully. A sloppy script will take down a network, but a careless application of the shutdown command or VTP revision number will cause significant devastation as well.

Therefore, it’s not the methods and techniques that are flawed, necessarily, but the network engineer. We make mistakes, and we need to find ways to mitigate those mistakes. Network automation absolutely does this, but just like any other professional endeavor, it requires skill to utilize effectively.

Also, there is a sentiment that network engineers’ jobs will disappear or change so much that their skills will not be very relevant. I see this assumption all over the place, and maybe addressing it should be its own post, but for now I’d like to address it simply by saying that a network engineer will always need to know  what a VLAN is and what the K values are in EIGRP. Network engineers will always need to have a deep understanding of networking concepts because of the simple fact that they are managing networks. Yes, some elements of configuration may be abstracted; nevertheless, the serious and professional network engineer will still need to know the deep aspects of networking in order to make the magic happen.

Network automation is another tool in the network engineer’s toolbox. 

Picture a veteran astronomer working late one evening, PhD diploma on the wall, coffee at the ready, and dual monitors flickering with incoming data from an exciting new object he’s discovered in the brilliant night sky. Quickly he and his graduate student assistants put together a Python script to analyze the data in order to deepen their understanding of this exciting new phenomenon in the sea of space.

When the astronomer turned aside to write this script, was he no longer an astronomer? Did the usefulness of using Python to analyze and manipulate awesome space data immediately negate any need for a serious understanding of astronomy? Of course not!

In this case, Python is just a tool in the scientist’s toolbox for being a more effective astronomer. In the same way, using the network automation techniques developed and promulgated by the open source community and vendors alike does not presuppose the network engineer is no longer relevant. In fact, network automation is simply another tool in the network engineer’s toolbox allowing him or her to be just that much better of an engineer.

I’m pretty new to this brave new world, and my passion is still certainly in traditional networking, but I can say confidently that no one is trying to re-invent the networking wheel. The industry is just trying to make the ride smoother.

How do I know this? A few reasons, actually.

Every semester I develop a deeper sense of satisfaction teaching students all about networking or servers or whatever it is that’s on the docket that term. I don’t have any quantitative data to identify some trend semester by semester, but I definitely sense a deeper appreciation for what we’re doing in the classroom on Tuesday nights from 6 to 9pm. I find this causes me to be more invested in what I’m doing and much more deliberate in preparing lessons.

Next, each semester my network engineering skills develop a little more as a result of my day job and professional development. That means I can bring more professional experiences and technical depth to the classroom each time I start a new term. It helps me prepare better and I think be more relevant.  I want to believe that students sense and appreciate this through the lessons and relationships we forge over those few months we share together.

Whenever I teach a class a second or third time, I don’t throw all my previous lessons out, of course; instead, I adjust and tweak and improve my material based on how the previous semester went. Yes – sometimes I’ve thrown entire lessons out the window, but normally it’s a matter of expanding and fine tuning labs or moving lessons around to get a better flow. My classroom management skills improve, and my delivery methods improve. For example, and perhaps to the chagrin of my network engineer comrades, I’ve found myself using less sarcasm in the classroom in recent years.

In hindsight, I don’t think I’ve ever taught a class the same way twice.

Also, as I get older and see the value in doing what’s necessary to support my family, I value more the effort my non-traditional students are making. Changing careers is no easy task. I started that process myself in my mid-20s when I was newly married and with no children, so I can only imagine how difficult it is for students who are close to my age or older seeking to make such a major life-change. As the age-gap widens between me and my traditional students, I’ve found it easier to relate to my older, non-traditional students and deeply empathize with their journey. I hope this translates to the classroom. I feel genuinely humbled and privileged to be able to participate in that sort of life-changing endeavor.

During actual class time, issues of life seem to fade as we delve into the content of the day and chase all sorts of rabbits in our discussions. It’s a great feeling, and I start to miss it around early July. Already I’m thinking about how to make that router-on-a-stick lesson work better or how to clean up that ridiculous Powershell scripting lab. Don’t get me wrong: I’m looking forward to some hot summer nights, but I also can’t wait for September to roll around and for those first few emails to come through with my new class roster.

School may be out for summer, but I guess I just can’t wait for the fall semester to start.

Ambitious network engineers thrive on facing challenges and learning new technology. They love to learn, they get excited at the latest and greatest technology, and they get bored easily. And in my experience, the most ambitious network engineers are constantly looking for opportunities to be part of bigger, more complex and more interesting projects.

Recently I had a discussion with some friends about our early days when we were in junior positions racking and stacking hundreds of simple access switches for hardware refresh projects. To many veteran network engineers, this type of project is something we hand off to the junior folks or at least manage from afar while we work on fancier things. A switch refresh is definitely not at the top of the list of cool projects hungry network engineers aspire to work on.

The reality is there’s nothing trivial about a large-scale access switch hardware refresh. Some of the technical components may be simpler to configure on a switch by switch basis, and being successful in an access switch refresh project generally doesn’t require an expert level understanding of networking. However, planning to swap out the entire point of entry to a network for end-users certainly requires incredible planning, deliberate patience, stubborn dedication, an iron stomach and a strong understanding of layer 2 troubleshooting.

Network automation methods can make this much less painful, but the actual design and implementation still requires a certain level of understanding both to deploy and to troubleshoot. It’s the latter case, troubleshooting, where I think junior and senior engineers alike prove their worth, and a switch refresh at a reasonably sized enterprise is no exception.

Coordinating with end-users, understanding the paths IDFs take to distribution and core switches, and how spanning-tree can blow everything up is all serious business. Though no one is configuring global DMVPN topologies with 13 different underlay and overlay networks, royally messing up a switch refresh project takes all users offline completely.

I’ve had the opportunity to work on all sorts of networks from the SMB space to large school districts to large enterprises to one of the largest global enterprise networks in the entire world. To be honest, though, the absolute most fun and fondest memories I’ve ever had as a network engineer was working on large-scale access switch refreshes with like-minded coworkers who took great pride in their cable management and switch/patch panel layout design. Cutting over IDFs at 11pm may not sound as glamorous as a fancy data center project for SuperCoolCompany, but man alive was it satisfying to finish off a closet and compare before and after pictures. And wow was it fulfilling to figure out how to fix a loop we accidentally created ourselves plugging in one stupid switch in the wrong place.

I will likely never do those types of projects again, but I will never for even a second believe they are trivial, menial or beneath me. Getting the job done, whether blog-worthy or not, always gave me a deep sense of accomplishment in my work. Besides, it’s always the junior engineers cutting over IDFs in the middle of the night that get to expense all the pizza they want.

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