More on Reading and Writing Books

Russ White wrote a great response to my “Do You Really Want to Write that Book?” blog post and I couldn’t agree more with what he wrote. Unfortunately, he seems to be a bit over-idealistic when analyzing why the market for high-end content is so small.

You know I usually have a cynical explanation handy, so here it is: too many people calling themselves engineers for no particular reason simply don’t care. It’s way easier to Google-and-paste your way around than to invest time in understanding the fundamentals.

I understand that you won’t devote days to studying technologies underlying a simple problem that you have to solve once in a lifetime, but if you encounter the same challenge multiple times, it’s time to do some proper research.

The problem with the scenic route to knowledge is that you have to invest an extraordinary amount of time before reaping the benefits (see also: 10K hour theories), but once you do, the results tend to be great.

For example, it’s really easy to identify the problems with most things touted as SDN once you’ve seen (and understood) enough networking technologies – there are only so many ways a problem can be solved, and I haven’t seen a revolutionary one in decades (regardless of what the marketers trying to separate VCs from their money claim).

To summarize: Don’t be one of the people interested in finding shortcuts (aka Best Practices) without understanding them. Whenever you’re trying to grasp a new technology ask simple questions like:

  • WHAT problem is it trying to solve?
  • HOW does it work (as opposed to How do I configure it)?
  • WHY does it work the way it does?

Before you leave: If you made it this far, you MUST watch the excellent A Praise for Hackers Troopers 2016 keynote by Rodrigo Branco.

And finally: if you prefer watching videos over reading books, here’s a treasure trove of 130 hours of downloadable videos.


  1. Can you make any recommendations on what we should be reading now when it comes to networking books? I have read everything on the old and new CCDE reading lists and Russ White's newer books as well. I have also read all of your books. I am currently reading through Patterns of Network Architecture by John Day.
  2. I am usually a passive listener, but your link to the troopers conference was so valuable that I had to break my silence. I chuckled so many times while watching the presentation and I think the approaches speaker mentioned is applicable in general and just not limited to Security. Thanks again for that link.
  3. I think you're also being too idealistic.
    Most companies want people who fix problems (fast).. not who understand the problem.

    Also in order to save money, they prefer to hire fewer people with lower quality. This kills the motivation for people to learn and to understand the problems and just know the necessary stuff to get the job..

    It is also common to make technical decisions on management level, leaving the engineering with the question "how do i configure it to make it work"

    This all leads to many people relying on google to quickly fix the problems instead of spending time and reading books to understand it.
    1. A few books I'd recommend --


  4. I find gaining years of troubleshooting skills to add to your arsenal is worth just as much as learning the fundamentals of new or existing deployment changes. I like to approach troubleshooting using the OSI model, logs and wireshark are always your friend.. for Layer 7 application issues I like to keep a simple Word document which lists the error message and its solution..easy reference for future errors.. that document grows by the day. Layers 1-3 debug/warning messages aren't so simple to just document in Word, this is where a good network diagram comes in handy to map out LACP/STP/IP links and paths. I will admit, I tend to gravitate to the raw config and show commands first. Either way, it's no fun when your network is down and your scrambling to get it back up and running. My last case was where I had a Bladecenter chassis go down due to a prolonged power outage.. as soon as power was restored, the "active" LACP trunks would not come up due to STP blocking issues. Luckily we had all of our more critical stuff on another chassis. Sometimes, if you can, you can try to simplify the configuration a little more to narrow down to root cause.
    1. I forgot to add, I am finding more often, especially with the rise of Software Defined "X" and separate control planes, that a solid Out Of Band network is a MUST. You don't want that chicken and egg situation where your controllers are trapped inside of your data path.
Add comment