Posted on Mon 05 November 2018
I remember that there are test patterns built into T1 CSU/DSUs, but not what they are or how to turn them on – if I need to know, I’ll look it up.
I remember that there are three QoS bits in the IPv4 header, but not where they are. Probably pretty early, because of hardware implementations.
I remember that lots of people look down on Perl 5’s object system, but not why. I remember the existence and purpose of lots of Perl modules, but not the interfaces.
I edit JSON and YAML every few weeks, but I don’t have a conscious recollection of the rules – they’re prompted by looking at what’s already there.
I can guesstimate Big-O notation on most chunks of code, but I’ll be fooled when there’s a function that’s hidden in a library because I generally don’t have those memorized.
I can tell you the bandwidth of lots of hardware interfaces, and the relative efficiency of speed and efficiency of storage for a handful of RAID configurations – the ones that I set up, and the ones that I avoid.
I know one firewall configuration tool reasonably well, which means that I look up esoteric bits, and have used so many that I expect to do common things in all of them with a quick examination of the language.
I currently know a fair amount about GDPR and why it doesn’t apply to my company (and how we can assist customers with their GDPR requirements) and lots about the Massachusetts and Virginia data privacy law. Very little about PCI compliance, but my point is: if my company wanted to do card transactions, I can figure out what I will need to learn to write a good policy and get it implemented in a way that won’t embarass anyone.
In short: when the job is the same thing over and over again, you memorize the details. When it’s always something new, you need a broad overview about what can be done and where to find the details. And “always something new” is more fun for me.