Is it a security thing? Are Googlers not allowed to directly control their own computers?
Actually one of my favorite Google experiences starting out was that I wanted to work with an Apple Magic Keyboard, and to get proper support for it I needed to compile some kernel driver I found on github. I asked IT support if I can do that, and the answer was "you're a SWE, review the code, make sure it looks legit and doesn't contain any security holes, and then it's your responsibility if you mess anything up". Which I did, and it worked just fine. It was in 2018 so it's not like I'm referring to some early days thing.
First, if the computer is provided by the company, for company work, they're not "their own computers." They're the company's computers. And I don't know about Google, but yes it is VERY common in most mid- to large-size organizations that employees are not allowed to change things on the machines they use for work.
The IT department is usually required by either contracts or regulation to follow certain security standards and many of those prohibit end-user modification of machines. And further, these are often enforced through annual, semi-annual, or quarterly audits. Failure to follow these standards can result in the loss of a sales contract, a critical certification, or fines.
So, just like a manufacturing worker is not allowed to modify a machine on the factory floor (even to fix it, or improve it, regardless of their skill to do so), employees are not allowed to modify the organization's computing equipment.
And, it's important to note, the IT department generally has NO say in these rules since they are a business or legal requirement.
Edited to add: I've also worked in companies where the developers who write the in-house software might be masters of the business problem domain and their programming language, but have exactly ZERO knowledge of hardware or the most basic system administration principles. It doesn't cross their mind that RAM and disk space are actually finite things, for example, and that it makes for a Bad Day when one of their programs starts to consume ALL of it. These are the people who should not really be managing their own operating systems at work.
Most bigcos are the same way, there’s a way to get root but there’s also security software or policies to counteract damage you could do. With most hardcore “zero-trust” setups you consider a device’s posture based on its current state and don’t take into account whether or not the user has admin rights (what do you care how what rights they used to install bad software, you just care that they installed bad software). No admin rights typically means nobody has time to do something better for end users or there’s a regulatory requirement (at the same time, bigcos can throw a sandboxed VM up in their data center that can’t access PII if devs need more access).
of course I was trying to get my brilliant colleague without a degree, noticed with that code; zero response, like stonewall. Later I read, that year Google got over 1million job applications.
weird place
What you didn't know is that it wouldn't work.
There is also an expectation that you don't just randomly start changing things in shared conference rooms. If there is an issue, you open a GUTS ticket and someone comes and solves the problem. Chances are if you discovered a real issue, there are 90 other rooms with the same issue that also would be updated.
If something doesn't work, they can communicate back to the (well-bearded) developer who sent them that weird build. The developer surely has some crazy esoteric distro on their bring-your-own device, but they also have desktops running the consistent distro available to them all around the office to reproduce the issue on. It's a bridge between worlds.
I work in academia and we manage our own Ubuntu spin for this reason, despite everyone we ship it to being very conventionally smart.
> if you're smart enough to work at Google, you're smart enough to manage your own OS.
I also like to think of myself as "smart" for self-managing most OS and cloud things. But the role of smarts is probably minor compared to the decade+ of experience I have doing it. When it's something I'm good at, I think it's because of intelligence. When it's something I can't do, I assume the people who can have lots of practice.
Nope. If you want access to more than just the basic corp resources, you’re doing it from a fully managed and approved OS on a company owned machine or VM.
No disrespect to you but this is a really naive take on how IT management works.
For one thing, not everyone at Google is an OS expert. There are people working for Google in marketing, sales, support, data science, graphic design, hardware design, and other fields where you can't depend on every person to "do the right thing" when it comes to "managing their own OS."
And even if they can, is that where you want them spending their time? Manually managing their OS? Don't you want them to do the job they were hired to do instead? Their computer is a work tool, not tinkertown.
Basically, the opposite of what you're saying is true: because 100,000 people work at Google, each person represents another way to potentially mess something up and cause problems for the whole company.
Assign each employee with probabilities:
- Probability of falling for a phishing scam
- Probability of installing malware
- Probability of an employee missing an announcement regarding OS/security policy
- Probability of an employee opening a support ticket with IT
These probabilities are very low for people who are computer-savvy, educated, very highly qualified people. The thing is, all you have to do is multiply those probabilities by 100,000 and now you've got a big problem.
It's much easier to run with zero IT automation if you've only got 10 people in your company and they all know each other.
For your probabilities, you describe many issues that aren't big issues at Google. Phishing credentials is mitigated by mandatory FIDO tokens, binary whitelisting heavily reduces installs of malware, security policy isn't needed on these desktops (really just needed for mobile devices incl laptops).
I just explained why it doesn’t matter that “most” people can manage their OS, that’s because Google has thousands of Linux users. If 1% of Google developers make a critical mistake that could be a hundred workstations or more.
On top of that, I still disagree. Many developers I’ve met are not that good at using the OS.
Remember that writing applications is a completely separate skill. You can learn to code completely separate from learning anything else about the computer. I had a college professor that taught C on a chalkboard, in this millennium.
Google’s own developer interviews are very CS and algorithm heavy and to my knowledge never test your abilities with OS management.
When you say “really just needed for mobile devices including laptops” that’s basically all devices isn’t it? You’d have to be incredibly specialized to need or prefer a desktop workstation.
I haven’t even brought up compliance controls and certifications yet, either. If you’re SOC 2 or HIPAA compliant you have to manage workstations to disable functionality and restrict system preferences. For example, there are typically restrictions on USB port data transmission and idle screen lock delay time.
I would absolutely despise it if I had to manage my own OS, just like I despise thinking about my keyboard layout or text editor.
Hacker News overrepresents the hacker type which loves the feeling of full control but I'd estimate that at least 33% of engineers, including many very talented ones, don't want that, and only want to focus on the concrete problems they are trying to solve.
* By default, a tool called “Santa” keeps a naughty and nice list of runnable programs but all it took to get a program added to the nice list is any other googler vouching for it in an automated web tool.
We’re root on both desktops and laptops though, I just rather use my time for work and I’m sure my employer would rather I do that too.
I don't really understand what "messing around mean" in your context. Exotic things like slackware or alpine aside, all major popular distros now offer unattended updates, easy upgrade path between major releases.
Your vscode, neovim, jetbrains whatever or emacs do not work differently from one distro to another and since nowadays many external stuff is either distributed as static binaries, containers or flatpacks or appimages everything is quite straightforward and not distro specific.
For example, security aside, as an engineer working on X that depends on internal tools Y, Z and W, I do not particularly care what variant of Linux is under the hood as long as I can run my favorite WM, editor and user apps. But I do want support on Y, Z and W if they misbehave. If I run a non-standard OS or distro I will likely get a lukewarm support because those teams will put debugging problems in "non-standard configurations" as a low priority.
Personally, I learned to live with most Linux distros. When I did roll out a non-standard setup I had a standby system in a standard configuration that I can show failures on before asking for help. My 2c.
Smart isn't really a key point here. You can be smart and make choices that solve your immediate needs but may not be good for the company in the long run. The distro provides for some standardization and baseline in among other variance.
> Is it a security thing?
Yes, one of the forms of standardization are audit solutions that keep track of all kinds of data about the machines. In the time I worked there, I once received outreach because a service I had started on the machine had retained an outgoing port to a third party service provider for an extended period of time. I explained what it was, and I did not get in trouble, but I also shut it down. There are many other forms of audit systems.
> Are Googlers not allowed to directly control their own computers?
It depends on your role, but many roles have root on their machines. You can of course do just about anything from there, however some things may get undone by periodic scripts if they're defensive (e.g. removal of certain software), or in other cases trigger some kind of outreach as described above. For certain other policies, you may need to file a bug with a business justification to request specific policies - you can also do this for entire teams if it applies to their work.
There's a tremendous value in having a somewhat homogenous environment. We have our own package repo and .deb packages to access internal resources. Even little stuff like editor plugins customized to our internal stuff we have packages for.
Plus, we hire a great deal of folks that aren't Linux experts. Have a sane set of defaults gets people going faster.
It makes a lot of sense to have our own distro when we're talking this kind of scale.
Not to mention all the non-engineers, even in tech roles like PM, design, etc.
Regardless of the scale, that is a recipe for having your highly capable, highly paid engineers losing hours, days, even worse - to annoying configuration issues etc. Sometimes it's the right thing to do (e.g. very early stage, no IT infra) but if you can have an IT person who is actually good/experienced at this sort of thing sort out the core problems, it's way more efficient.
It's astonishing how much collective time can be wasted on "well, it works on my machine" issues. This makes it worth coming up with some sort of systematic way to avoid (mostly) it.
> Is it a security thing? Are Googlers not allowed to directly control their own computers?
This and simplicity I think. There's definitely some controls over what kind of things you install on the MacBooks as well, though it's actually not that restrictive.
Oh boy, have I got some stories to tell you!
Although to be fair the question of who "manages" a workstation is not always as simple as just "who has the technical ability to manage it". It's the intersection of who is legally responsible for the device and it's data (this is BY FAR the most important part), who has the time to maintain it (that's often NOT the user), and who technically can maintain it according to whatever standard it has to be maintained to (this gets complicated when you factor in reporting, patching etc).
In my experience, a common approach on non-Windows systems is to give the users privileged access to do what they need to do while also monitoring that closely, managing patching for them, and if you have some legal requirement to do so; running some kind of AV for reporting purposes. This tends to strike a happy medium between giving IT/Security peace of mind to some extent while also not totally ruining the developer experience.
This is a bit like saying if you can operate on human brains, you should absolutely be able to take apart your car and put it back together.
Or your software has all these customization options
Or your product has a bunch of different configurations
What was already hard just became a thousand times more painful