The Google Vortex
apenwarr.ca
apenwarr.ca
Conversations with pre-Google-employment friends go along the lines of:
"What are you working on?" "Well I was working on an inventory tracking system using Flask and Redis so I needed to kludge together something to store session in ..."
After getting hired by Google, these conversations are more like:
"What are you working on?" "App Engine." "Oh. Um. What parts?" "Oh, you know. Python and stuff."
It's sad.
So congrats to Avery and everyone else who's getting sucked in. I'm sure things are awesome over there, and I hope some day you'll be able to come back out and tell the rest of us about it.
But I sure as hell am never going to give up my freedom to talk to my friends.
Not that this is a good thing. But it's very interesting, in terms of incentives.
Man, I just find that tremendously depressing.
But now I feel like a jerk for raining on your parade so I'll butt out. Enjoy the tech and the food and the awesomeness, and I hope some day you'll be able to tell the rest of us what you've learned.
I work on the production kernel for our data centers, and most of what I do is completely public. In fact at the moment I am working on a way to decrease seek overhead when writing large files to ext4, and I have been releasing the in-progress patchsets for review and comment both in and outside Google. Why? Because I've gotten some really valuable comments both at the design level, and "spot the stupid bug" level, both inside and outside of Google.
That being said, there are some really cool things that are only available inside the Google kernel. For example, we can track every read, write, and seek operation at the hardware level, and tell you whether it is metadata or data, what application was responsible for issuing the request, and then correlate this information across multiple machines and in fact across the entire data center, and give you a single high-level view of your map reduce, or your application homed on hundreds of machines, so you can see how it is actually using all of the disk spindles associated with that job. And its overhead is small enough that we can leave it running by default, as opposed to only turning it on during debugging/benchmarking runs (ala blktrace).
Why haven't we shared this with the external world? Well, part of it is because it depends on infrastructure which is Google-specific, but the main reason is because we can't find the right people to help us clean up the code so it would be mainline acceptable, disentangle the Google-specific enhancements, negotiate with the upstream Linux kernel maintainers whose subsystems are touched by this code, and get it into mainline kernel. And for most of these kernel enhancements (of which this is only one), we _want_ to get them upstream, because every single one of these enhancements (while they are really cool and there is no way we would give them up), makes it harder for us to rebase the kernel so we can get the latest enhancements from upstream. More people using it means we hopefully will get a community of people collaborating to make the technology better --- which means free engineering help for us! :-)
The problem is headcount; we need to staff up this and other projects before we can do things like push more of these Google-specific enhancements upstream to the Linux kernel. (Some of it is happening now, slowly, but we have lots of other production and release priorities which take precedence.) Unfortunately, it's really hard to find Systems People who are interested and willing to do low-level Linux kernel programming, and can also see the "big picture" systems issues.
So if you think you're a hotshot Systems designer who is not afraid to get their fingers dirty coding low-level Linux kernel code, we're hiring (and not just in storage, although that's my area; contact me). And if you come to work at Google, you may be surprised at how much you can talk to your friends about, and even publish as a paper at a conference. Yes, there is plenty of stuff about features under development in Google Docs, Search, Android, that you'll be able to play with as an early dogfooder, and that stuff you won't be able to share with your friends. And some stuff we can't share because it would harm our relationship with our hardware partners --- but even there, Google has published a paper at FAST describing the failure rate and patterns of hard drives (although we anonymized the specific names of the disk drive manufacturers involved, for obvious reasons).
I'm surprised people think this is such a big deal, actually, because invariably there is some stuff that you have to keep secret at all companies. I found that there was more stuff related to my day-to-day work which I had to keep quiet at my former employer, IBM, than I am here at Google. And I'm sure that Apple engineers would be even more constrained!
For what it is worth, when I read this article one of the people it reminded me of is someone from the Chrome OS team. It might be, however, that with the release of the Cr48 that the situation has changed (I last talked to him days after those shipped). The people I've met from the Chromium team, however, were certainly a different story.
However, I know a /lot/ of people at Google (Chrome OS, Books, Social, Native Client, Ads, Docs, and those are just the people I know a project title for), and for almost all of them the article's content rang true.
I'd add one more thing, though: I often get to hear about just how much fundamentally better their tools are, or how much larger their scale of operation is, with this background attitude of legitimate pity. To be clear, I mean to say that I get a really legitimate positive emotional read from them of "I wish you were here, too, so you could play with me on the other side with all of this cool stuff".
And I'm sure that Apple engineers would be even more constrained!
I never actually knew many people who wanted to work for Apple, but those who did are certainly in a fundamentally different class of secrecy: for all intents and purposes they are now dead to me (which may be a uniquely-me problem: I could see them being fired for even talking to me; the treatment I now get from them is "head down, don't reply, shut down conversation, leave venue").
There's a great book called "Watership Down". In it, a band of ragtag rabbits whose home was destroyed come across a warren where all rabbits are well-fed and seemingly happy, and yet, something is wrong, every so often one of them disappears. Except no one talks about it, because that would mean admitting that they live on a rabbit farm.
Draw your own conclusion.
I've worked for a university (MIT), a startup (VA Linux), a big company (IBM), and compared to my past employers, I've easily found Google to be the best for me. Others may find the environment at a 30 person, 300 person, or 300,000 person company more congenial. A lot of it is personal preference...
Perhaps because it's possible to do something new and crazy (and unrelated) in Google, and not so possible to do so in Facebook.
Plenty of Googlers are entrepreneurial enough to leave and do startups, but they aren't considered mafia because they were never part of an early core group that bonded. And those that are entrepreneurial enough to leave aren't as high-profile entrepreneurial as early-stage employees would be.
Any decent professional should know when to keep his mouth shut. And it should know that leaking privileged information would potentially get him fired and marked as unreliable. No NDA required.
An NDA not only keeps an employee quiet, but it makes him liable long after the employment relationship has ended.
I, for one, would not work for any company that would force me to sign an NDA. Besides being insulting, it's just not worth it.
Wait a minute, you generate that much profit and then you don't get paid even half that much? Sounds like why I left Apple.
Are the reduced risk and added infrastructure really worth Google's 90% cut?
That's the important comparison - it's quite possible for you to keep 100% of the value you create, but only create $60-70K/year of value. Several of my college friends (not in the valley) are in that position.
If you took a vote, I bet the majority of people at Google would be terrified to get paid according to the corporate earnings they account for.
Also note that the quoted earnings have of course deducted anything that got paid directly to the owners; the listed earnings are the money that is getting re-invested straight back into the company, not paid to the founders, so it's not quite valid to compare it directly to what you would earn if you owned the company.
Personally, the only thing I miss is the social environment of the office.
And I've had friends in industry move up the ranks and get high six figure salaries and multi-million dollar bonuses.
And I sometimes look at the hecticness of startup life and think that I'm finally getting too old for it. And while the idea of working for myself is a good one, I've always felt like I was working for someone -- just this person never told me who they were, what they wanted, or when I'd be paid. :-)
So, while we continue to hire from Waterloo where it works, we're also looking further afield for talent... Iqaluit here we come!
I'm probably going to be banned from HN for saying this, but the giant Google talent vacuum cleaner is one potential reason that starting a startup right now is especially difficult and maybe not the right choice.
When I've started startups before, it's been in economic down times (eg. right after the .com boom). I actually preferred it that way.
It's different, that's for sure. Different isn't necessarily equal to better, though.
Google is going to create an updated version of Geocities?