Hedge 216: Automation Success Stories

One thing we often hear about automation is that its hard because there are so many different interfaces. On this episode of the Hedge,
Daniel Teycheney joins Ethan Banks and Russ White to discuss how they started from a simple idea and ended up building an automation system that does cross vendor boundaries within a larger discussion about automation and APIs.

Hedge 215: Old Engineering Books (3)

Reading people from the past can sometimes show us where today’s blind spots are–but sometimes we can just find the blind spots of the people who lived then. In this episode of the Hedge, Tom, Eyvonne, and Russ finish going through a selection of quotes from an engineering book published in 1911. This time, we find there are some things to agree with, but also some to disagree with.

Hedge 214: Hardware Offloading

Network operators increasingly rely on generic hosts, rather than specialized routers (appliances) to forward traffic. Much of the performance on hosts relies on offloading packets switching and processing to specialized hardware on the network interface card. In this episode of the Hedge, Krzysztof Wróbel and Maciej Rabęda join Russ and Tom to talk about hardware offloading.

Hedge 213: Batfish with Ratul Mahajan


 
Network configuration analysis has always been the domain of commercial-grade software. Batfish changes all that with an open source, community-supported tool that can find errors and guarantees the correctness of planned or current network configurations. Ratul Mahajan joins Tom Ammon and Russ White to talk about this new tool, its capabilities, and the importance of network configuration analysis.

Hedge 212: Shift Left? w/Chris Romeo

How many times have you heard you should “shift left” in the last few years? What does “shift left” even mean? Even if it had meaning once, does it still have any meaning today? Should we abandon the concept, or just the term? Listen in as Chris Romeo joins Tom Ammon and Russ White to talk about the origin, meaning, and modern uselessness of the term “shift left.”

On Writing Complexity

I’ve been on a bit of a writer’s break after finishing the CCST book, but it’s time to rekindle my “thousand words a day” habit. As always, one part of this is thinking about how I write—is there anything I need to change? Tools, perhaps, or style?

Hedge 211: Learning About Learning

How much have you thought about the way you learn–or how to effectively teach beginners? There is a surprising amount of research into how humans learn, and how best to create material to teach them. In this roundtable episode, Tom, Eyvonne, and Russ discuss a recent paper from the Communications of the ACM, 10 Things Software Developers Should Learn about Learning.

Hedge 210: Eric Chou and Technical Publishing

Have you ever thought about publishing a book or recording a professional video? It’s not as simple as proposing an idea, doing the work, and becoming famous (or infamous, as the case might be). Eric Chou joins Rick Graziani and Russ to talk about the ins and outs of technical publishing. We are planning a part 2 of this in a few months to cover things we left on the table for later discussion.

Hedge 209: User Interface Stupidity

User interface design is notoriously bad for networking gear–but why, and what can we do about it? Frank Seesink joins Tom and Russ to talk about user interface stupidity.

Making Networking Cool Again? (2)

Network engineering is not “going away.” Network engineering is not less important than it was yesterday, last year, or even a decade ago.

But there still seems to be a gap somewhere. There are fewer folks interested than we need. We need more folks who want to work as full-time network engineers, and more folks with network engineering skills diffused within the larger IT community. More of both is the right answer if we’re going to continue building large-scale systems that work. The real lack of enthusiasm for learning network engineering is hurting all of IT, not just network engineering.

How do we bridge this gap? We’re engineers. We solve problems. This seems to be a problem we might be able to solve