I have a direct A/B experiment on this: I have one work laptop which is centrally managed by big-corp IT (I'm not the admin), and one laptop which is a project machine which I manage and admin.

Guess what? The big-corp IT managed computer which I only use to check email and edit Word docs is almost unusably slow, weighed down as it is with antivirus, surveillance software, centralized updates, etc. The project machine which I manage and have admin access to remains snappy despite its workload (Visual Studio) and older hardware.

Also, you gotta love the "cost savings" of let's outsource our IT, not let developers be admins on their own machine: now we have to buy secondary machines that developers ARE admin of, so they can get their work done.

Preach! I have the same issues,but my last place had me as IT for the whole (small) shop, and when they outsouced IT ('we need you on important_thing') they had me install all of the Corp Spyware (because 'why would we ask them to send their own techs, then we would have to wait for them to schedule us in, you do it- it'll be faster!) and I watched with Despair as all resources went to AV (gotta love that Norton 360, so secure), key-logging, sending everything out by the millisecond. It was like watching a dumpster fire.

I kept my machine as it was, explaining that if anything happened to those units (bad updates, blah blah), mine would be unaffected and mine was completely necessary.

Lo, and behold! That very day everyone was complaining how slow their computers were, how even basic websites now took ages to load, and they did.

The owner refused to admit he made a bad decision and stayed with that 'IT' 'company' for over a year, and didn't get rid of them until I'd left and no one was available who could triage, and they saw just how little that 'company' did, and just how much I was made to cover for them

> The owner refused to admit he made a bad decision and stayed with that 'IT' 'company' for over a year, and didn't get rid of them until I'd left and no one was available who could triage, and they saw just how little that 'company' did, and just how much I was made to cover for them

That last part leaps out at me as particularly interesting: highlighting behind-the-scenes firefighting work is always tricky. Management doesn't want to acknowledge that it's necessary, while engineering maybe shies away from managerial caricaturization of what ultimately amounts to implementational minutiae. How'd you end up conveying the behind-the-scenes work you did in these kinds of situations?

It sounds like they didn’t convey it all. As I read it, the boss only learned about the heroics after the employee had left and no one was around to put out the fires. And that sounds normal for the situation, because management did not want to hear about it.

Fun note at that. If nothing happens the CIO states boastfully how their spyware prevented crap from happening. If shit happens it is elaborate stuff we need more protection against.

If a developer needs to be admin to do their work the os needs a better security model.

That's highly dependent on the type of development work. I'm a kernel developer and I need regular access to privileged components of the system for a wide variety of reasons. It could be argued that all standard *nix/windows/mac systems need a better security model to better isolate specific tasks, but for much of what I need to do (e.g., create, modify file systems/boot loaders/kernels, ptrace processes, etc...), if I'm allowed to do it at all, I can get anywhere else anyway, so I may as well just have full admin and save everyone some headaches.

And I'd argue this isn't only true for kernel development. In some cases, sure, but certainly not enough to make such a blanket statement.

You shouldn't be doing your kernel development testing on the same machine as you do your office tasks.

Though I will agree there are exceptions, you are not one