Chapter 4 – Curiosity and Learning

Most of what I’ve discussed in the past three chapters has not centered around technical things.  This chapter will pivot on that point a bit.  I did say earlier that the vast majority of an architect’s responsibilities will center around long term designs, and socializing those designs with other folks.  In other words: staring more at PowerPoint than you are a command line interface.  But focusing too much on that will cause the techie side of your brain to atrophy a bit.  You want to avoid that.

It’s important to stay technically sharp.  That means you want to keep abreast of the current and coming technologies in your specific field.  But you also want to consider expanding a bit and learning other technologies that may only be tangentially related.  If you’re a network engineer and looking to become an architect, do you understand DNS, for instance?  Do you understand A and PTR records, how to get a BIND server, running, and how to make changes to it?  How about sendmail?  Can you speak to a sendmail daemon directly and send someone some mail via the telnet command?  These and other things will have very little impact on your day to day role as a network engineer or architect, but they round your skillset out more, and make you even less myopic.

It’s hard to stay how important this is or exactly why.  Flip back to the last chapter where I discussed being social versus just being transactional with your coworkers.  Expand that to your own skillset: if you’re a very skilled network engineer or architect and that’s all you know, then you’re going to be limited to doing that sort of work.  And that may very well be OK for you, too.  But expanding your skills could potentially make you even more valuable to your present employer, as well as more interesting to future ones.  Further, it could help you discuss challenges that other folks, such as internal customers, are facing with their systems or servers.  If you understand the technologies they’re working with, you can relate easier, and have more productive conversations with them.

What’s more important in my opinion is the curious mindset.  What I mean by that is: someone who is genuinely technically curious about things he or she doesn’t know or understand, and takes steps on their own to fix that.  It’s certainly helpful to have an employer that fosters on-the-job learning via classes, for sure.  But what about outside of work?  What about on your own time after hours, on weekends, or other days off?  Sure, some work-life balance is important and I’m not trying to downplay any of that.  But if you’re running ragged each day at work, you might have to take some time out of your private life to learn some new things.  And you should want to, too.  That’s the point.

How I Did It

Like with the last chapter, I’m still working on this.  It’s less so, “How I Did It” and more like, “How I Continue to Do It.”  I’ve always been a technically curious individual.  The first time I logged into a UNIX workstation back in 1991, I was instantly hooked and just had to understand it thoroughly.  Throughout my adult life, I’ve taken a lot of my own time to learn things that may or may not have a direct impact on my current role.  In my early 30s, I finally decided to start taking the last week or two of December off instead of wasting my vacation time.  But during that time, I’d generally cook up a technical challenge for myself, and spend the time off learning it.  For instance, one year I decided to finally get over my fear and ignorance of IPv6 (this was over a decade and a half ago…).  I spent my Christmas break working through Hurricane Electric’s classes until IPv6 was basically second nature to me.  Another year, I spent time burying myself in VXLAN work on my VM server, before VXLAN was a big thing in data centers.

I’m writing this chapter during my two-week Christmas break.  As it turns out, I spent a few hours during the first weekend of this break finishing up something I want to propose at work.  This involved me working through my virtual environment, trying to prove out some concepts, which did ultimately work.  None of that was required or asked of me, but it was an interesting experiment and it taught me a couple of things that I might be able to apply in the future.

There’s lots more, but I think you generally get the idea.  I’m a geek.  And I thoroughly thrive on that.

Next: Mentoring

Push back from the configuration grind as an architect, and embrace the new tools of your trade.  But, don’t forget all that technical know-how that got you there in the first place.  And, in fact, keep fanning it so that it doesn’t extinguish on its own.  Up next, I’ll dig into mentoring a bit.  I may skip a week since, oh yeah:

Merry Christmas, bah! Humbug… and all that jazz.