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…
Life & Career
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.
I am hopeful when it comes to new tech. I really am. In part, technologists are employed because of tech’s ever-changing landscape. But I am also dubious during any technology’s formative years. I take a wait-and-see approach, and I’ve never been sorry for doing so. I believe that being a late, not early, adopter of technology pays off for most organizations.
In written communication, technical people can sometimes come across as impolite. I see this on Slack (talking down), Twitter (the angry tweeter), in emails (blunt and terse), in blog comments (bitter sarcasm or pedantry), Hacker News discussions (aggressive confrontation), and other places IT builders gather online. Perhaps you, as just such a technical person, don’t […]
We love shiny things. Sometimes, we work with technologies not because our company needs them, but because we want to put new skills on our resumes. Sometime when faced with a problem, we’ll default to how we solved it last time, rather than analyzing the new situation to see what’s most appropriate. We care more than the business does at times, because our switches and our servers and our cloudy constructs become pets we cherish and teach tricks to so we can show off to others. Our designs become laws. This is the way.
My mind brings revelations to the surface when I’m out in the woods hiking, biking, or running, as I rarely listen to media when I’m out there. (It’s the bears, you see. Gotta listen for those bears.) So, why don’t I create more quiet time for myself?
How long does it take to learn a new skill? It’s like…a really long time, right? You never have that much time to learn whatever it is. Most people who learn new skills are dedicated super humans who put in 25 hour days doing labs and reading books and taking courses and sniffing markers. Those folks sacrifice everything to stay ahead and earn the tough certs. Right? Isn’t that how it’s supposed to work? Don’t overthink it.