I prefer to hire a person who first tries to figure things out. While I want neither a cowboy nor science experiments making their way into production, I do want a motivated individual who will research difficult technical challenges and grow as a result. As that person grows stronger, their team grows stronger as well.
I surveyed 53 IT professionals about online IT training in August 2021. Most of the folks I interact with are networking & cloud infrastructure professionals, and the answers reflect that. 53 responses isn’t enough to draw hard and fast conclusions from, but I still believe there are interesting trends & individual comments worth thinking about.
From a technical perspective, I believe a senior IT engineer is primarily differentiated from a junior in one word–experience. The senior engineer has installed more systems, planned more changes, fixed more problems, and survived more outages than a junior engineer in the same organization. Ideally, that experience has led to wisdom about how technology can best serve the business needs of an organization. This wisdom will tend to eschew needlessly complex designs, nerd knobs, and “science experiments” conducted in production. But this post is more about the non-technical skills…
Most of the search engine hits for “upgrade PHP on WordPress” told me to go into CPanel or a similar tool my hosting provider might offer to abstract what’s going on with the server itself. That’s not what I was looking for, because I manage my own hosts. I needed to know how to reconfigure the host itself. The OS packages to install. The conf files to tweak. The processes to restart. This was not obvious, as the magical CLI incantations required to complete the task varied depending on which Linux distro and HTTP server I was running on a given box.
Let’s think about what happens when a business does not stick with their incumbent networking vendor. Is changing networking vendors adopting new technology, and therefore fraught with risk? If I change from Cisco to Arista for data center switching, or to Aruba for my wireless, or to Juniper for my edge routing, or whoever and go all-in on their ecosystem, is that change really as risky as Cisco’s continuing dominance implies? My experience is that no…it isn’t.
Architects and engineers tend to be introverts who are at times unsure of themselves. We don’t want to be learning in public. We want to be left alone to figure it out. When we’ve figured it out, maybe then will we share, once we’re supremely confident that we’ve got it 110% right. We just don’t need the headache of criticism, controversy, and the “but actually” pedants.
Backups are crucially necessary and incredibly boring all at the same time. We almost never need backups, and so they tend to fall down the task list next to “update interface descriptions to the new standard” and “write the new standard for interface descriptions”. Yet, when disaster strikes, the most important thing in the world might be recovering from that backup data.
Zero trust assumes that every endpoint has been compromised and represents a threat. Therefore, even though an endpoint is connected to the network legitimately and allowed secure access to resources, the access requests themselves are suspect.