Operator vs. Builder in an increasingly code-ish world

It's been a long time since I've written anything, and a lot has changed in a year. For those of you who don't know, I've moved on from the microservices world. I enjoyed it, but it tested me to my very limits. As with any challenge, I learned ALOT about the field, the tech, and also what I'm good at and what I'm not.

I consider myself fairly technical, but I am not an engineer/developer by any stretch, nor do I attempt to play one on TV. The world of microservices stretched my abilities in awesome new ways, including skills FAR beyond my previous capabilities. I spent more time in a Terminal window (usually multiple) in my 2 years in microservices than I have in the entire rest of my life combined. And no bones about it, 90% of the time I was completely lost (and I'm told that's considered normal)?

Prior to this gig, I was able to get along with bash fairly well, I knew my way around Linux and Mac via command line and I could do some light scripting... but mainly I was just running scripts other people wrote for me and modifying them when I needed to. I never needed to know how to build anything, especially from scratch. I didn't go to school for computer science, I've never taken a coding class, and I never had any real world application prior to force myself to learn. 

I was an operator, not a builder. 

In the world of containers and microservices, even being an operator is difficult. Anybody who has worked with Kubernetes or OpenShift will tell you:

  - Keyboard fatigue is palpable
  - Instructions are confusing (or unavailable)
  - There are a million commands to learn, each with their own function based on context
  - Error reporting is cryptic at best

 Ever tried to set up an OpenShift cluster from scratch? It's like trying to chop down a tree with a pocketknife. I've never operated in a space where the customer EXPECTS things to fail the first 10 attempts. 

That being said, there is a TON of money in this stuff. OpenShift typically costs around $10k per node...per NODE! A cluster for a microservices deployment has at least 10 nodes, but usually more like 200-500... that's a big chunk of change. 

This is because the microservices space is fundamentally different than traditional infrastructure. Once you get things deployed, everything operates with an extreme level of efficiency. Even at the basic level the amount of automation and resiliency far exceeds even the best of the best virtualization. That said, the space is still very much in it's infancy. Bugs abound (as they do with any software), support is minimal for non-RedHat orchestration, and there's just not that much generally available for it. This means lots of trailblazing. 

I define trailblazing in the engineering world as creating something that doesn't already have 10-20
stack overflow articles explaining the proper way to do it. For someone like me, this poses a huge challenge... especially in a startup with limited documentation and resources.

The people who sat in that office with me are some of the smartest, most talented engineers I've ever met. There were more folks with Ivy-league PhD's in my engineering team than folks who didn't have them... and those that didn't were definitely there for a reason. Trailblazing is a way of life for these brilliant minds. Fact is though, even engineers of this caliber struggle in this space... ask anyone I worked with, and that's saying a lot. In a startup that exists in an industry where EVERYBODY is still trailblazing EVERY day... things don't bode too well for the SE who's more of a "people person," do they?

At last, I arrive at my point. I am a firm believer that no one should ever stop learning. Acquiring new skills are how we can all continue to grow as people and increase our value in our careers. I also believe that any experienced professional knows where they excel, and where their weak points are.

There will never be any one person who is good at everything, so eventually no matter how eager you are to take something on, sometimes it's best left to the professional who made a career out of it. I will always try my damndest to figure something out before I ask for help... but eventually I have to take a step back and ask myself: "Is this the best use of my time?" More often than not, something that takes me half a day to choke through can be done in 5 minutes by one of the engineers I have the pleasure of working with.

The key is to maximize the value of their time as well as your. Any time an engineer is helping me figure something out is time taken from whatever engineering-centric task they're focused on. Because of this, I make it a point to document what I learn as much as possible every time, so they don't have to repeat the effort they've already put into my problem. I also put whatever I documented in a place available to everyone in the company, so the other folks on my team can reference our documentation before needing to go back to our engineering team. 

So previously, I was solely an operator... do I consider myself a builder now? Maybe a builder of how-to guides...