5 ms·

I was nodding along so strongly to the first half of this that I was genuinely surprised when the other shoe dropped. I see another friend get sucked into the v

• apenwarr 16y ago
  Your last line is an interesting one. The point when more than 50% of my friends worked at Google was a really serious one for me: it became the point at which joining Google meant gaining the freedom to talk to my friends. Not that this is a good thing. But it's very interesting, in terms of incentives.
  • jacobian 16y ago
    > The point when more than 50% of my friends worked at Google was a really serious one for me: it became the point at which joining Google meant gaining the freedom to talk to my friends. 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.
    • khafra 16y ago
      It could be worse. If you go military/industrial complex instead, even if all your friends also have TS/SCI clearances you can't talk about what you do unless they need to know; and even then only in a SCIF and over an encrypted line.
• tytso 16y ago
  It really depends on what project you're working on at Google. Some are so secret you can't even reveal their name, or even what general area that they are in. Others are done completely in the open. For example, if you work on Chrome or Chrome OS, most of what people work on is available in public repositories. 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!
• zellyn 16y ago
  Part of it is that it's simply difficult to keep track of what's public and what's not. My various Google apps are full of as-yet-unreleased features, all on their own schedules. Unless I track the external blogs carefully, it's hard to know what I can talk about. When I really need to know, I'll search and see if something is mentioned on the web...