Technology

you end up compiling 5 minutes quicker

This implies the entire build still takes a few minutes on that beefier machine, which is in the "check back later" category of tasks. Rebuilds need to be seconds, and going from 10s to 5s (or even 30s) isn't worth a separate machine.

If my builds took that long, I'd seriously reconsider how the project is structured to dramatically reduce that. A fresh build taking forever is fine, you can do that at the end of the day or whatever, but edit/reload should be very fast.

it's so that you're never a single point of failure

That belongs at the system architecture level IMO. A dev machine shouldn't be that interesting to an attacker since a dev only needs:

• code and internal docs
• test environments
• "personal" stuff (paystubs, contracts, etc)
• VPN config for remote access to test envs

My access to all of the source material is behind a login, so IT can easily disable my access and entirely cut an attacker out (and we require refreshing fairly frequently). The biggest loss is IP theft, which only requires read permissions to my home directory, and most competitors won't touch that type of IP anyway (and my internal docs are dev level, not strategic). Most of my cached info is stale since I tend to only work in a particular area at a given time (i.e. if I'm working on reports, I don't need the latest simulation code). I also don't have any access to production, and I've even told our devOPs team about things that I was able to access but shouldn't. I don't need or even want prod access.

The main defense here is frequent updates, and I'm 100% fine with having an automated system package monitor, and if IT really wants it, I can configure sudo to send an email every time I use it. I tend to run updates weekly, though sometimes I'll wait 2 weeks if I'm really involved in a project.

if something goes wrong you can point at policy and say “I followed the rules”

And this, right here, is my problem with a lot of C-suite level IT policy, it's often more about CYA and less about actual security. If there was another 9/11, the airlines would point to TSA and say, "not my problem," when the attack very likely came through their supply chain. "I was just following orders" isn't a great defense when the actor should have known better. Or on the IT side specifically, if my machine was compromised because IT was late rolling out an update, my machine was still compromised, so it doesn't really matter whose shoulders the blame lands on.

The focus should be less on preventing an attack (still important) and more on limiting the impact of an attack. My machine getting compromised means leaked source code, some dev docs, and having to roll back/recreate test environments. Prod keeps on going, and any commits an attacker makes in my name can be specifically audited. It would take maybe a day to assess the damage, and that's it, and if I'm regularly sending system monitoring packets, an automated system should be able to detect unusual activity pretty quickly (and this has happened with our monitoring SW, and a quick, "yeah, that was me" message to IT was enough).

My machine is quite unlikely to be compromised in the first place though. I run frequent updates, I have a high quality password, and I use a password manager (with an even better password, that locks itself after a couple hours) to access everything else. A casual drive-by attacker won't get much beyond whatever is cached on my system, and compromising root wouldn't get much more.

For your average office worker who only needs office software and a browser, sure, lock that sucker down. But when you're talking about a development team that may need to do system-level tweaks to debug/optimize, do regular training or something so they can be trusted to protect their system.

tools that you use don’t change all that often

Sure, but when I need them, I need them urgently. Maybe there's a super high-priority bug on production that I need to track down, and waiting 2 days isn't acceptable, because we need same-day turnaround. Yeah, I could escalate and get someone over pretty quickly, but things happen when critical people are on leave, and IT can review things afterward. That's pretty rare, and if I have time, I definitely run changes like that through our IT pros (i.e. "hey, I want to install X to do Y, any concerns?").

Most of us are pretty anti-google overall in our company anyway.

Then maybe we'd be a better fit than I thought. If, during the interview process, I discovered that IT didn't use MS or Google for their cloud stuff, I may actually be okay with a locked-down machine, because the IT team is absolutely based. I'd probably ask a lot of follow-up questions, and maybe you'd mitigate my concerns.

But when shopping around for a new job, I steer clear of any red flags, and "even devs use standard IT images" and "we're a MS shop" completely kills my interest. My current company is an MS shop, but they said we have our own infra for our team, and we use Macs specifically to avoid the standard, locked-down IT images.

On my personal machines, I use Firefox, openSUSE (due to openQA, YaST, etc; TW on desktop, Leap on NAS and VPS), and full-disk encryption. I'm considering moving to MicroOS as well, for even better security and ease of maintenance. I expose internal services through a WireGuard tunnel, and each of those services runs in a docker container (planning to switch to podman). I follow cybersecurity news, and I'm usually fully patched at home before we're patched at work. Cyber security is absolutely something I'm passionate about, and I raise concerns a few times/year, which our OPs team almost always acts on.

All of that said, I absolutely don't expect the keys to the kingdom, and I actually encourage our OPs team to restrict my access to resources I don't technically need. However, I do expect admin access on my work machine, because I do sometimes need to get stuff done quickly.