Adapting to Windows as a Linux Developer

Last year I switched jobs: I was working as a Site Reliability Engineer at Google and decided to pursue a new opportunity as a Software Engineer in Microsoft, where I work on the internal CI/CD tools that we use to build, test and deploy Azure products.

One of the reasons I accepted the job at Microsoft is because I realized that I was getting too used to the way things are done in Google. While I think the Google infrastructure and developer workflow tools are pretty good, I wanted to gain a new perspective and make sure that I wasn’t becoming too comfortable with how things were done in Google.

In this spirit, when I joined Microsoft I resisted all the urges I had to try and use Linux as my main development platform, which I could have done (to a certain extent), but rather I tried to (re-) learn how to use Windows as a developer.

I have been using Linux almost exclusively for my entire professional career (14 years and counting, including part-time jobs I had while studying), but my first steps in computing — after playing a bit with ZX Spectrum / C64 when I was single-digit old — were indeed with MS-DOS and Windows. I remember creating elaborate runner menus with batch and ANSI codes, the thrill of running this new thing called Windows from the command-line (win.exe), the 2–3 floppy disks required to install DOS 6.22.

Anyway, this post contains a list of things I found useful when switching from Linux to Windows, without too many details to avoid being too long, and setting ideological issues aside (I am a supporter of free software and have been for, again, 14 years and counting). I hereby reserve the right to discuss those topics, and maybe spend a bit more words on the technical setup itself, in another post or multiple other posts.

Note: many of these suggestions/discussion points will likely sound obvious to people who have been using Windows professionally for years. That’s working as intended: the audience I have in mind for this post are people — like me — who have used some flavor of Linux for years and, for some reason, want to consider Windows as a development platform and daily OS.

Note2: needless to say, every word written here represents my own opinion and not the opinion of my past, present or future employers. :)

Window management

The first issue I faced was the following: how do I effectively lay out windows on my monitor(s)? That might seem a mundane problem, but for me it’s pretty core to how I work.

I am a fan of tiling window managers, in particular i3wm , so having to use a mouse to arrange windows was a no-go.

I tried finding a proper tiling window manager, and tried a few (bug.n, Dell Windows Manager) but in the end I decided to stick with the vanilla keyboard shortcuts that Windows 10 has to offer:

• Virtual desktop support (Ctrl-Win-Left, Right)
• Docking windows to edges of the screen (Win-Left, Right, Up, Down)

This is sufficient for me to create the few setups I usually have: full-screen windows, 50/50 split screen windows, a mix of the two on multiple monitors, the occasional 4-split.

Command-line Experience

I spend a lot of time on the command-line, and switching jobs didn’t change that.

PowerShell

I invested some time in learning PowerShell , towards which I have mixed feelings. I find it more verbose than bash but also a bit more structured. One-liners still don’t come natural to me, and I find the weak typing a bit annoying when writing larger scripts

On the other hand, its pipeline model (passing .NET objects) is very powerful and I am starting to like this more than just piping streams of text. PowerShell is a fully-fledged .NET language so I have access to a very powerful set of libraries and there is also excellent support in Visual Studio Code, which is my IDE of choice (more on that later).

Overall, it’s worth being familiar with PowerShell if you’ll spend time on Windows and want to know how it’s supposed to be automated. With the release of .NET Core, it is also open source and cross-platform, so in theory you could also run it in Linux environments.

Terminal Emulators

I dislike the default Windows terminal emulators (cmd.exe and powershell.exe), so I looked for alternatives here. I settled on cmder , which is a fork of ConEmu with reasonable defaults. I like the integration with posh-git and the consistency of having one terminal emulator for multiple shells.

Windows Subsystem for Linux (WSL)

One of the first things I enabled on every Windows machine I was given is the WIndows Subsystem for Linux (WSL) . In short, it’s a way to natively run some Linux programs on Windows. It is part of the Windows operating system since version 10, and its integration is much deeper than what tools like cygwin or msys could do in the past.

This gave me a way to finally use the commands I am familiar with, from a Windows machine!

But if you think about it, it’s a double-edged sword, especially considering my original goal of learning a different perspective. I could just run my usual tools to get the job done, but I was missing out on learning how to do the same things in — say — PowerShell.

While it was a useful “crutch” to help me get through the first months, now I tend to use it less and less, only when there is true reason to do it, otherwise I try to stick to PowerShell.

Package Management

This was a pleasant surprise: when I stopped using Windows, there was no way to install packages in a managed way, from a curated feed.

Nowadays, I install as much software as possible from Chocolatey , and I don’t have to think about where to find software or which environment variables I need to change in order for the thing to work (looking at you, JDK).

Writing and Editing Code

I am a vim user. Many vim shortcuts are second nature to me and I would find it very hard to not be able to navigate text and code using them.

However, I do recognize that IDEs are extremely helpful, and I’ve come to appreciate them more and more in the last few years.

For me, the way this all comes together is by using Visual Studio Code . It’s a pretty good open source IDE with a great vim emulation layer called VsVim . It is not the same thing as having all the features of Vim at your fingertips, and there are some minor quirks (for example I find that using the status bar to display commands in normal mode is hard to read), but I find it more than sufficient for most of my needs.

Giving up the most advanced vim features, the ones not supported by emulation layers, a very good trade-off to be able to access all the amazing features of Visual Studio Code.

I am seriously impressed by how good it’s becoming and how much time it’s saving me. This probably would deserve a separate post, but here is a short list of things I really liked about it so far, in no particular order:

• language support for all the languages I need: PowerShell, C#, Java (even if I still prefer IntelliJ IDEA for Java);
• the debugger support for PowerShell was a pleasant surprise;
• CSV support is pretty great too, CSV fields are separated visually with colors and the CSV dataset can be queried with a subset of SQL;
• git support is good but not fully comprehensive, but it doesn’t get in the way of doing more complex operations (like rebases): in fact, it helps during rebase thanks to the excellent diff support;
• the UI is opinionated: the command palette drives most operations, and the statusbar is pretty rich and interactive.

In general I find it pretty usable, extensible and modular. I should not have been surprised when I learned that Erich Gamma (one of the Gang of Four) was one of the architects behind it.

Knowledge of Windows Internals

When working in Google I typically was dealing with infrastructure that abstracted away most of the kinks of the underlying operating system. This is not true in all Google teams, but it was true in my work experience. Similarly in Microsoft I think there are teams that don’t deal a lot with Windows internals, especially if working above Azure, but since I am working a bit closer to bare metal I found out that I had to learn a bit more about the operating system to be effective.

The wake up call came when I was trying to set up the OpenSSH server on my own Windows 10 machine (a relatively new Windows 10 feature), and I realized that sshd was refusing to start due to permissions on the host key being too open, and that I had no idea how to fix perimssions or even what is actually the file permissions model on Windows.

To fix this, I am slowly going through the Windows Internals, 7th ed. book. I don’t plan to read all of it, but I’ll read at least the introductory chapters, which give a high-level overview of key concepts, design choices and architecture of the OS, and then deep — dive into topics as needed.

For example, I needed to learn more about how Code Signing is working for a project I am currently leading. For that I used this book and also spent some time with the online documentation (see section about Cryptography ). I am honestly surprised as how good Microsoft documentation is nowadays. There are entire sections of docs.microsoft.com which are essentially high-quality technical books on specific subjects. The section I liked the most so far is the Azure Architecture Center , a very large source of information on Cloud Architecture and Design Patterns, both cloud-agnostic and Azure-specific.

Going back to Windows Internals, having studied Linux internals in college it’s interesting to draw parallels and understand why some specific choices were made, and to be honest when I opened that (e-) book I felt a sensation that brought me back to the University years: being completely ignorant about one topic and having in my hands a large book that was ready to teach me things I don’t know yet — very exciting. :)

And, a small plug here: I think that having a free O’Reilly Safari Books Online subscription is a great perk to have. ;)

Conclusions

I think that’s mostly it!

Each of those topics deserves more in-depth discussion, and there are several other considerations about how my way of working changed that could benefit from more discussion as well, but for now I hope this can give an overview into how, as a Linux user, I am adapting to become an effective developer on a different environment.