Don’t Have Time to Debug My OS Anymore — My Personal Move Back to Windows as Android Engineer

If you’re a Senior Engineer, there’s an unspoken rule: you’re supposed to use a Mac for the “it just works” experience, or a Linux distro because you’re a “real” power user. For years, I followed that rule. I looked the part — I had the terminal shortcuts and the elite environment.

But I was lying to myself.

I’m a Senior Android Engineer. I juggle multiple freelance projects, and my “free time” is a precious, disappearing resource. I’m also a gamer who wants to stream my PC’s raw horsepower to my phone while I’m on the move. I realized I had fallen into the Power User’s Trap:

I was spending more time being a “Digital Janitor” than an actual developer.

The Maintenance Tax — From a Former Linux Freak

I’m not some casual user who got scared of the command line. I used to be a total “Linux Freak.” I’ve spent years digging into the kernel and tweaking deep system calls. I was the guy who would unironically tell you:

“I use Arch, btw.”

Recently, I was running CachyOS with an extreme kernel. It was fast and optimized — on paper, it was perfect. But here is the secret no one tells you about being an elite Linux power user:

The more you optimize, the more you break.

The “Update Roulette” Gamble

When you’re a freelancer juggling three projects, “Update Roulette” is a game you can’t afford to play. I’d finish a 10-hour coding sprint, hit pacman -Syu, and—boom—my low-latency remote desktop config for Sunshine and Apollo was toast.

I’ve spent too many 1:00 AMs debugging kernel-level driver conflicts just to get back to a working environment. I realized I was spending my expertise being a digital mechanic instead of an engineer.

Linux is a masterpiece if your time is free. But when time is your most limited resource, you eventually get tired of fixing your tools_._

The Mac Trap — The 256GB Wall

When I tried to escape to Mac, I hit a different wall. I’m a pragmatic guy, so I use a Mac Mini — but Apple’s storage prices are a joke. Staying on a 256GB base model means living in a constant state of “Storage Anxiety.”

MacOS is a hoarder. It hides system caches and “Other” files in corners you can’t easily reach.

The breaking point? Google Chrome refused to share my screen during a high-stakes client meeting because the disk was so full it couldn’t cache the video stream.

Pragmatism Over Elitism

Cleaning that mess isn’t “engineering” — it’s digital janitorial work.

In Windows, I found I finally had control. I can see every file, I can kill every useless process, and I can manage my storage without a PhD. I stopped chasing the “cool” OS and started chasing the one that stays out of my way.

OS Solution — AtlasOS

If you think Windows is for “office work,” you’re looking at the wrong version. Out of the box, it’s a mess of telemetry and background services. As a power user, I needed the hardware compatibility of Windows but the “lean and mean” feel of my old CachyOS setup.

Instead of fighting standard Windows, I moved to AtlasOS. This community-driven project strips Windows down to its bare essentials. Your CPU focuses 100% on the build or the game, not on reporting your usage habits to a server in Redmond. It kills the “silent killers” — Windows Defender “ghost scans” that slow down your IDE.

I’m not just going by “feel.” The AtlasOS team’s own benchmarks (v0.3.1) show why this matters for high-performance tasks.

The “Priority” Trap — Why I’m Careful with Process Lasso

Process Lasso is a powerful tool designed to squeeze every drop of performance from your hardware. For an Android Engineer, the temptation is real — force Gradle or Java into high-priority CPU cores and watch the build times drop. I’ve done it, and I learned a hard lesson.

Back when I was a “Linux Freak,” I was obsessed with aggressive scheduling. I wanted speed at any cost, but the reality was disappointing. The UI became jittery — the system felt brittle.

I found the same thing happens with Process Lasso on Windows. You can shove more power into your build, but the moment you do, the fluidity of the OS suffers.

You want a system that is fast because it is efficient — not because it is being forced.

The Efficient System

Get Joseph Sanjaya’s stories in your inbox

Join Medium for free to get updates from this writer.

Subscribe

Subscribe

Remember me for faster sign in

If you want to push for a world-record build speed, use Process Lasso. However, if you want a machine that feels smooth and responsive while you work, focus on making the OS naturally light first.

The “Final Boss” — The NTFS Bottleneck

Even with a clean OS and optimized scheduling, I noticed my build times were lagging. I realized the problem wasn’t the CPU or the RAM — it was the File System.

NTFS was never designed to handle a modern Android project. These projects are essentially graveyards of millions of tiny cache files. Every time Gradle performs a “Check,” NTFS executes a heavy metadata handshake for every single file. This bottleneck is exactly what drives most developers back to Mac or Linux.

But Windows finally has an answer. It is called the Dev Drive, and it is the closest thing to “magic” I’ve found in years.

If you’ve ever wondered why the same Android project builds faster on a Mac than on a high-end Windows rig, the answer isn’t the CPU — it’s the file system.

The Science — Why NTFS Chokes on Gradle

NTFS was designed in the 90s for stability and general-purpose use — not the high-velocity demands of modern development. It relies on a “Heavy Metadata” approach. Every time Gradle creates or checks one of the millions of tiny files in your build folder, NTFS must perform a series of synchronous writes to the Master File Table (MFT) and security logs.

When you have 50,000 files in a single build, that “handshake” overhead becomes a massive bottleneck. You are essentially asking a giant freight train — NTFS — to deliver 50,000 tiny envelopes. It is a massive waste of energy.

File System Solution — ReFS (Resilient File System)

Microsoft finally gave us the Dev Drive, which uses ReFS. Think of ReFS as a modernized, “lean” file system built for high-performance developer workloads.

• Copy-on-Write (CoW) — ReFS does not overwrite data in place; it writes to new blocks. This dramatically speeds up file allocation.
• Metadata Optimization — ReFS handles metadata much more efficiently than NTFS. It was built to “breathe” through the millions of small-file operations that modern compilers — and Gradle — throw at it.

The Result — In my real-world tests, moving an Android project and the SDK to a Dev Drive cut build times by 15% to 20%.

The Workflow — The VHDX “Portable Office”

This part changed my life as a freelancer. I do not merely create a Dev Drive on my local disk; I create it as a VHDX file — a Virtual Hard Disk.

By putting my entire environment — Android Studio SDKs, project folders, and Gradle cache — into one 100GB VHDX file, I’ve created a Portable Office.

How to Create Your First Dev Drive

• Open Settings — Navigate to System > For Developers > Dev Drive.

• Create VHDX — Choose “Create new VHDX”. This creates a single file on your drive that acts as a high-performance disk.

• Format with ReFS — The system will automatically suggest ReFS.
• Move Your Work — Relocate your src and your .gradle cache folders here.

How to Reuse it on Another Machine

This is the magic part. Because the Dev Drive is a simple .vhdx file, the transition is seamless:

• Copy & Mount — You can copy that single file to a local server or a thumb drive.
• Instant Access — When moving to another PC, double-click the VHDX. Windows mounts it as a Dev Drive instantly.
• No Re-Cloning — All SDKs, dependencies, and project states remain exactly where you left them.

The Conclusion — Pragmatism Wins Every Time

This is not an attack on the Mac or Linux communities. I’ve lived in those worlds, flexed my Arch config, and paid the “Apple Tax”. They are great systems if they fit your specific life.

But for me — a Senior Android Engineer juggling multiple freelance projects while trying to protect hobby time — efficiency is the only metric that matters.

I stopped being an OS Janitor. I realized every hour spent fixing a broken kernel update or clearing out “Hidden System Data” on a Mac was an hour stolen from my life. I moved back to Windows not because it is perfect, but because once you strip away the bloat and fix the file system bottleneck, it becomes a high-performance engine that stays out of your way.