The lie of homogeneous corporate environments

Published 2025-07-01

tag(s): #yell-at-cloud #linux #programming #overblown-minor-annoyances

Welcome to another edition of "Hoagie's venting posts", where I get fed up with something, then remember I have a place where I can rant about it.[1]

I am (was?) setting up a codebase in my work laptop, a Django-based website with some scripting around it and dependencies on other repositories and infrastructure. And it didn't go well.
The first problem is, our servers are Linux-based, and our laptops are Windows. Why? Because everyone's laptops are Windows I guess, which is another way of saying there is no good reason.
The theory goes that everyone having the same environment makes administration by IT and security easier. In this post, I will argue that this simplicity is just a hurtful lie, and reality has many more corner cases than people want to admit.

Security

Caring about this is a good thing, don't get me wrong. The problem I have with it, is that it is usually implemented assuming no one will ever need access to anything.
Developers always need permissions to more services. I am not advocating for a "free for all", but make it so that extra access is easily obtained, and regularly audited. As opposed to needing 7089304890 layers of approval, and relying on teams that are 12 hours away from you.

If you are scared that developers might fuck up your network or servers, then:

  1. Get better developers.
  2. Have a good recovery procedure.
And #2 is really the most important one, because even if you have the best of the best people...mistakes happen. Have good back ups and the ability to rebuild stuff as needed.

The other thing that happens with overzealous security is that because people know permissions are hard to obtain, they ask for more access right away, lumping more things in the same request.

Or even, they don't say anything about existing holes!
For example, this totally made up scenario: access to domain lookup of users is blocked in laptops, and you are offered a VM as an alternative (more on this later).
Then you find out that when you work from home, you can reach the domain controllers using the corporate VPN!!! It probably is less secure that it works outside the physical office...but, do you bring up the inconsistency, and risk having that access closed? Or stay silent, and when in office, use "guest wifi + VPN" and move on? The latter certainly makes your life easier 👀

Windows (and WSL) or Mac

This is a "solution" that is just a shifting of burden.
All laptops are Windows! Or all laptops are Macs! Then there's a central administration for IT stuff, and the same rules for everyone. Problem solved!, they say.

Just as with the security rules, people will need exceptions that ruin the illusion of sameness: install drivers for specialized hardware, permissions for a debugger, specific compilation tools.
Use x86 based tools in your M1 laptop, which means workarounds or alternatives for half the things in your stack.

Or your servers are Linux based, and all developers need to account for that when writing and testing code in Windows. You can cover maybe 85% of the most common scenarios with WSL, or VMs, but that leaves you open to the more annoying and difficult to bypass corner cases.
And many times, that same extra layer introduces new testing complexities. "Does this not work because of external permissions, or something in the WSL-Windows layer?".[2]

Possible solutions?

I was OKed in a previous job to use dual boot and run Linux. It was understood I was on my own, and I kept the Windows partition around just in case. I could run the same containers we deployed natively, much simpler than the VM-based "Docker on Windows" experience.
In another case, I was offered BYOD and using that previous experience, I knew I could run all corporate MS services via browser[3] and access the VPN with the Linux CLI client, so I didn't even boot their laptop, ever. Worked 100% from my own laptop with no hiccups.

Of course that approach doesn't work for non-power users. You still should offer a "default experience" that works for a good chunk of your organization.
But maybe have a second "power user" setup? Yes, make those people responsible for their environment and how they use the powers they are granted. But it streamlines the process!!!

If you are gonna make it more work for me to get things setup, I'd rather spend that time figuring out how to configure things on my own, than creating tickets and chasing approvals in Outlook. 90% of the time, the approvers don't even know what they are OKing...

The current workaround

I am ssh-ing to a Linux dev server to setup the same website.
But I really tried my best to make the darned thing work in Windows, even if meant more effort to get it running. Out of principle! You gave me a Windows laptop, and you bet I will get this working on it.
It helped that I know Windows really well from my many years as a C# developer[4]...except it didn't really help. Now I feel like a stupid quitter 🙃

Footnotes
  1. I care less than the post implies, but I find that venting about minor things clears the mind for when it is time to tackle Real Problems™️.
  2. Most likely, it is your own code =P
  3. Although in this day and age, not offering plain IMAP for Office 365 is just laziness. If a sysadmin ever reads this, and provides a counterpoint, I will update the text.
    "Microsoft recommends it" is not a real reason (just like it isn't a real reason to turn off third party authenticators for TOTP... 🤦)
  4. shudders in IIS 6.0.

Share your thoughts (via email)

Back to top

Back to homepage