The Portable Command Guide: How it Works and Why You Should Build Your Own
Quick – what’s the command to turn on authentication in OSPF using MD5? Or the command that changes the k values in EIGRP? Do you hate it when you type in a command incorrectly and the router spends what seems like hours (it really is only a few seconds, but it sure does seem like hours) trying to find that command out there in the enterprise, searching location 255.255.255.255? Do you really know all the steps involved in recovering a missing/forgotten password on a router or switch? All of these happened to me at some point early on in my Cisco career, and I am guessing that some of these happened to you as well. So what do you do about it? If you are really smart, you memorize every command and every keyword for every command and the placement of the command in the Cisco IOS so that you can walk around like Sheldon from The Big Bang Theory and impress (or annoy) everyone you know with your amazing brain. Or you can be like the rest of the population and take advantage of a small notebook and your own personal organizational style to create an Engineering Journal. My engineering journals became so popular among some of my colleagues that they kept on borrowing mine, claiming that if I ever published it they would buy it. So with the folks at Cisco Press behind me, my engineering journals became the basis of the Portable Command Guide Series.
I have long been a fan of what I call the “Engineering Journal” – a small, portable notebook that contains little nuggets of information such as commands that you forget, the IP addressing scheme of some remote part of the network, and little reminders about how to do something you only have to do once or twice a year but is vital to the integrity and maintenance of your network. This journal has been a constant companion by my side for the past 12+ years; I only teach some of these concepts every second or third year, so I constantly need to refresh commands and concepts, as well as learn new commands and ideas as they are released by Cisco. My journals were the best way for me to review, as they were written in my own words; words that I could understand. At least, I had better understand them, because if I didn’t, I had only myself to blame.
The first engineering journal I created was for the Cisco Academy BSCI (Advanced Routing) Instructor’s course. In the class we were able to write down lists of commands for use during the practical final. Some of my classmates wrote down the commands, but I found that for me a command list wasn’t enough. Although I was familiar with the theoretical concepts of what those commands were to do, some of the commands made perfect sense, while others didn’t. As I got deeper into the course, the commands got longer and more complex. In the Cisco world, not all commands work in all locations, so where the command was to be typed was (to me) equally as important as what was to be typed.
Taking a second CCNP course in BCRAN (Remote Access) introduced me to technologies that I had never used before, and with those new technologies came new devices and even new cable types. I had to worry about more than just the syntax and location of commands; if I was having concerns about how to process and store this information in my brain (and I am the so-called "expert"), then how would my students handle this, having much less experience in this area?
This is where the engineering journal really took hold for me. Because I was going to instruct in these areas, either I needed to know these commands inside and out or I needed to have some way of finding the answers quickly. My engineering journal needed to have a specific layout and format if I was to find information quickly. Because of the importance of the location of the command, my personal journals became color coded: blue ink for the prompt, pencil for the command, and red circles or highlighting to emphasize important commands or part of commands that were tricky and needed to be reinforced in my mind. These visual cues made looking up something in my journal extremely easy. With the exception of the first command guide published by Cisco Press, the use of color coding has been replaced with boldface fonts and italics. In a publication or book this is an acceptable means of differentiating the parts of the command that need to be identified as unique or special. But there is still something visually appealing to having colour-coded cues and examples.
In fact, years later, in the summer of 2010 as I completed my master's degree in education, I took a course on brain research and how people learn and process information. I was stunned to find that an overwhelming majority of English-speaking people are visual learners, and yet English is an auditory language. I discussed my concepts of my journal (now published as Portable Command Guides) with my professors, and they concurred with my ideas of using visual cues of color and shading within my books. These were the cues that visual learners need to help process information and to be able to retain information long term.
As a college professor teaching Cisco concepts to students, my job is to make sure that my students are prepared as best as they can be to enter into the IT industry and to become your colleagues. But as an author I want to sell more books. So even though I want my students to build their own journals (which I allow into practical exams), I still want them to see an example of one way to structure and organize ideas and concepts. However, the organizational style that I use for me may not be the best style for you. And while my books are structured around a specific sets of objectives for Cisco’s certification exams, your job may not be so neat and compartmentalized. The compromise came to me in the form of Appendix B in every PCG published by Cisco Press – and by Pearson Education for the non-Cisco PCGs – the “Create your own Journal Here” appendix. This section contains nothing but lines on the page; use that space to create your own journal. By customizing and personalizing the PCG to your network and experiences, the PCG stops being my book and it becomes your journal.
So there you have it – a brief summary of how my journals came to be Portable Command Guides, and why I want you all to create your own journals. The educator in me says to go and buy your own coiled notebook and some colored pens, but the author in me suggests you start with the PCG best related to your job and take advantage of Appendix B. As an author, I thank you.