Looking at my desk in the late 1990’s, that little haven where I came in early in the morning, and left ealry’ish in the afternoon, you’d see a catalog rack. Only it wasn’t full of catalogs, it contained a full set of the latest Cisco IOS documentation. We whined when a new version of the docs came out that wouldn’t fit in the catalog racks we already owned, and ordered another one. There was a bookcase on the side which contained the documentation from the last two or three versions of the IOS code, and then every hardware manual I could find. Another stack of books would be lying in a corner, the “quick reference” stuff that wouldn’t fit in one of the catalog racks. All over the walls were pieces of paper, carefully crafted shortcut sheets, shared around the TAC, pinned up. Given the nature of cubicle walls, we either bought special cubicle clips, or we made to do with various sorts of push pins. Just a few years later, the ISO auditors came along and made us throw it all away. Every last scrap. The dumpsters were filled to the max. Extra dumpsters were brought in, and we filled those to the overflowing. What did we do? We rebuilt all of it on internal web pages.
Why am I talking about catalog racks?
Because we had a word for the frenzy of activity in that time period in the TAC, with its mounds of manuals, pounds of paper, and, finally, its web of bytes containing so much of what was interesting in the early networking industry.
Sipping from the fire hose.
Now that I’ve been working on networks for 20 years, I’ve discovered something: we like sipping from the fire hose. It’s somehow exciting to live in a world where there’s always some new technology that’s just coming, in a world where we truly believe this will change everything. It’s exciting. It’s interesting. But there’s also a downside. Not only is burnout a real option, but tech folks tend to end up being insecure, unhappy, constantly looking over their shoulders. Why? Because you just can’t sip from the fire hose fast enough to really keep up. From an article over at Idlewords —
(btw, the entire article is worth reading)
I know this is hard to hear, and it’s even hard to say. But, look — there is such a thing as good enough.
There, I said it, and the sky didn’t fall. The walls didn’t start their inexorable squeezing like every great SciFi movie requires. The end of the world didn’t come.
There is such a thing as good enough in our networks. We don’t need to design for a moon shot, we need to design for the problem set in front of us — not forgetting that one of those problems is going to be inevitable changes, and therefore flexibility is a grounding requirement. Do you know what happens when you forget “good enough” in network design? I once talked to an architect at a large corporation who said, “our network is a mashed up ball of every failed networking product and system push by our primary vendor.” I looked at his network diagrams, and I realized he was right — I could recognize the sea flow of initiatives that had passed through the fire hose over twenty years.
There is also good enough in your skills. Do you really need the 6th CCIE? You need to learn continuously, but we’re often on a treadmill of “have to learn,” said at 2AM as our family peacefully sleeps, knowing we’ll be a crank in the morning so we could build just one more lab overnight. Part of this is our fault, of course, because we, each, individually don’t do any better at going through resumes looking for engineers (rather than someone with the right buzzwords), than HR or anyone else. Part of this is our fault for choosing a world where the excitement for the new and novel, the squirrel, dominates.
So this is what I think needs to be said to those who are entering the engineering field — particularly network engineering — it’s okay to be good enough. It’s okay to focus on understanding the theory, and not worrying so much about each individual bit. It’s okay to go to bed and get up a happier person — it’s okay to leave that lab ’til tomorrow. Don’t stop striving for excellence, for new knowledge, for new concepts. But don’t forget to build a foundation of fundamentals on which to build real skills, rather than just flash in the pan “I know the latest thing so I can put it on my resume.”
And don’t forget that oftentimes good enough is just, well, good enough.