As you can see from my career timeline, I’ve been around the block a few times in my ~30-year career in software engineering.

But the last 5 years, since returning to Microsoft in 2016, have been among the most challenging, exciting, fun, and rewarding of my entire career!

Bear with me while I summarize the last 5 years to give you a picture of where I’ve been … and to set the stage for what comes next! 🤓

Opportunity Born From Frustration

As mentioned in my “Welcome” post, in late 2015 I was building the infrastructure for a new startup’s site and services, but I ran into several problems getting things working on Windows. Frustrated by my experience, I tweeted:

A follower DM’ed me the email address of the then owner of the Windows command-line. I sent him a lengthy email listing the numerous issues I had bumped into when using Windows console and command-line apps and tools. To my surprise, he invited me to lunch! He shared that there was indeed a new team who now owned the Windows command-line, that they had some exciting plans, and were looking for a PM to join the team. Was I was interested?

Initially, was torn: While I was super-excited about what I had heard that lunch, I had left Microsoft in 2010, after 10 years at the company, in large part because Microsoft was not at that time the company I believed in as I once had. At that time, many were questioning Microsoft’s position and relevance in the future of the software industry. However, much had changed since then!

In February 2014, in a rather surprising move, Steve Ballmer had stepped aside as CEO of Microsoft and Satya Nadella had taken-over. Satya rapidly transformed Microsoft and its culture to one of empathy, openness, and far greater transparency. “Out” was the aggressive compete-at-all-costs ethos of Microsoft of old, and “in” was a Microsoft that now competed respectfully with others in the industry, and collaborated with many companies that were previously seen as “enemies”.

By early 2016, Microsoft was a very different company: While it still had (and continues to have) A LOT of things to improve, it was energized, exciting, forward-looking, collaborative, and was going from strength to strength.

Satya had freed and unleashed Microsoft’s true soul, and it showed!

Back to Microsoft (v3.0)

So, just a couple of weeks after discussing the future of Windows’ command-line over lunch, I found myself going through an interview loop, which I passed. After negotiating the finer details, I accepted an offer to join Microsoft as a PM for (the then unannounced) Windows Subsystem for Linux (WSL) and the Windows command-line & Console.

Once again, I had a blue-badge!

Rich returns to Microsoft

WSL, Console, and the Command-Line

Upon my return, I was enormously fortunate to have the opportunity to drive and launch what I consider to be one of the most impressive and impactful technologies that Microsoft has ever shipped: Windows Subsystem for Linux (WSL).

WSL enables Windows users to install and run genuine native Linux command-line tools, without any modifications, alongside their existing Windows apps and tools. WSL is a HUGE boon to developers who want/need to run the many exciting tools, compilers, interpreters, runtimes, etc. that are either only available on Linux or primarily optimized for Linux.

To paraphrase Scott Hanselman, developers on Windows no longer had to feel ostracized, unable to run cool Linux command-line utilities or tools: Using WSL, developers can run all their favorite Linux and Windows tools side-by-side!

As a huge fan of Linux and open-source software, being able to help announce, deliver, and drive WSL made me very happy!

Rich loves Linux and OSS

Interest in WSL positively exploded - our 12 minute pre-recorded WSL announcement video was viewed 50% more than both Build 2016 keynotes combined, and WSL’s launch was covered via many media outlets including The Verge, Ars Technica, and Linux.com. Interest in and adoption of WSL has continued to grow rapidly ever since.

Since that first announcement, we partnered with Canonical, Suse, and other distro owners to help them publish their distros to the Microsoft Store, and drove a series of huge improvements in functionality, compatibility, and performance, especially with the introduction of WSL2.

Improving the Console

At the same time, I worked closely with the then fledgling Console team, helping plan, design, and deliver a series of important enhancements to Windows Console; improving its ability to render text correctly on increasingly popular high-DPI screens; supporting accessibility tools like Windows Narrator, NVDA, and JAWS screen readers; and massively improving Console’s ability to render VT sequences including 24-bit color support - which is particularly important when running Linux apps in WSL! We also set to work improving the core command-line infrastructure of Windows itself, finally introducing a Console PTY which makes it possible/easier to create many types of command-line tools that previously were difficult to build.

A new Terminal

But we had bigger goals - we wanted to create a new and modern command-line UX … a new Terminal app.

As I documented in this post, Windows Console and the closely related Cmd shell have one primary responsibility: To maintain backward compatibility at all cost.

Console and Cmd were originally introduced in Windows NT 3.5.1 to run existing MS-DOS batch scripts and commands with little/no modification. This helped users and enterprises to migrate from MS-DOS and Windows 3.x/9x to the then brand-new Windows NT. And there they have remained ever since - through Windows NT, 2000, XP, Vista, 7, 8, and now Windows 10 - all can and do still run batch scripts and commands that may have originated-as/evolved-from MS-DOS batch scripts from more than 30 years ago! Alas, so vast and diverse are the scope and complexity of Windows command-line scripts and tools, it’s practically impossible to change anything in Console/Cmd, even small things, without breaking someone, somewhere!

Alas, because Console was so fragile, it had fallen behind Terminals on other platforms, and lacked many of the features and capabilities that other Terminals provided and that command-line users craved, such as multiple tabs/panes, colors, themes, support for rich text-UI features, etc.

To deliver a modern command-line UX, we knew we had to deliver a new Terminal.

But should we build a new terminal, or leverage an existing one? While there are several great 3rd party command-line apps available for Windows, each has their key use-cases, performance characteristics, memory/CPU requirements, security considerations, etc. What customers asked us for time, and time again … and what I originally asked the owner of the Windows command-line for, was for a modern command-line experience: A modern Terminal - one engineered to Microsoft’s exacting requirements, but with the features demanded by our passionate and enthusiastic users.

So we drove hard toward those goal. From 2016-2018, while overhauling & improving the Console’s internals, we gestated plans for what the new Terminal could be … and would be. We built and argued case after case, explaining to management why they should dedicate resources to building a new command-line Terminal, and how doing so would deliver sufficient value to our users to warrant doing the work at all.

And then, in very early 2019, a breakthrough: We got the green-light, so we got to work building a new Windows Terminal.

By May 2019, we had a working prototype, which was unveiled in our rather snazzy “sizzle video” at Build 2019 …

… and unveiled and detailed in our presentation:

Like WSL before it, the new Terminal garnered HUGE interest and support from the community, customers, and media. Usage skyrocketed, issues flooded into the Terminal GitHub repo, followed closely by PRs (Pull Requests) containing fixes, improvements, and even entire features.

Windows Terminal v1.0 was launched in summer 2020, and is available for download for free from the Microsoft Store:

👉 Note: If you’re interested in news and updates on WSL, Terminal, and all things command-line, be sure to visit the Windows Command-Line blog to which the team regularly post news and announcements to!

Make yourself redundant!

In a healthy organization, one of the most valuable things one can do is to replace one’e self! This is more true the higher up the ranks of one’s company that one climbs.

As a Senior PM, I had leveraged my extensive experience to do the work that my skills were best applied to: Laying the foundations and getting projects up off the ground and running smoothly. Specifically: Launching and driving the first few releases of WSL, and getting the Terminal project kicked-off and announced.

With the WSL and Terminal projects on solid footing, they were now well-placed opportunities for Early in Career (EiC) PM’s to take-over and drive into the future.

And here we lucked-out:

In fall 2018, Craig Loewen, who had interned with us the previous summer, returned to the team after completing his degree in Metatronics Engineering. Craig hit the ground running and I started transitioning more and more of the PM ownership of WSL to him. As his knowledge and confidence grew, Craig started to establish himself as the go-to person on Twitter for any and all questions around WSL.

A few months later, in early 2019, Kayla Cinnamon joined the team after completing her Masters degree in IT specializing Human-Computer Interaction. Kayla’s skills were immediately employed in helping finalize the design of the Terminal’s UX and features, and helping make the Terminal’s sizzle video … well … sizzle 😁. Like Craig, Kayla’s mastery of the Terminal quickly grew, and she established herself as a prominent authority on Windows Terminal, on Twitter, in talks, podcast interviews, and beyond.

Kayla also took over the reins of the project to create a new open-source monospace font we’d been working on for a while. She worked with font-designer extraordinaire Aaron Bell, delivering Cascaida Code, and is continuing to drive improvements and innovations for Cascadia Code in the future! 😜

Cascadia Code font

Both Kayla and Craig have now been driving Terminal and WSL for well over a year and, alongside our engineering colleagues, are doing stellar work delivering new and exciting features, while continuing to drive up the quality and performance of both products.

WinDev Performance

So what does one do after essentially making one’s self redundant … well, thankfully, there’s plenty of work to do here in the Windows Developer Experience & Platform team! 😜

After transitioning WSL and Terminal onto Craig and Kayla respectively, I had the capacity to expand my scope from “just” the command-line to seek out more issues and problems that impact developers using Windows. This was, to me, just a natural expansion of what began as a flame-mail complaining about the issues I uncovered when trying to build my startup some 5 years prior!

We call this project WinDev - a combination of “Windows”, “Win” / “Win at”, “Dev”, “on Windows” … it all just flowed into “WinDev”.

During most of 2019, I helped drive an initiative to find and fix performance issues in Windows that impede developers when building apps, tools, and services on/for Windows.

Once again, we lucked-out: In August 2019, Avri Parker joined our team as a PM, after graduating with a degree in Computer Science and Business Administration. Wasting no time, she quickly engaged in helping plan and build-out our developer-focussed performance analysis workstream.

We started by choosing a candidate scenarios containing steps that we could run on Windows, Mac, and Linux. We then ran those scenarios, measuring the time it took to complete each step of each scenario, on each platform. We built infrastructure to automate much of the running & measurement of these scenarios, and acquired several devices to allow us to compare the performance of each scenario across all three platforms.

We learned a ton in the process, and ended up with a pretty reasonable process by which we can measure the performance of some quite complex scenarios across multiple platforms and devices, capturing performance traces that can be analyzed in detail.

To deliver meaningful results on this project, we had to partner with colleagues within our team, and across several other teams and divisions at Microsoft including BASE, Defender, NTFS, Indexer, OneDrive, and others. We also reached out to and worked with external companies, projects and partners, too including Android, QEMU, and others.

I don’t want to go into too much detail on this project in this post, as we’re planning on sharing more about this project in a more detailed blog in the future. Do let Avri know if you have specific things you’d like to know/ask/suggest about the WinDev Perf effort

I also drove the creation and triaging of the “new” WinDev GitHub Issues repo, in which we invite developers to file issues that impact them when building, testing, debugging, profiling, etc. code on Windows. This repo initially focussed on performance-specific issues, mostly as a way of ensuring that we didn’t get swamped with mountains of issues that we didn’t have the capacity to triage, and to help ensure that there were not any unexpected performance related scenarios that we weren’t aware of. But we’re planning to increase the scope of the issues we invite developers to submit. Though I’ll leave it to Avri to share those plans in the future 😜

So, now that the WinDev Perf project is stabilizing, essential relationships have been established, tools built, processes defined and refined, and having transitioned most of the WinDev project into Avri’s highly capable hands, I made myself redundant once more!

Something new!

In late 2020, I was starting to wonder “what’s next?” when, from out of nowhere, a new opportunity appeared!

On Jan 25th 2021, I start a new exciting role! I already hear you ask …

  1. Are you leaving Microsoft? (No!)
  2. Where?
  3. Doing what?
  4. Tell us, tell us now!!!!

Soon, friends. Soon. Stay tuned and follow me on Twitter for news! 😜

THANK YOU ALL!

I am enormously proud of and grateful to all the teams who’ve worked on and helped support the WSL, Terminal, and WinDev Perf projects: I could not have asked for better, more passionate, engaged, and fun colleagues to work with and to transfer ownership of these projects to. Rest assured, all of these projects in great hands and have some truly amazing new features and results arriving in the near future 😁

And to all of you in the community who’ve provided such great feedback and support on Twitter, GitHub, StackOverflow, HackerNews, Reddit and elsewhere, THANK YOU! Without your feedback, we literally couldn’t have made WSL and Terminal as awesome as they are. Keep sharing your feedback with Craig (WSL)), Kayla (Terminal), and Avri (WinDev Perf) so they can continue to work with our amazing engineering teams and communities to improve WSL, Terminal, and WinDev Perf.

On behalf of the entire team - THANK YOU to all our users, commenters, contributors, and supporters - both WSL and Terminal have benefitted enormously from all your contributions. The Windows Terminal & WSL core-team at Build 2019