Why I Left Google

No mention seems to be made of how long Spencer was at Google.<p>As for the "pathological love of Java", Spencer has a distorted view. This will vary from project to project. I'd say C++ is more pervasive although Java may well dominate applications (rather than infrastructure) code.<p>Also there are lots of people who use Python but ultimately its production use is limited.<p>A common theme here seems to be that as an engineer you are discouraged or disallowed for doing things that are too "clever". This is something I approve of. Other people need to maintain your code after all.<p>For example, the abusage of automatic semicolon insertion that the Twitter devs behind Bootstrap seem to love (as some kind of "see how smart I am" display) would never survive at Google (our style guide expressly forbids excluding semicolons).<p>Anyway, sorry it didn't work out. Good luck, Spencer.

A lot of the "cons" in the technical section just sound like a large engineering organization making pragmatic decisions. I can't think of any company working at that scale that's successfully integrated a non-trivial amount of functional or logic programming. As much as hackers might not like it, there are reasons that coding at that scale is almost always a matter of banging out a lot of imperative code in a boring language like Java.<p>And I'm definitely not the only one that appreciates Go precisely because it doesn't play the Scala game of integrating every single academic PL research feature of the last 20 years but instead tries to be as practical and simple as possible.

A few days ago I was at a conference and there was this Google recruitment desk, with gadgets and two nice guys. I walked near the desk and said: "Hi, can I have a t-shirt for my son?", and they said sure, asking me to compile a form in an Android tablet.<p>Basically it was a list of programming questions, and out of 5 questions I was able to reply only to three. One was the time complexity of heap sort, that's pretty obvious, another one a probability theory quiz about trowing balls into bins, also pretty reasonable. Another one I can't remember, still pretty general.<p>Then there were this two questions I was not able to reply: one was about Java argument passing conventions in some specific kind of method I can't even remember (I can't write "Hello World" in Java). Another was about graph theory and adjacent Matrix.<p>Well, my idea is, that a big percentage of Google problems are due to this kind of hiring process. It's good if I know the fundamental algorithms as a programmer, but why I'm required to know Java as it was a pre-requisite to be a good programmer? About graph theory, it's something that is rarely used, if I need to do something I can grab a book and check it, it's strange to remember this stuff when you don't use it a lot.<p>Now hiring only guys that know exactly the Java calling convetions AND graph theory means to apply a big filter between the programming world and your company. This filter is good as it's cool to know a lot of things, but it's also bad because, for instance, a lot of good programmers I know don't care about Java at all, and while they may have a generally good understanding of algorithms they don't remember how to factor a number with polland-rho, or dynamic programming, and so forth.<p>This filter does not tell you nothing about the real ability of the candidate to write good programs, to use the right abstractions, and to design beautiful systems. Actually it <i>may</i> tell you that the candidate is focused on the details, and the brain is a zero-sum game sometimes.<p>Another thing I'm pretty convinced of is that this kind of candidates is not <i>the only kind of employees</i> you want if you want to enter the social network business and compete with Facebook. Your output as a company will be a system that little resembles what average people want.<p>So the #1 problem of Google IMHO is to allow more internal divesification of cultures and programming backgrounds.

This bit seems wrong (about private open source projects):<p>&#62; Technically, Google owns everything you write while you work there, even if it's on your own time and with your own equipment.<p>Google is a California employer, and that's directly counter to California law as I understand it. The only exceptions made are for product areas directly related to your work (not just the employer's business interests). Am I wrong about this?

What's so fascinating about this is that it provides a glimpse of the inner workings of the Google machine. Even Google with its second-to-none reputation, cool tech and HR practices ends up alienating this employee because of its bureaucracy. This in a company founded just fourteen years ago. On one hand it's comforting to know that even the best of the best lose an important aspect of their competitiveness and might be defeated, on the other hand it is troubling how all companies seem destined to lose their agility and flexibility. Not even Google with all their incredible resources and brilliant minds can solve this, it seems.

<i>Java was viewed as being "good enough"; alternatives like Scala and Clojure were not considered.</i><p>If a company enter the <i>what-is-the-hottest-language-of-the-week</i> game it can easily drag itself in a downward spiral of death. Just because it boils down to taste! And it leaves a lot of hurted feelings around the way. Language is a lot about maintenance 10 years down the road.<p><i>Scala and Clojure each have significant design flaws, in my opinion, and neither would have been a significantly better choice.</i><p>Couldn't agree more! Be it a startup or a mega-corp, VPs should make their minds upfront and stay on their path until something <i>amazingly</i> better comes down the road. C'mon, if Google had chosen Scala, for example, they could have produced clean, concise code, FP-oriented software at the price of sluggish compilation times (many wasted minutes), lots and lots and lots of generated bytecodes, and binary incompatibility (ouch!). Jump into the trendy language badwagon and you find yourself nowhere pretty soon. I know of at least two prominent startups in Bay Area who are switching of Scala and adopting the old-fashioned Java, for many reasons, but fondness of OO or lack of vision are not among them. And a third startup is stealthily switching to Clojure. On the other hand, you have C/C++.

A big organization not wanting projects written in Clojure, Scala, or other language of the month? Yeah I wouldn't either. If 99% of your coders know Java, and there's no compelling reason otherwise, go with Java.

&#62; Pathological love for Java and anything resembling Java.<p>And I think that's the good thing. Over years I finally realized, it's not the programming language you use that matters, or makes you look smarter. It's the kind of problem you are trying to solve by writing code. Computer Science field is far, far reacher than the PL research subfield.<p>I mean, you may be writing another boring enterprise web application in Haskell, or solving Artificial Intelligence problem in Visual Basic. I would prefer later rather than former, although I hate VB. I know, both situations are contrived, this is just a thought experiment to illustrate my point.<p>Don't get me wrong, I love "esoteric" programming languages. Few years ago I spent quite a lot of time playing with Haskell, Prolog Lisp, etc, and I don't regret it. No, I don't use these on daily basis or going to, but I studied a hell lot of coll new stuff. Most importantly, it taught me about new _paradigms_ of programming, that I really think every programmer should understand.<p>These days, however, I try to squeeze as much math and algorithms from different domains as I can in my poor stupid head and I think that payoff of this would be much bigger for me.<p>PS<p>Few month ago at a local functional programming meetup some guys presented their Scala solution to a trivial problem of validating web forms in a rather trivial web application. Their solution employed the whole lot of functional stuff, like functors, mappings and the things whose names I forgot. I was trying to understand what they are doing but they lost me after fifth minute of the presentation. It took them maybe a week to write all this code. Do you see the irony?

Most Google projects are not written in GWT for the frontend, they are written in Javascript using Closure and the Closure compiler, that includes Gmail, Search, G+, Docs, Drive, etc.<p>Really, it sounds like this guy got put onto a team project he didn't like, but Google has very large codebases in C/C++, as well as JS, and there is ample opportunity to work on non-Java stuff. Chrome and Android (non-userland) in particular.<p>Any company with a team of people is going to have to place limits on polyglotism and have standards for readability and coding. I like Scala too, but the idea that a company is going to allow anyone to just pick any PLT research languages that they personally like sounds far-fetched.

Ouch this seems painful<p>The trend of "all OOP" especially in the Java world, and how OOP is done, is BAD. As in "there's something in my eye" bad.This reflects <i>exactly</i> on this: "Reviews preferred local simplicity over global simplicity; abstraction was discouraged"<p>I feel like I'm a million years old, but I think procedural programming does it right.<p>It seems most OOP programmers want an excuse to do 10 levels of inheritance and split the functionality in weird ways.<p>The rest seems likely to derive from google's broken hiring process.

I'm surprised by the tech part. I was under the impression Googlers used a lot of Python, for instance, and possibly other languages... Are these exceptional cases, then?

This is the best "Why I Left Google" article I've read, and I really don't have any criticism for it. Everything he says is true on some level, but things that look bad don't look as bad with some context. So I hope to provide that in case you are thinking of working for Google but are pushed in the "nah, maybe not" direction because of articles like these.<p>First off, you have to remember that Google is a big company. It's one of the world's most profitable, and there are quite a few employees. This is not a startup. This is not a world free of politics. This is not a world where the execs will listen to all of your concerns. (With that in mind, it is very easy to get their ear and voice your concerns. It's just that they might not drop everything to do things the way you think they should be done.) This is a publicly traded company with lots of stuff to do and processes that scale to a large number of employees.<p>But, that's not a horrible thing. If you've worked at other big companies (or bigger companies), this place is like a dream world. You know what other people are doing. You can see their code. You can see their processes running in production. You can have internal mailing lists where you might accidentally say something that looks bad during discovery. Every change you make to the codebase gets another developer saying, "yes, this looks good" before you commit. Everywhere I've worked before, anything like these would have been immediately shut down. Code reviews slow progress. Mailing lists are a legal minefield. Sharing code doesn't allow the correct cost center to pay for its development. That's how it is. If you are unhappy with Google's corporate policies, try working for Bank of America. You will not complain as much :)<p>On the other hand, if you are the "I want to work by myself and be a product manager, engineer, sysadmin, and CEO", then the big-company culture is not for you. I write code and talk about writing code. That's it, someone else does everything else. I like that, but if you don't, you won't like the big company lifestyle.<p>(So, with that in mind, I don't think Google is a good place for your first job out of school. You will be annoyed with the M&#38;M restocking policies, quit out of protest, and realize how horrible the real world is. IMHO.)<p>Now on to some specific points:<p>Programming-related:<p><i>Pathological love for Java and anything resembling Java.</i><p>This is a network effect. In any project I've started, I've been able to use any language I've wanted to. Plenty of projects are using Haskell, my personal favorite app programming language. The reason why I choose Python or Java at Google is because I want a large pool of people to get feedback from on code reviews, design reviews, at "could you take a look at this" time, and so on. Everyone knows Java, and so I can be more productive at Google if I use Java. I don't spend much time typing in code. I do spend a lot of time working with other people. I think Java is objectively a terrible programming language and I hate it conceptually, but the great internal community and great internal libraries make it quite usable. (Read my HN history. I am not kind about Java. But at Google, the limitations I complain about are not as relevant as they are when you are "out on your own". I don't foresee any personal projects in Java any time soon, however. It's too verbose for apps that don't need to be fast or scale. And it's not really <i>fun</i> like Perl is.)<p>If you absolutely cannot work with Java, then there are plenty of C++ projects to work on and your skills will be valued highly. Go is probably quite acceptable, too, given the right project.<p><i>Most engineers were not comfortable with {functional, concatenative, combinatory, logic, meta} programming.</i><p>Even though it's Google, programmers are at various different levels in their programming careers. I personally like programming languages and their differences in style, but other people are more practical and just want to sit down and churn out features for their project. They don't want to switch to Haskell because it's better at X than Java. They just want to make something new. So, if you want to be different, you need to be prepared to go out on your own. And if you're new to Google, you might not be ready to do that for two or three years, because there is so much other stuff to do. You're going to be thrown on a team and expected to contribute. Establish rapport and then try to change the world. Don't do it on your first day. (Again, if that's a problem, big company life might not be for you. This is a team effort, after all.)<p><i>Reviews preferred local simplicity over global simplicity; abstraction was discouraged.</i><p>The first half is true, simply because reviews are line-based rather than repository-based. But there is a <i>design review</i> stage of projects when you discuss high-level design. I was not used to writing design docs before writing code before working at Google, but now that I'm used to it, I like it a lot. It's saved me a lot of time, I think.<p>Code reviews depend on your teams' conventions. My team is super strict and nit-picky, but others will almost rubber-stamp changelists. Different personalities, different results. If you want harsher code reviews, review other code more harshly, I would say.<p>Abstraction is not discouraged.<p><i>Productivity was graded without much regard to the amount of technological debt accrued. (Though to be fair, this is a hard problem.)</i><p>I don't know much about this. I work with lots of people that are at the level I would like to be at in a few years, and I don't foresee any problems for myself. My bosses give me the impression that I choose good objectives and key results, and I pretty much meet all my key results. But it's only my second quarter at Google, so who knows.<p>As for the corporate culture points, I basically agree with everything he says. I don't think Google+ is the finest Google product the world has ever seen. That's my opinion and since I don't work on the project, nobody really cares what I think. I can live with that and even think it's reasonable. But if you want to associate everything a company of 30,000 does with your personal thoughts and beliefs, you might be disappointed.<p>I know I sound like a total pushover when I say "that's just how the world is and you should adapt yourself", but honestly, I just want to receive large quantities of money in exchange for playing with computers, and Google gives that to me. And really awesome food. And wonderful coworkers. So I can't complain much, especially after the other places I've worked.<p>YMMV. Why not try Google out for a year or two and see for yourself? You might like it, you might not, but you'll definitely learn something.<p>(And if you want to apply but don't have a contact at Google, I'm happy to be one. Tell me about yourself and I will try to get you in touch with the right people. jrockway AT google.com :)

As someone who worked there 4 months last year, this is pretty accurate. I had a more negative experience because I got consigned to an obvious tarbaby team that was bleeding an engineer a month, but this seems more like the norm...<p>And yes, Google makes claim to everything you write while you're there unless they explicitly agree otherwise. They have set up a committee for making those decisions. This is probably a good thing IMO.

As a guy who basically did Java/GWT at Google for a year, I feel like I could have written this exact article.

"Pathological love for Java and anything resembling Java." "Java was viewed as being "good enough"; alternatives like Scala and Clojure were not considered."<p>Perhaps Google should have acquired Sun, and worked on updating Java to keep up with other C derivatives (e.g. C#).

Correction: Pathological love of Java and C++<p>What's that essay PG wrote on starting Viaweb with RM where he said potential competitors advertising for Java and C++ developers did not make them nervous?

Spencer's comments are generally accurate. I might quibble with some of them or say that they vary from team to team. For instance, I have used R, Python, Java, and Sawzall in my work at Google and have had freedom to choose technologies on some of my projects with input from team members.<p>It is true that most of the larger production systems like the Search Engine are mainly written in C++ and Java and that functional programming isn't widespread, yet.<p>But you are free to take on a 20% project to show the value of other ideas.<p>I would also challenge technology cons #2, #10, and #11. I think a lot of Google Engineers do tackle fundamental problems.

&#62; <i>Efficient, well-managed HR system with minimal bureaucracy and red tape.</i><p>Noobs are under the impression that HR somehow supports employees. That is not the function.<p>There is one and only one function for HR: CYA for the company.

Dupe from the other day:<p><a href="http://news.ycombinator.com/item?id=4044219" rel="nofollow">http://news.ycombinator.com/item?id=4044219</a><p>The only difference in the URL is the unnecessary "www." prefix. Perhaps news.arc could be updated to treat both URLs the same?

&#62; "I'm certainly not saying I'm right"<p>When you said it, if you did not believe in what you said, you better have not said it<i>. The world is filled with enough empty smalltalks. Moreover, if even you do not believe in what you say, who the hell would believe in you ("read you") next time you say something?<p>If you thought it was right but have changed your opinion in between, please state it clearly. It is a strong mark of cleverness (to me).<p>If you still think it is right, please stand for your opinion, it may have some value for others.<p>[</i>] Just finished a nice podcast about Wittgenstein...

complains about the widespread use of Java, but also complains that Go is stupid. Sounds like someone is a bit difficult to please.

What's sad is that when this get publicity the author has to shield up all the things he said, which were probably honest; in order to avoid troubles/ future employment issues.<p>Employment is always so taboo. Not so much freespeech if you don't wanna live with the "consequences".

"High turnaround time for my own open-source projects. [5] ... two-month lag before I got an official reply from them .."<p>What I would give for two months! At my current employeer the turnaround time has been up to six+ month which has killed a number of my personal projects.

Mildly shocked this comment thread hasn't been hijacked by Michael O Church yet.

I would like to hear your thoughts on Clojure's serious design flaws. I'm currently learning the language and haven't come across anything warning me of such things.

I wonder if there are similar articles from ex-Apple people.

The only Con that really made me nervous was 15 and even without context it doesn't say a lot. Boilerplate isn't <i>always</i> bad though it usually hints at things that could be better and more reliably solved.<p>Funny, he complains about over-usage of OOP but off-handedly dismisses Go. Not sure I understand that.

everybody leaves Google if there are better company

offtopic nitpick: I have a really nice widescreen monitor, and you are giving me 13 words per line using about a quarter of the horizontal space. Why is that?