Five years at Microsoft

Today marks five years at Microsoft. It simultaneously feels like a lifetime and that it has gone by in the blink of an eye. I thought I better capture some thoughts on the last five years, so here I am throwing this post together to cover my highlights of this time. I'm writing this on December 11th, and despite knowing this anniversary was coming, I only just thought to note this down now. Let the brain dump commence!

Leaving Oracle and interviewing

I should probably start this post back in mid-2017, a few months before I left Oracle. I spent nine years at Sun Microsystems and Oracle working on JavaFX and other Java technologies. I was always so immensely proud to say to developers that my code was on their system. I worked hard for a long time, always from home in New Zealand, and I'm proud of what I achieved during my time at Sun Microsystems and Oracle. Unfortunately, as tends to be the case at Oracle, eventually most people find their time is up, especially for those in exotic locations (I have many stories to tell one day about how whole offices were shut down, or world-leading engineers were let go, for objectively bad reasons). Eventually my time was up, and although I'm pleased to have had the last year or so to help train up my replacements, I can't say it wasn't a sad period in my career. I still can't quite reconcile the Oracle perspective on JavaFX - Oracle seem to be lost about what to do with it. It gets defunded and largely offloaded to external companies, and then occasionally funding reappears and plans change. For the most part, Oracle seems to leave it lingering in a weird intermediate state. I sometimes see (and even get pinged about) jobs going at Oracle to staff up the team again, although I don't know the status of the team any longer.

When I learned that my time was coming to an end at Oracle, I started reaching out to my friends at various companies. I am immensely lucky to have been somewhat well known (although I frequently kick myself that I suck at networking, building and growing contacts at other companies, and so on). One person I pinged was Yoshido Terada, at Microsoft, who I knew through my numerous travels to JavaOne, and his interest in my work on JavaFX. He introduced me to Tim Heuer, and that began a very whirlwind interview process where I travelled to Microsoft HQ in Seattle. I had a day of interviews with Tim Heuer, Brian Benz, Asir Selvasingh, Arthur Yasinksi, and Jeff Sandquist. From my recollection, by the time I got through airport security at the end of that day (or maybe the next morning, I can't quite recall) I had already received a phone call from the recruiter that they wanted to offer me a job.

As is the case when looking for a new job, I already had irons in the fire with other companies, including Google. My recollection is a little hazy, but I believe in the Seattle airport I decided to email and let Google know that I was going to decline an onsite interview there, because of the speed in which Microsoft had done things (and, conversely, how slowly the Google process was going), and that I didn't really look forward to flying all the way back to New Zealand only to have to turn around and come back to San Francisco to see Google. When I landed in Los Angeles on my way back home to New Zealand, I received a phone call from my Google recruiter, who said something along the lines of having never seen a candidate turn down an onsite interview at Google. It's an interesting thought though - how different would things be if Google moved a little faster, or if I gave them the chance to interview me?

With Microsoft fast-tracking their hiring, I was in the curious position of working through my redundancy from Oracle, and negotiating my exit deal, and at the same time, negotiating with Microsoft about my hiring deal! I can't quite remember how much of a break I had between jobs, but I think it was only about a week - just long enough for me to get itchy feet and eager to jump back into things. I remember that I had a lot of email exchanges with Tim and other Java folks at Microsoft, about what I should be doing first. I spent a lot of that week writing up big documents on things I wanted to change immediately (you could say I naively thought I could do anything back then)!

The first year (2018)

Coming to Microsoft felt like an entirely different world, seeing as Sun Microsystems and Oracle was my first 'real' job since I graduated. Everything felt more clearly defined compared to what I was used to (remuneration, career growth, processes - everything!). It honestly felt like a breath of fresh air.

As I mentioned, I joined the Microsoft Cloud Developer Advocacy team in December 2017, where my role was a combination of presenting at conferences, producing documentation and samples, and working with the engineering teams at Microsoft to ensure the Microsoft offerings were meeting developer expectations. I recall telling my first manager, Tim Heuer, prior to joining that my goal was to focus on working with engineering teams, and to limit my travel to the three big conferences at the time (which from memory I said were JavaOne, Devoxx, and SpringOne). My (very hazy) recollection of the first few months was that of me going in guns blazing on a variety of topics:

• Working with the Microsoft Docs team to get better Java reference doc representation (it used to be presented in a format very foreign to Java developers).
• Building scripts to generate aggregate JavaDocs of all Java SDKs being shipped out by Microsoft (particularly for Azure) to demonstrate to the various teams the differing quality of our APIs and reference documentation.
• Finding all of the teams responsible for building Java SDKs throughout Microsoft and introducing myself, learning about their challenges and customers, trying to write applications using their libraries, and filing bug reports / pull requests on anything I could.
• Building higher-level samples for Spring and other frameworks.
• Writing guidance and internal training on API design and library design.
• Working with teams on reviewing their APIs and proposing simplifications or other improvements.

After a while though, it became clear that I was expected to travel more - I had defaulted back to my standard position in life of disappearing into engineering, and not doing enough talking. To rectify that, I applied for a number of conferences, expecting to be accepted by a few of them, but my recollection is that I was accepted for every conference I submitted for. I've covered some of my presentations in 2018 on this page - from memory all I presented was 'Java API Design Best Practices'. From memory, I travelled to:

• Microsoft Build - May 7th - 9th, 2018
• JDK.IO - June 11th, 2018
• Devoxx Poland - June 21st, 2018
• JavaZone - September 12th, 2018
• QCon Shanghai - October 18, 2018 (My first keynote presentation)

On top of the travel for conferences, I travelled at least twice to Microsoft HQ in Redmond, and three times to Microsoft Shanghai. During these visits I met with engineering teams and PMs for the various libraries, as well at my own team mates. I always enjoyed these trips as it felt like I could do the part of the job I enjoyed the most.

As can be seen - I spent a significant amount of time (for me, anyway) away from home, and this was compounded by having to travel for a few days from / back to New Zealand. Whilst I personally enjoyed the opportunity to travel and see glimpses of the world, I always tried to optimise my time away to be as minimal as possible, so often I only went long enough to present a session and briefly walk around the city I was staying in.

After a while though, being away from my young family in New Zealand grew too much for me. You can see in June 2018 I visited Copenhagen for JDK.IO, then I actually flew back home to New Zealand to spend the weekend with my family, only to turn around ~72 hours later to fly all the way back to Krakow, Poland for Devoxx Poland. I also eventually started to notice that my kids weren't as upset as they were initially when I left them at the airport. On the one hand, this was perhaps a blessing for me - clearly they understand better that their Dad will be back before long - but from my perspective, it bothered me that my kids weren't upset that I was leaving. It shouldn't have to become normalised that Dad is leaving yet again!

Towards the end of the year, I published a DZone Refcard on Java API Best Practices. This summarised a bunch of my research and learnings from the time, as well as the numerous presentations I had given, and the feedback I had received. In more recent times, I've taken it upon myself to document these as Java Best Practices on my website.

Looking back, I got a lot done in my first year at Microsoft, but I was also starting to get a sense of some problems at Microsoft. Most notably, we were 'shipping the org chart' from a libraries and SDKs perspective. Each Azure service team was responsible for building their own libraries, and there was very little coordination between these teams. The result of this was that the libraries were all vastly different, in all manner of ways. From the 'small things' like different API designs, documentation styles, and test strategies, up to the vastly more significant things like dependencies, interoperability, and critically, support for a common set of 'high priority' languages. The result of this was that customers could write applications with one Microsoft library in their language of choice, and not be able to use other parts of the Azure offering, because the libraries were literally incompatible (or non-existent)!

Despite this, I spent my time working with the individual teams, offering whatever guidance I could. From memory, I spent a lot of time with the Azure Functions and Azure Storage teams, working quite closely with them on their APIs, helping to write JavaDoc, and giving feedback on whatever I could. I remember working with big names (before I realised who they were) like Jeffrey Richter and David Fowler on Storage and SignalR topics.

I recall at one point arranging a meeting when I was visiting Microsoft HQ in Redmond with as many of the different teams as I could, in a large meeting room. I wanted to try to align projects as much as possible between the teams. Being still relatively new at Microsoft I didn't fully understand the company structure, and so I found it really weird when the various teams talked about the other teams work, without them realising that they were all in the same room! I started to realise that this was a bigger problem than I could solve - the teams were disjoint and focused on their service. There was no 'center of excellence' for Java, and I started to really wish there was! I started telling my management of this issue, but from my position it was something greater than I could do myself.

I don't know exactly what precipitated it, but as I was starting to realise this and talk about it with my team, it was announced by Scott Guthrie that a brand new team was forming, called the Azure SDK team, and that it would centralise the design and construction of libraries for Azure services. Despite the coincidence, I'm certain I take no credit for this plan. However, what an announcement it was! There would be an architect for each language, as well as a team of engineers, design guidelines, best practices, a centralised engineering system, and all kinds of tools and processes! It sounded like exactly what was needed, and I excitedly emailed Scott Guthrie directly telling him that this was exactly what I had been wishing for, and that I wanted in. He put my in touch with very important people under him, such as Julia Liuson and Peter Marcu.

Fortunately for me, in the lead up to this new team being formed, I was actively working with another team on their libraries, and Peter ended up being CC'd in the discussions by someone else, so he saw what I was doing before I even knew I had to be on my best behaviour! That made things much easier for me when it came time to start talking to him about the team, and when it came time to interview for the new role, it was done by Peter and, again fortunately for me, Jeffrey Richter (from the storage libraries team). A large part of the pre-interview prep for me was to spend a few hours documenting how I would fix the Azure Key Vault library for Java, with the interview then being a discussion about all the points I raised. My memory is that I provided a five-page document summarising myriad things I would change. Fortunately for me, it worked out in my favour and I was asked to join the architect team.

With that offer in hand, in October 2018 or so, I recall having a bunch of discussions with people in the Cloud Developer Advocacy group, particularly Tim Heuer and Chad Fowler about whether I should stay in the org, or move over to Developer Division (better known as 'DevDiv'). As is usual for me, my decision making was slow and tortuous (for me), but in the end I decided that I would leave the Cloud Developer Advocacy team to help found the Azure SDK team, taking on the role of Java architect. I took a short vacation around this time, taking my family to Hawaii. I remember being so excited about the new role that I actually dialed in to my first architecture board meetings from vacation, sitting on a bed in my hotel room whilst my family were enjoying the beach and sun! In hindsight (and, to any sane person, even obvious at the time), I should have prioritised my family and vacation - but I knew this role was important to me, and I could also sense how important this role was for Microsoft. I was excited.

Second year to today (2019 - 2022)

Working as the Java architect for the Azure SDK team in the early days was extremely busy - we were bootstrapping an entirely new thing. All of the benefits of a centralised team were still to be realised, but they weren't going to magic themselves into existence. We launched into a frenzy of architectural board meetings, hiring, and coding. It was a great time at Microsoft, and I felt like I had found the perfect place for myself, out of sheer luck and being in the right place at the right time.

Architecture boards were (and continuing even today) the most important part of my week. This is a board with an architect representing the many languages we support (the four primary ones being C#, TypeScript, Python, and, of course, Java). They are two hours long, and four days a week (I think partially this is because my time zone means I would otherwise have a meeting on Saturday, and I think the other architects are kind enough to let me avoid that fate). In the early days we discussed everything related to library design - I could write many of these posts on so many interesting topics - but the ultimate outcome in the early days was our design guidelines.

Whilst these design guidelines were being written, we were also interviewing and hiring like crazy. I spent a lot of time interviewing a lot of candidates. We staffed up engineering teams for each language, and so I spent a lot of time working with 'my' burgeoning Java engineering team on building out our azure-core libraries for Java. These libraries were where we would place common functionality for things like HTTP pipelines, exception handling, logging, web service proxying, and everything else. Fortunately for Java, there existed core libraries that some of the team had already written, so we were able to bootstrap a lot of our effort by taking that as our foundation.

Another big part of my time was focused on the topics of build systems, dependencies, versioning, and figuring out how we fit into the bigger picture of the Java ecosystem. Baselining on Java 8 seemed obvious back in 2018, but working out what other dependencies we could and could not use was more difficult. I spent a lot of time doing a lot of 'market analysis', as well as reading of the tea leaves.

One of the nice perks of the Azure SDK team, especially in the early days pre-covid, was the ability to bring developers from outside of Microsoft into our usability testing labs. This was a foreign concept for me up until that point - isn't a usability test seeing how well a graphical user interface works? How does that relate to libraries? It turns out that Microsoft were strong believers in having real developers test our libraries - is the API obvious? Can the user perform some tasks with or without JavaDoc? How does the user find help when they are stuck? Can a user understand async APIs? I loved this - it made it so much easier to design APIs knowing that I could watch real developers play with prototype APIs, and it helped to inform so many design decisions in the early days. Our UX lab was pretty much constantly full, running tests for all languages. In hindsight, it feels weird that I never saw this done when I was working on the JDK at Sun Microsystems and Oracle, and how much more difficult the work was because of it.

Over the course of the next four years, the team grew massively. Interestingly, we still have the same core group of architects, but we have now scaled up to have deputy architects for each language as well. Every six months or so we pick up another group of services we build libraries for (or, that we work with the service team on to build themselves). The amount of work that goes into the development and ongoing support of these libraries is immense.

Over the same period, we've also invested heavily in constantly improving our azure-core libraries. Performance has dramatically increased, memory consumption has massively dropped, self-service supportability has improved with features like structured logging, drastically improved JavaDoc (with code samples), and error messages that link out to long-form help articles. It has been a great pleasure in my career to always have time and scope to focus on the fundamentals like this, as it is the time where so many customer-delighting improvements get to be made.

As with all big library projects, it's a certainty that there will be regrets, and there are some here too. For the most part, so many of the design bets that I made back in 2018 have paid off nicely, but one or two hang around my neck still. For the most part these are all to do with dependencies that I wish I could have avoided, but due to limited time (or, just the way the Java ecosystem is), they are still depended on today. Fortunately, I think in the next year I should be able to get close to getting rid of these regrets.

Looking ahead

I'm having a great time at Microsoft working on open source Java. I still feel weird saying that, as I never expected to work for Microsoft given my career trajectory was firmly on the Java / Open Source path, but a 10 year old me would have been elated to know that future-me was a Microsoft employee, given how much of a Microsoft and Bill Gates fan boy I was back then.

I still feel like there is so much more potential for Java at Microsoft. I try every year to unlock it in the areas that I can, but I can also see that there is so much more Java at Microsoft now than there has ever been. I might be wrong, but I'd imagine Microsoft might be the top employer of Java Champions right now. Every January I send out my plan for the year ahead, and every year I feel excited and invigorated to make things better for my users, my team, and the Java community as a whole.

Today is my five year anniversary at Microsoft, and I'm grateful, excited, and energised about what comes next.