Archive for 2023
The RFC Process
I’ve just finished a seven-part series over at Packets Pushers about the process of writing and publishing an RFC. Even if you don’t ever plan to write a draft or participate in the IETF, this series will give you a better idea of the work that goes into creating new standards and IETF documents.
Hedge 206: Taking Care of Yourself with Ethan Banks
As we reach the end of what has been a hard two-year stretch for what seems like the entire world, Ethan Banks joins Tom, Eyvonne, and Russ to talk about the importance of taking care of yourself. In the midst of radical changes, you can apply self-discipline to make your little part of the world a better place by keeping yourself sane, fit, and well-rested.
Thoughts on 2023
As we close out 2023, some random observations about engineering, culture, and life.
Network engineering needs help. I am hearing, from all over the place, that network engineering is “not cool.” There is a dearth of students entering the pipeline. College programs are struggling, and many organizations are struggling with a lack of engineering talent—in fact, I would guess the most common reason for companies to move to “the cloud” is because they cannot find anyone who knows how to build an operate a network any longer.
It probably didn’t help that for the last few years many “thought leaders” in the network engineering space have been saying there is no future in network engineering. It also doesn’t help that network engineering training has become stilted and … boring. Coders are off talking about how to solve problems. Robotics folks are working on cool projects that solve problems.
Network engineers are being taught how to spend less money and told to “find another career.”
I don’t know how we think we can sustain a healthy world of IT without network engineers.
And yes, I know there are folks who think networking problems are simple, easy enough to solve with some basic software knowhow. I think I have enough knowledge and experience of the wider world of information technology to say those folks are wrong.
I’d actually like to help solve this specific problem. I’ve been looking for a Christian college someplace in the US interested in starting or growing a strong engineering program. Someplace where I join with a team to help build and teach an entire program from the first class to the last. If anyone knows of such a place, get in touch. We need to make network engineering cool again.
How much did you read this year? I read just over 40 books this year, not many of which were technology related. If you don’t read regularly, why not?
How much did you create this year? I wrote one book—the CCST Official Study Guide. I’ve written two dozen articles or so and created a few new slide decks. I’m working on several new live webinars with Pearson through Safari Books Online, including interview skills, open-source labs, some work around coding skills, and a few other things.
It you aren’t creating new things, why not?
Big is, for the most part, bad. I’ve started thinking that one of the worst things about technology-driven culture is how deeply it has enabled and taught—even encouraged—us to be passive-aggressive.
For instance, I’ve been “lifetime banned” from eBay. Why? I’ve no idea—I barely even use eBay. I logged in, listed a few items for sale, and then couldn’t log back in again. I tried to reset my password—the service accepted my new password, but still refused to allow me to log in. No notifications, no email, no … anything. I called customer support and was told I have been “banned for life.” They will not discuss why, only that some “system flagged my account.”
It is just this kind of “the computer says you are a bad person, and we will not explain why” thing that makes people dislike technology companies so deeply.
As always, feel free to get in touch if you have thoughts, want to chat, or have an idea for an episode of the Hedge.
Weekend Reads 121523
Weekend Reads 120923
Hedge 205: OId Engineering Quotes
For this month’s roundtable, Eyvonne, Tom, and I return to Addresses to Engineering Students by Harrington and Waddell. This book, published in 1912, is a “product of its time,” and hence deserves some trigger warnings. But it is also interesting to see how advice given to engineering students over 100 years ago holds up for today. Have engineering challenges, and the engineering life, changed all that much? What kinds of advice stand the test of time, what kinds do not?
Upcoming Pearson Class: Modern Network Troubleshooting
On the 26th of January, I’ll be teaching a webinar over at Safari Books Online (subscription service) called Modern Network Troubleshooting. From the blurb:
The first section of this class considers the nature of resilience, and how design tradeoffs result in different levels of resilience. The class then moves into a theoretical understanding of failures, how network resilience is measured, and how the Mean Time to Repair (MTTR) relates to human and machine-driven factors. One of these factors is the unintended consequences arising from abstractions, covered in the next section of the class.
The class then moves into troubleshooting proper, examining the half-split formal troubleshooting method and how it can be combined with more intuitive methods. This section also examines how network models can be used to guide the troubleshooting process. The class then covers two examples of troubleshooting reachability problems in a small network, and considers using ChaptGPT and other LLMs in the troubleshooting process. A third, more complex example is then covered in a data center fabric.