How I Got Here - I'm Still an Engineer!

At some point in early 2006, I found myself interviewing for a software engineering position at Orbitz (the travel company, not the gum).  I'd already secured a position at a smaller company in the West Loop of Chicago and was entertaining the Orbitz interview with the expectation that I'd turn it down, because the role would be too corporate (Orbitz was far larger than the other company, but, as I came to realize later, it was in the Goldilocks zone of company sizes for me).

The interview went well, to the point that I actually exclaimed "I'm having fun," and meant it, but, again expected that Orbitz, being a larger company, would pay me a smaller increase than the other company had offered (which wasn't quite a 10% increase over my then salary).  Boy was I wrong.  Orbitz offered me a 30% raise and the position of Software Engineer II, skipping entirely over the SE I position I'd coveted.  I got the position in large part for spending time writing various payroll parsers at my previous gig, demonstrating an initiative that I'd just stumbled into out of enthusiasm rather than ambition.

I was thrilled about the new spot and also terrified.  My impostor syndrome kicked into overdrive.  I was making more money than I'd expected to see for at least the next 5 years and had an inflated title (and, presumably, responsibility) to boot.  At one company happy hour, I chatted with a couple of directors who were bantering about the usage of the intern method for strings in the Java API.  

I simultaneously thought - "Wow, I can't believe people are talking about programming at a happy hour!" and "I have absolutely no clue what the hell these people are talking about.  I'm going to be fired in 2 months!  I can't keep up."

Well, I didn't get fired, but I did have some adjustments to make.  I'd been conditioned during my previous exposure to professional services work not to make changes to core code functionality.  So, when I was tasked with re-writing the sign-in logic for the Orbitz site, I left much of what was in place alone and papered over it with my own odd-fitting data structures.

My team was very supportive during the ensuing code review, but there was certainly an air of awkwardness along with the voice in my own head questioning just what the hell I was doing there, anyway.

I also didn't appreciate unit testing (or any automated testing), believing that it was just extraneous because I was writing code for functionality I'd already tested manually.  It wasn't until a colleague of mine described its use as a design tool for writing more modular code and preemptively spotting edge cases (and suffering through a lot of unnecessary bugs) that I understood the usefulness of unit tests.

Even so, I still maintained the persona of a Prima Donna Developer who wrote the code and chucked it over the wall to operations (and, I'll admit, have very likely uttered the literal phrase, "it works on my machine" when confronted with a failing system in production), so I still had a ways to go on my career development path.

All of that changed a couple of years later when I joined a small infrastructure team.  We maintained a critical application handling dynamic service discovery (if you're non-technical, think of it as a directory where services need to look up other services to access functionality from those other services in order to keep the site running).  The app was written in a relatively obscure language named Erlang (note of no consequence to this story: though obscure, I still believe it's my favorite language of all time), and I was the only programmer on the team who knew Erlang, so I was the only engineer who could support it.

And it was highly unstable.  

It was our literal network hub for communication between services.  Every time it went down, the site would go down along with it.  And it went down way more often than anyone felt comfortable with.

While I can't say that the 2+ years I supported the app were consistently full of joy (I had to tell our Network Operations Center that they wouldn't be able to contact me on a particular Saturday, because I was carving out some time for myself to get married), it was likely the greatest period of growth for me.

I came to know everyone in our NOC (referred to as the Service Operations Center, or SOC, at Orbitz) on a first-name basis.   Any notion I had about the separation between development and operations quickly dissipated when I was able to see firsthand how the code I wrote affected the scalability and operation of the site.  I also had the opportunity to see how much work the operations teams did on a day-to-day basis to keep the site functioning, sometimes working against the very code developers wrote that, naively, we didn't realize was so harmful.

Eventually, after much more time than it should've taken for me to come to such an obvious realization, I was able to make a very simple change to the service discovery application to keep it from crashing.  Rather than trying to pass all traffic through the application (which was only growing by the day as our site got more complex), I used the app as a simple lookup service and let the other apps do the necessary work themselves (this is how modern service discovery tools like Consul and portions of Kubernetes work today, so, apparently, I was on the right track if a little slow on the uptake).

After 3 years, the infrastructure team I was a part of disbanded, and I was moved into the realm of a more traditional travel product - hotels.  By this time I had worked my way up to senior engineer and was happy with my role.  I had aspirations to make the jump to the next level in the engineering progression - Tech Lead - but wasn't in a hurry to get there.  I liked the balance of responsibilities and freedom that Sr. Engineer afforded me and was in no rush to move on.

After, 6 months on the team, I received a pleasant surprise and was promoted to Tech Lead.  Tech Lead at Orbitz was still a technology-focused role without management responsibilities.  I had no aspirations to join the management class and was happy to serve solely in a mentor role rather than have people report to me directly.  I'd decided long before that management wasn't a career path I was interested in.

In my new role, I was looking forward to diving into more complex topics like Java Virtual Machine tuning and understanding how to increase the scalability and reliability of the hotel stack.

Life, however, had other plans.  A month into my new gig, someone in one of the more senior tech roles - the head of a department was referred to as a Group Manager - left the company.  This allowed the Hotels GM to take on that vacated role during a minor department restructuring, which, in turn, allowed my boss to become the Hotels GM, which, in another turn, left a vacuum for the position of manager on my current team.

I first heard the news during a stand-up (an actual, physical stand-up where we went into a separate conference room for 15 minutes) and quickly realized what that meant as I started looking around the circle of attendees.  With one exception, everyone else in the room was much more junior than I was.  The exception had previously tried out team lead duties on a temporary basis and didn't want to travel down that path a second time.

Once all of this registered, I started to get light-headed and could feel my knees begin to buckle.  As I recovered from my swoon, dear reader, I realized that now I was a manager.

Until next time, my human and robot friends.