2012.0530 permalink

Why I left Google

This post is getting a lot more attention than I expected or hoped. I wrote it mostly for family and friends who know me well and who might be curious about it. So I need to address some stuff to avoid saying the wrong thing.

Responses to Hacker News comments

  • Replies to DannyBee's comments

    I think I've unintentionally misrepresented Google here. I'm not a lawyer or an expert, and I tried to play things safe and as much by the book as possible, since I didn't know what to expect. I did receive a reply about the project to the effect that it was in an area that Google was interested in, and it was a pleasant surprise when they allowed me to release the code and retain copyright. I'm not blaming anyone from the committee and I completely appreciate their efforts and reasonableness. The two-month complaint was a contrast from my previous job, where open-source software was easier to release. But I don't think Google was remotely unfair or unreasonable.

  • "No mention seems to be made of how long Spencer was at Google"

    I was there for a total of six months. A lot of people have said this is not enough time to get an accurate picture, and I think that's correct. A big part of why I left had to do with family events, and I was unsure about how well I would do considering my biases as a programmer.

  • "[he basically said] 'if you don't adopt functional programming you are a loser'"

    I'm biased about this. I don't think Google employs a bunch of losers. They're worth billions of dollars and I don't even own a house. My post isn't about what Google is or isn't, it's about the problems I faced based on my biases and perspective. I'm certainly not saying I'm right.

  • "LinkedIn shows a series of jobs, each lasting less than one year"

    My job history is choppy primarily because of choices I've made. I've been thinking about this a lot and haven't completely figured out why I've had so much trouble staying in one place. A lot of it comes down to perfectionism on my part, and the kind of impatient and relentless optimization that ultimately leads nowhere. For what it's worth, I've been in a professional career for three years since college, so I've got a lot to figure out. But that should also put this post into perspective; I'm not coming from a broadly informed viewpoint.

  • "the Scala game of integrating every single academic PL research feature of the last 20 years"

    I hate Scala with a passion, for what it's worth. I just wish there had been more advocacy for it.

  • "directly counter to California law [about open source projects]"

    Google isn't trying to be difficult here. The problem is that they do so much stuff that you're inevitably competing with something, or at least it's hard to rule that out. So to be safe, I ran every new project by the committee. They did a great job handling it, too. I just wish the latency had been a little lower. (First-world problems.)

  • "Google's broken hiring process"

    I think Google's hiring process is perhaps the most objective, well-considered, and effective I've ever seen. The stuff I'm complaining about is probably inevitable in a company this size, and like I stated a few times in the post itself, it really is an indictment of me, not them.

  • "noobs are under the impression that HR somehow impacts employees"

    Sorry, I should clarify. When I talk about HR, I'm talking about everything that wasn't related to coding. Vacation time and expense reimbursement, for example. The system was brilliant, easy to use, and efficient. I never felt like I was blocking on any kind of red tape.

  • "Sounds like someone is a bit difficult to please."

    Yes! I don't even like a lot of the technology I write for myself, and I consider myself to be one of the most xenophobic and picky technologists I know. This is not Google's fault by any means.

  • "Abstraction is discouraged" (I wrote this)

    This is probably misleading. I'm talking about abstraction in the general sense; things like metaprogramming, etc. I'm not talking about anything like simple code duplication, which Google is very sensible about. Avoiding clever abstraction is why their engineers rarely kill each other. But I missed having a job where I could write code like this, so it acted as a Con in my decision process.

Also, jrockway has provided an excellent summary from the other end. Seriously, read this if you want a thoughtful counterpoint.

Original post

I resigned from Google about a month ago and have been meaning to write about it. It's always hard to sound grateful when describing why something didn't work out, but hopefully this comes across as more of an analysis of my own flaws than an indictment of Google. On the whole, they are an awesome company and I thoroughly enjoyed my time there.

Also keep in mind that I only saw the part of the company I was working with. Google is a huge place and a lot of my observations probably don't generalize at all.

From a highly subjective and local point of view, here are some of the key factors that influenced my decision. List items are in no particular order.

Technological culture

This is by far the most important factor behind my decision about where to work, and it was ultimately the reason I ended up leaving. I think a lot of this has more to do with my biases than with any particular flaws in Google's technical process. Again, this is all from my point of view and isn't necessarily meant to be objective.


  1. Total openness. I could read and contribute to the source code for almost any project.
  2. Well-engineered solutions to hard problems.
  3. Rigorous unit testing and attention to low-level code quality.
  4. Good developers had more influence than bad ones (Google employs some of each).
  5. Very reliable and solid infrastructure to help developers get their job done.
  6. Bugs and features were generally well-prioritized within the context of our project.
  7. 20% is a real thing, and there are lots of opportunities to pursue cool projects. Mine involved machine learning, for example.
  8. Basically unlimited computing resources if you needed them.
  9. Good technological choices were valued and encouraged.


  1. Pathological love for Java and anything resembling Java.
  2. Little inclination to solve fundamental problems; most engineering effort spent on superficial implementation.
  3. Most engineers were not comfortable with {functional, concatenative, combinatory, logic, meta} programming.
  4. Therefore, most code was stateful and object-oriented, and no alternative design was seriously considered. [1]
  5. Coding standards and reviews prevented bad low-level decisions, but not bad high-level ones.
  6. Reviews preferred local simplicity over global simplicity; abstraction was discouraged.
  7. Internally-developed languages like Go and Dart failed to solve any significant problems. [2]
  8. UI programming was incredibly tedious due to GWT and its enterprise Java influence, and I as an engineer felt like I couldn't do anything to improve the situation. [3]
  9. Java was viewed as being "good enough"; alternatives like Scala and Clojure were not considered. [4]
  10. Insufficient code ownership for engineers to have a reason to write excellent code.
  11. Out-of-the-box thinking was often not useful.
  12. Productivity was graded without much regard to the amount of technological debt accrued. (Though to be fair, this is a hard problem.)
  13. The overhead of getting things done was often dominated by a complex API. Many internal APIs were excessively complex, in my opinion.
  14. High turnaround time for my own open-source projects. [5]
  15. Gratuitous boilerplate and complexity were widely accepted.


  1. I didn't mind the fact that they had chosen OOP for nearly everything. There are good reasons to do this. What bothered me was that a lot of people making these decisions didn't seem to have enough knowledge of alternatives to make well-informed choices from a strictly technological point of view. This probably reflects the conservative nature of a large company, but things like this detract from Google actually feeling like a startup.
  2. This didn't impact me directly, but I felt like it was symptomatic of a larger problem within Google's technological power structure. It also felt like a compromise for the wrong reasons; Google was nominally willing to solve hard problems, but even with people like Guido van Rossum and Rob Pike, they ended up backing out of implementing well-established, if not mainstream, PL research.

    Update (June 4): There's been an interesting discussion going on in the Go Google group, and I should clarify what I meant here. I'm not saying that Go is a bad language to use, like it's all the others in every way, etc. What I'm saying is that it gets its roots in concurrency from Erlang, a language that, in my opinion, did a better job of addressing concerns like shared-nothing even if in a less-than-performant way. Erlang also was designed from the ground up to be highly concurrent; immutability and such are baked into the language at a low level to make this work. I don't know a lot about Go, but from what I've seen, it appears to be a version of Erlang that made it about halfway to C and didn't really decide to stick to a particular mode of thought (e.g. shared-nothing actor model, shared-memory multitasking).

    Incidentally, Michael Jones has brilliantly captured the idea I'm talking about. Google has the intellectual firepower to be going where no programmer has gone before, yet languages like Go remain solidly in well-understood and, for the most part, commonly-implemented territory. I have no doubt that this is a good strategic move on Google's part, and that Go solves a number of important problems that Google faces, but I was disappointed that Google hadn't taken a more experimental and research-focused approach.

  3. Not all teams have this problem; some write their frontends in Javascript directly, which I imagine makes things nicer. But even the Javascript coding standards are rigid enough to preclude a lot of interesting metaprogramming opportunities otherwise afforded by the language.
  4. This is a personal bias and point of arrogance on my part. Java is "good enough" if you are a MegaCorp who hires mostly inexperienced college graduates; but Java is, by many standards, not a powerful language and not something that makes sense as a mandate for solid, experienced developers. Scala and Clojure each have significant design flaws, in my opinion, and neither would have been a significantly better choice. My objection is not that Google didn't choose one of these, but rather that it's symptomatic of a technological inertia that prevents new ideas from being adopted.
  5. This deserves some explanation. Technically, Google owns everything you write while you work there, even if it's on your own time and with your own equipment. However, they have a committee that reviews things you write and assigns copyright to you provided that they don't conflict with something Google is working on. My experiences working with this committee were completely positive, but there was often a two-month lag before I got an official reply from them. This uncertainty bothered me a lot, since I wasn't sure whether my project could be legally released as open source.

Corporate culture

This wasn't nearly as important to me as the technological culture, but it did still matter. This list is also subjective and may not accurately represent Google as a whole.


  1. Efficient, well-managed HR system with minimal bureaucracy and red tape.
  2. Excellent managers, tech leads, and delegation of responsibility.
  3. Excellent salary, benefits, corporate policies, etc. I cannot emphasize this enough.
  4. "Don't be evil" was taken seriously at all levels of the company.
  5. Engineers were given everything required to be happy and do their jobs well.
  6. Top of the line hardware, and easy access to other devices.
  7. Frequent tech talks by guest and internal speakers, and about interesting subjects.
  8. You could leave your desk without anyone assuming you were slacking off.
  9. Minimal corporate politics, at least from where I was standing.
  10. Google employees were generally cool people. I can't think of anyone I didn't like.
  11. Low-stress, low-pressure work environment.
  12. No negative feedback from management or my team lead. All criticism was constructive, and I really had to ask for it to get any. [1]
  13. Every week, upper management answers (sometimes critical) questions from employees.
  14. I felt at ease talking to my manager and team lead about anything that was bothering me.
  15. It was common practice to make snarky memes, often about Google, and send them to other employees. Management snarks back.
  16. Google as a company has a great sense of humor.
  17. Developers could set their own schedule, modulo meetings.
  18. Performance reviews, interviews, and other evaluations were very objective and fair. I never observed any bias of any sort.
  19. User experience was a high priority.


  1. Google+. [2]
  2. Ubiquitous political emphasis on Google+ that sometimes compromised other engineering efforts.
  3. Products were not engineered with low-powered devices in mind. [3]
  4. Features outweighed the bugs that came with them. [4]
  5. Performance feedback was infrequent and vague.
  6. A lot of the maintenance I was doing produced a worse user experience, in my opinion. [5]
  7. "More wood behind fewer arrows."
  8. Much more formal than a startup (could also be a pro, but for me it was less fun).


  1. This isn't my way of saying, "look how awesome I am." I totally made my share of screw-ups. I think Google management is legitimately very cool about this stuff across the board.
  2. I think Google+ is an effort that does not deserve the engineering minds at Google. This is mostly a personal bias. I see Google as solving legitimately difficult technological problems, not doing stupid things like cloning Facebook. Google, in my opinion, lost sight of what was important when they went down this rabbit hole.
  3. This is a natural by-product of the combination of (1) dogfooding, and (2) giving engineers top-notch hardware. I think both of these practices are fine, but the problem could be addressed by issuing each engineer an underpowered netbook in addition to the insanely powerful machines we were given.
  4. I'm referring to a number of things, but I feel like Google's tolerance for bugs has gone way up since the early days of GMail. They have implemented more features, but the overall software quality is lower now in my opinion.
  5. This was a major downer for me. I thought the original Google UIs were simple, clean, and fast; the new ones felt clunky and buggy, and I felt like the attention to detail that went into the originals was lacking in our redesigns. The decisions behind this were primarily corporate-driven, not engineer-driven.


Some people read this post and concluded that Google would be a bad choice for them. I think that's a definite possibility, but my advice would still be to apply and take a job if you're offered one. There are two reasons I think this makes sense.

First, you could be wrong. You might really love it. And if you do, it's probably one of the top five jobs you'll ever have. Enough brilliant programmers love working at Google that I think it's naive to dismiss this possibility too quickly.

Second, I doubt you'll come out having learned nothing. I learned a lot at Google and left mostly because I wanted to take the time to pursue stuff closer to my interests.