For a long time, I followed the usual setup for my development environment:
Install a VM → set up a Linux distro → allocate resources → wait for it to boot → start working.
It worked.
But it always felt like I was adding friction before even writing my first line of code.
Over the past few years of building personal projects, I’ve started paying more attention to how I work not just what I build.
That’s when I explored WSL (Windows Subsystem for Linux).
And honestly, I moved away from virtual machines.
Not because they’re wrong but because they didn’t fit the kind of workflow I was trying to build.
With WSL, everything feels more integrated:
• Linux commands running alongside Windows tools
• Same files accessible across both environments without duplication
• Seamless VS Code integration that actually feels native
• Near-instant startup, no waiting for environments to boot
• Much lower resource usage compared to running a full OS
But the biggest shift wasn’t technical.
I stopped switching between environments… and started working in one continuous flow.
For someone building backend projects, experimenting with cloud tools, and refining workflows, this small change made a real difference.
One thing I’m learning along the way:
Better development isn’t just about better tools.
It’s about removing unnecessary complexity.
Still building. Still refining. Still learning.
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (1)
Your point about reducing context-switching friction is solid. The boot-allocate-wait loop of a traditional VM setup does eat into the kind of flow state you want for backend work. The irony is that WSL2 is a virtual machine. It runs a full Linux kernel inside a lightweight Hyper-V VM that Microsoft manages on your behalf. The friction you eliminated wasn't the VM itself, it was the manual setup and visible boundary between environments. That distinction matters because it changes the takeaway: the win here is not "VMs are unnecessary overhead" but "a well-integrated VM can become invisible." And that invisibility has limits. Cross-filesystem access between /mnt/c and the Linux root has well-documented I/O performance penalties, which means "same files accessible across both environments" works fine for editing configs but falls apart under heavy disk workloads like large builds or database operations. The recommended practice is to keep project files in the Linux filesystem, which quietly reintroduces the separation the article says WSL eliminates.
Have you run into the I/O boundary in practice, or does your workflow stay mostly on the Linux side?