Cleared for Takeoff: The Return to Alaska Airlines

This post is my attempt to write down some of my thoughts and reflections on what has been one of the most informative, testing, and growth filled six months of my life. As you can probably surmise from the title of this post, I am returning to Alaska Airlines on Monday the 8th of July. How I got here is a whole story in itself but I’d love to write about my experiences of the past six months.

As I mentioned in my previous post, leaving Alaska Airlines was a very difficult decision for me, but I took that leap to join a startup called Upbound. In this new role, I was able to use my passion for automation to help with multi-cloud architecture, CI/CD automation, and working as a utility player either setting up the networking equipment in the new office to working in the code for some of the core company products. During my time at Upbound, I have experienced joys and challenges of a Series A startup. I am truly thankful for the opportunity to have worked there and am thankful for the people I was able to work with every day. Upbound employs some of the brightest engineers I’ve ever worked with and I’m so excited to see where they will take the company. I’m looking forward to reading and hearing about the amazing work that will continue at Upbound.

My return to Alaska will be in a very different role than I had before. During my first time at Alaska, I worked on a team which was under the IT branch of the company, and primarily worked on systems that were internally facing. This new role will be in the E-Commerce organization, which will allow my work to focus on the guest facing side of the business. I’m beyond excited for this new challenge. There is a lot of work ahead, but the very thought of helping other E-Commerce software engineers get their code shipped out faster with the end goal of improving guest satisfaction, really gets me pumped up. A big part of this new role will be to help continue the containerization and microservices effort surrounding many of the core Alaska products.

This has been a crazy ride, but one that I’m very thankful for. Upbound has made me into a better engineer and I will always be grateful for that.

It’s time to go, I’ve been cleared for takeoff…

A New Direction

TL;DR: After a wonderful run at Alaska Airlines, I will be starting as a software engineer at an exciting startup called Upbound in Seattle.

A few weeks ago, I had to make a very difficult decision; today (Friday the 11th) will be my last day at Alaska Airlines. I have been able to call this incredible company home for the past three years. It’s not an exaggeration when I say these have been three of the best years of my life. Over these years I have been blessed with the opportunity to work with some of the finest engineers and staff I’ve ever known. Every day I would come into the office feeling as if I was tackling problems and challenges with good friends, whose support and comradely made even the most stressful challenges achievable. During my time at Alaska, I’ve had to opportunity to present at ChefConf 2018 with my manager and friend Nick Kirschbaum, sharing what we’ve learned in our journey of application automation using Habitat. Our team even won an award for “automating any app, anywhere”. The work we accomplished as a whole within Alaska is something I’m very proud of and very thankful for. I am a better engineer today than I was when my journey with Alaska started in early 2016 and will always be grateful for the time I have called this company my home.

On Monday the 14th, I will begin working as a software engineer at a startup in Seattle called Upbound. I could not be more excited for this opportunity. Upbound blends together some of my biggest passions: foundation of opensource/collaboration, focus on Kubernetes, and a desire to help people run their software wherever they want (not limited to a single vendor/cloud provider). Perhaps what excites me the most is being able to help build something from early on in the game. I am excited to see where we will go and how much we can create.

Words can never truly express my gratitude for Alaska Airlines and my crew over there. My friends always tease me because I am fiercely loyal to specific things. Even to this day, I am still a walking advertisement for Virginia Mason for all healthcare needs after my time as an engineer there, and I know that I will still “bleed Alaska blue” long after I turn in my badge. It has been an absolute honor to be an engineer at Alaska and I am really looking forward to hearing where the organization will go next.

Here’s to the adventure…

The Big Shift: Moving Exclusively to Linux

Hi, I’m Chris and I’m a recovering Windows user. Friends that have known me for a long time, and who are interested in technology, can remember a time when I was 150% in the Microsoft camp. If it wasn’t based on Windows I would always deem it sub-par. I would give my friends who used Macs a hard time and you wouldn’t want to get me started on iOS.

One exception to this Microsoft-centric viewpoint I held was in regards to Linux. I always respected Linux and its famed stability. Back in the early 2000s, I worked with a small company in North Seattle that ran servers for gamers, focusing mostly on Quake III, Counterstrike, Battlefield 1942, etc. We ran Red Hat 9 at the time and I loved it. During my early engineering career, I had continued respect for Linux as a server platform, but never thought of using it as a desktop OS besides the occasional hobby project.

Fast forward to 2014, when I truly started to get into the FOSS (Free Open-Source Software) movement. It was during this time I started to see the true importance of community collaboration in development. I attended a Hackathon where I met some great developers and worked on a shared project with them. Suddenly my mindset changed. After this time, I started getting more and more involved with communities like Chef. Moving from a traditional Windows based C# development background, I found myself spending myself diving into development in Go and later in Rust. For interpreted languages, Ruby became my focus.

If anybody here has tried working in Go or Ruby on Windows, you can probably agree that it isn’t really ideal. For Ruby, the interpreter always seemed to be sluggish on Windows, but on MacOS or Linux, it just screamed. In 2016 I made the decision to move exclusively to the Unix based MacOS. This was a pretty easy transition, and I am really glad for that time. I found myself spending most of my time in the terminal, finding Outlook and Firefox the only apps that I needed a GUI for. I made the switch to Neovim for my text editor and finally I was able to spend my whole day in the wonderful terminal  behind a beautiful Dracula color scheme. My heart was whole, or so I thought.

Let’s fast forward to fall of 2017. I was happy with MacOS and its strong Unix foundation, but I was getting frustrated with some limitations I was facing, along with some personal conflicts with the expensive hardware needed to run the system (besides making a Hackintosh). I began considering a move to Linux as a desktop OS. I got myself a pretty killer Dell laptop and loaded a few Linux OS versions on there until I settled on one that fit all my needs: Fedora. Fedora is the upstream distribution for the famed RHEL (Red Hat Enterprise Linux) that is the industry leader for enterprise Linux. I fell in love immediately. I can now say that I run Fedora 27 and 28 on all of my personal computers. Moving from my MacOS setup to Fedora was a breeze. Thankfully, so many applications used in the DevOps world work perfectly with Linux. Some of these include Slack,, Firefox, etc.

I have now been using Linux excludsivliy for over six months and I have no desire to go back. Infact, a few months ago I sold my personal Macbook to a buddy of mine at work, because I just was not using it.

What’s even more exciting than using Linux as a desktop OS for myself is seeing my friends interested in the journey too. I have a few coworkers who have taken the plunge too and are very happy.

All this being said, I encourage anybody interested in FOSS and getting away from the prescriptive world of OS offerings by Microsoft and Apple to check it out, it’s a fun journey and it puts you at the helm of your ship once again.

Good hacking!


Tiny Rudder on a Large Ship: Driving Organizational Change

I’ve been wanting to do this for some time now. Over the years, working in both the operations realm and in software development, big themes seems to present themselves. These themes are always in the back of my head, but I haven’t had a place to write them down or share them with others. After a long time, I have finally decided to launch

As I’ve been trying to figure out what to write about for that first “initial post”, many different ideas were circling through my brain. First it was ideas surrounding code, but I didn’t want to start swinging for the geeky fences right away, so I opted to share a personal story of my journey in this field and learning how to deal with big changes.

My career could be summed up as existing in three IT/developer pillars: healthcare, finance, and aviation. The first being my foundation, the place where I grew up. That would be in the world of healthcare IT. I spent the beginning of my career as a desktop technician intern at local hospital in Seattle at the age of 16. This is an opportunity I will always look at fondly. Having always been interested in technology, this was a incredible first job, and taught me at a young age the joys and complexities of working in a large IT shop. It was at this age I was exposed to the challenges of organizational bureaucracy. Too often it was easy to come up with a cool new idea of ways to improve a process, or help make things more efficient, but find that those ideas would get immediately shot down under the dreaded mantra “we have always done it this way”. Oh well, through years of working in the non-profit healthcare world, one learns to be creative and I am forever thankful for the time I spent at the hospital, eventually working up from desktop intern to systems engineer. I learned the importance of innovation, as budgets often dictated the needs for creativity when other solutions were out of reach.

The second pillar, the smallest of the three, was time spent in the industry of high finance. Wow, talk about a difference in business style from non-profit healthcare. Instead of adhering to super strict budgets, there was appeasing shareholders and those invested in the company. Dropping hundreds of thousands of dollars on servers was something you’d do without blinking an eye. This was a wonderful place to grow and learn. It was, however, an atmosphere I didn’t long to be in for an extended period of time. I never felt “at home” in the financial space, and it wasn’t until my third pillar that I found my niche.

The third pillar was with Alaska Airlines. This is a place that I truly love and where I am challenged every single day (something I’ve wanted desperately my entire career). One thing I missed about my crew at the hospital was the genuine comradely I had there, and at Alaska, I have that again. The atmosphere at Alaska is one of collaboration. Never do I hesitate helping a coworker with an issue or in turn, never feeling fearful of asking questions myself. This atmosphere really brings together things from both the non-profit healthcare and high finance worlds that I loved: collaboration and resources needed to get things done.

There is always the other side of the coin, the issues that every company, no matter how wonderful, faces. The issue that I feel we face now, and one that so many of my friends in the automation world feel as well, is that of resistance. Automation gets a bad rap by those who don’t understand what it really means. Some fear automation, understanding it to be the beginning of the end for their jobs. Others look at automation as a hassle, something more difficult to implement than the job being looked at automating. These challenges can be often overcome with some honest conversations and lots of promoting, helping to demonstrate the excitement of automation.

This biggest hurdle that I have found in large organizations is the time it takes to adopt automation and the blending of the operations and developer worlds. Alaska Air is a large organization, and when people ask me how my job goes, I often reply with “we are the like the small rudder on a really big ship“. This essentially means that driving change requires a commitment, one that will take time, but will ultimately get us where we want to go. On the team that I work on, we are slowly but effectively chipping away at this in the organization. Part of our strategy is engaging teams of engineers and developers, often whose software and processes are very time intensive or require a lot of manual interaction. When we start to show our automation offerings, you can almost universally see the excitement in their eyes. When that “ah ha!” moment happens, when people really get it, that’s when we start seeing the ship move just a little bit towards our destination.

This was a lot of rambling, and I promise not to do too much of this moving forward. Truly my passion is sharing information and code, as open source is my love. This being said, I want to encourage all of those in this field to not give up, especially if you’re coming from a small shop, or startup, where rapid change is expected and you find yourself perched on a huge ship. Changes can happen, they just take time and determination. My father has a couple of wonderful quotes that he has shared with me over the years. One I can safely attribute to him, and it really speaks to our work as automation engineers:

“Persistence, especially in the face of adversity, is the key to success” – Denny Maher