2022 has been a wild ride from a career perspective. I started the year at Microsoft and ended the year at Amazon Web Services. I thought it might be interesting to post a recap of my year. The work I did, lessons learned, and what I hope to get out of 2023.
DISCLAIMER: Everything I am writing I am writing as Brock Davis and not as a representative of said company. These are my personal views and do not reflect that of the company in which I speak of :)
Microsoft
I started my year at Microsoft, knee deep in working on Word Coauthoring. My team was working to solve some pretty complex use cases for some large customers. During my time on that team I got to work with some of the most talented engineers on the largest code base I have ever and probably ever will work on. Here are some of my key takeaways from that experience:
You don't know what you don't know
Microsoft Word is a 30 year old product and some of the code I cam across was written when I was in kindergarten. There is technical debt and then there is whatever you call 30 years worth of coding into one of the most used products in the word. Every bit of code made sense at the time it was written, but would baffle me looking at through the lense of a modern stack. What I learned in going through it all was, you don't know what you don't know. So it makes it really hard to ask the right questions.
Eventually the team and I decided to ask all the questions. Smart ones, dumb ones, wrong ones, right ones. We did not know what we did not know, so we assumed nothing. What came of that were stories and reasons why things were done the way they were. For example, there were pieces we were working on that would constantly go back to disk rather than using memory. The reason? Because the underlying logic was written when machines had megabytes of RAM rather than Gigabytes, so doing things in memory was not an option.
This taught me that no matter how much experience one has, no matter how confident you feel that your way is the right way, you should always ask questions.
Good ideas and bad ideas come from everywhere
This is a carry over from some of the hard lessons I learned when I first started Microsoft but it is still true in 2022 and will be in 2023. That is, good ideas and bad ideas come from everywhere. When working on teams of engineers, everyone is smart, really smart. Ideas though, should always be challenged and discussed. One should never assume because an engineer has N number years of experience or is a Principal engineering that their idea is the best way. You also should not assume that a person with 6 months of experience ideas are bad. Everyone should have a seat at the table and challenge one another's perspectives in a respectful way. This encourages a growth mindset and helps everyone on the team learn.
People come first, always
One of the things that stood out to me at Microsoft and still does even though I am not there is how well they treated their people. I saw reorgs happen to enable a person to focus on their health and recovery, workloads shifted so people struggling with effects of Covid could focus on their mental well being and getting back to full productivity, and people up and down the leadership chain genuinely reach out to see how folks were doing. This sort of focus on people and making sure they come first increases loyalty, dedication, and happiness in a job. This in turn reduces attrition which saves money, improved productivity, and usually results in people putting their soul into their work which just makes for better products. I have been at a few places and I have seen no other place treat their employees better than Microsoft. What I experienced first hand there made a huge impact on me and directly influences the culture I try to create on the teams I lead wherever I am.
The Walt Disney Company
I had a very short stint at Disney working leading the DevOps team for Disney Streaming web. I was only there a short 3 months I still learned some things there.
Don't make mountains out of mole hills
This lesson was learned only after I left. There were things that really irked me while at Disney, but in retrospect they were silly. Growing pains of multiple organizations coming together, personalities and new folks learning to work together. These things seemed really important and worth stressing over at the time. I made mountains out of mole hills and looking back on it I probably should not have. What I failed to see at the time is everyone was and is just trying to do their best. So it is important to give grace and help where you can. You won't agree with every decisions and you won't like everything that is said, but it is super important to zoom out and see the bigger picture. Ask yourself, is it really that important to get flustered over? 9 times out of 10, it is not.
There is scale and then there is Disney scale
A short a sweet note here. I have worked on large scale things but Disney's scale is next level. The amount of customers they have using their streaming products, the level in which the engineering teams there go to make sure they can expand to new territories and regions with ease and little to no hiccups is amazing. What really impressed me was how little they seemed to realize how impressive this was. It was second nature to the folks I worked with and that is commendable. Another thing worth thinking about is how relatively quickly Disney went from not having a streaming service to being a dominating player. From their excellent IP to their impressive tech stack and scale, you may not think of Disney as a tech company but maybe you should.
Amazon Web Services
I have been at AWS for 6 months and change and in that time I ramped up a new team that is responsible for all of the Ubuntu, SUsE, and Red Hat AMIs. These are building blocks for some of the most widely used services and images used by the largest companies in the world. We also expanded into 4 regions and launched a few new products (e.g. RHEL Workstation). The speed in which Amazon moves and the scale and impact a team can have is probably unmatched by any other place an engineering manager could work. I obviously am still learning a ton but here are a few things I have picked up so far.
If everything is top priority, then nothing is
I have a relatively small team but we are responsible for a lot of things. This means prioritization is key. There are only so many engineering hours in a week and it is finite. Because of this, not everything can be done and certainly not everything is number one priority. Everything is a negotiation. If a customer comes with an ask or Product Management needs a thing done, you do not tell them no, you give options. My team can do X but that means we will have to delay Y. You provide estimates on all the things being asked of you and then that helps tell the story of what is important, what will get the most bang for the buck, and what falls below the cut line. This is a super important skill I have picked up over the years but feel like I am mastering it at AWS.
People still use servers, like a lot
This one shocked me and will continue to shock me. Originally when I interviewed for AWS, it was not for the EC2 team. Fate had different ideas and I landed within the EC2 org. EC2 instances are things in previous roles I generally avoided at all costs. I did not like managing boxes, worrying about patches or updates, and I had no need to log in to a box to do anything. Serverless was the way for me. Give me containers, Lambdas, etc. all day everyday. I understand there are servers under the hood of those things that make them work but I don't want to touch them. I thought this sentiment was also true for most companies and engineers.
My time in EC2 however has shown me I was incredibly wrong. Companies, teams, and people use EC2 instances a lot and have a real need for them. There are use cases I had not even considered prior to joining. It has been a real eye opener and given me a new found respect for a service I previously looked at and thought "but why?".
Linux is a hard
Prior to becoming the SDM for the Commercial Linux AMI team I had about zero real experience with Linux other than WSL on Windows and a few DevOps-y things I had to do with pipelines. Working on an actual Linux OS, worrying about CVEs, thinking about kernel updates, upstream/downstream, forks etc. These were things I just did not know about or care to know about. Now I run a team that has to know about it, works with other teams that know about it and care a lot about it, and my assessment is.... Linux is hard. When I joined one of our directives was to make our engineering processes match that of the Windows AMI team which sounds nice in theory but Linux is just a wild place.
Windows for example has patch Tuesday. Linux, depending on the distribution, can have a patch Thursday at 4:38AM one week and then 2:00PM on a Monday the following week. There are no regular cadences on how the packages have to be updated, CVES can come from all sorts of places, and ratings do not match on all distributions. So yeah, Linux is hard. Hats off to every Linux master out there. I feel way more confident now in my abilities but I know I am barely scratching the service.
Looking Ahead to 2023
Going into 2023 I want to continue to grow in my current role and learn everything I can. I also want to focus some time and energy into game development. Video games have been a part of my life since as far back as I can remember and coding is something I have loved and mae a career out of. I want to take those two passions and turn it into something fun and potentially lucrative at some point. So I will be using this site as a place to document my progress, share what I have learned in game development (and other tech things as part of my "day job"), and hopefully grow a following that will play whatever game I end up putting out there.
I hope to take the lessons I have learned this year into how I lead my team at AWS, how I prioritize my day job and this new venture, and I hope to keep everything in perspective.