15 ms·

Why I Left Google

224 points by InfinityX0 14y ago

zemo 14y ago
complains about the widespread use of Java, but also complains that Go is stupid. Sounds like someone is a bit difficult to please.
cwills 14y ago
"Pathological love for Java and anything resembling Java." "Java was viewed as being "good enough"; alternatives like Scala and Clojure were not considered." Perhaps Google should have acquired Sun, and worked on updating Java to keep up with other C derivatives (e.g. C#).
- Drbble 14y ago
  Yes :-(
- Drbble 14y ago
  Yes :-(
Steko 14y ago
Mildly shocked this comment thread hasn't been hijacked by Michael O Church yet.
- Drbble 14y ago
  Passing the torch to the next generation of tourist cum expert. You can't expect these folks to stick with their avocatiom more than a few months before quitting.
  - heretohelp 14y ago
    You two are contributing to HN becoming cattier than a brothel of backbiters.
sodelate 14y ago
everybody leaves Google if there are better company
herval 14y ago
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?
- ChuckMcM 14y ago
  When I was there is was more by 'layer' so if you were in the customer facing side you were pretty much talking Java or C++ but if you were in operations it could be Python, C, or bash scripts even.
  - heretohelp 14y ago
    > if you were in operations it could be Python, C, or bash scripts even. As the case may be of late...Haskell.
- j_baker 14y ago
  Google's a bit ambivalent about Python. On one hand, you have a contingent of programmers who don't consider python a "real" programming language. These types seem to be mostly on the search team. On the other hand, there are plenty of pockets within the company where Python is used pretty heavily. The most notable is arguably the App Engine team.
  - tim_sw 14y ago
    and youtube
  - myko 14y ago
    I found this out during my interviews at Google; after I solved a problem using Python the interviewer gave me another and said "this time use a real language." Ouch.
    - underwater 14y ago
      That's pretty bad. Interviewing should also be about selling the candidate on the company. If they get an offer you want them to accept. If they don't then you don't want them bad mouthing you to other potential candidates. If an interviewer insulted me or my language choice in an interview it would definitely make me wonder how they would treat me as a coworker.
cageface 14y ago
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. 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.
- dsrguru 14y ago
  Have you witnessed any problems resulting from Scala "integrating every single academic PL research feature of the last 20 years"? (I was under the impression that aside from the actor model of concurrency, Scala typically gets used just like Java but with cleaner code.)
  - guelo 14y ago
    I think the signature of the map function is now the standard example of Scala being too smart for its own good. def map[B, That](f: A => B)(implicit bf: CanBuildFrom[Repr, B, That]): That
    - DannoHung 14y ago
      Yeah, this is really a consequence of Scala trying to do much shit for you automatically with the map function. See, it's not just a map function, but also an auto-conversion function from any generic sequence to any other generic sequence. What the hell does that mean? Okay, so basically, take your standard map function. Run it on the structure you're mapping over. Great, now you've got your updated structure! Now, you don't just want to return the same type of structure you just had, you also want it to be a different structure, but with those modified elements you had for its contents. Now build that new structure from the thing you just modified (Scala may actually optimize the traversal and construction of the new collection into one pass, although I am not positive). And there's your return value. It actually gets more complicated due to the Liskov principle and the way that Java handles type erasure, but thinking about that shit just makes me fuckin' tired. You want to know what the map type signature should look like if the Scala guys weren't going overboard on trying to make things seem outwardly simple? class Functor f where fmap :: (a -> b) -> f a -> f b
cletus 14y ago
No mention seems to be made of how long Spencer was at Google. 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. Also there are lots of people who use Python but ultimately its production use is limited. 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. 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). Anyway, sorry it didn't work out. Good luck, Spencer.
- trimbo 14y ago
  Yeah, I read his list of cons mostly thinking "gee, this sounds like an environment I'd enjoy". What look like cons when you're younger often end up being pros once you've been around the programming block a few times and inherited code that should be featured on the Daily WTF.
  - dwc 14y ago
    I've been around the programming block a few times myself and inherited some perfectly horrible code, and his list of cons makes me shudder. But people differ. I've (purposefully) worked at smaller companies where I had more influence over the technical direction. I think a good amount of his cons list come from the size of Google, and all that large size brings with it. Many of those things are probably needed in a large enough company, to prevent the very things you seem to think they'd bring (Daily WTF time!) But in a small company with decent people, those rules and attitudes would be overly restrictive.
- AdrianRossouw 14y ago
  "Pathological love for Java and anything resembling Java." I've often sensed this, when they push stuff like [1] GWT and to some extent Dart. and of course the entire android brouhaha. [1] https://developers.google.com/web-toolkit/ https://developers.google.com/web-toolkit/
raverbashing 14y ago
Ouch this seems painful 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 exactly on this: "Reviews preferred local simplicity over global simplicity; abstraction was discouraged" I feel like I'm a million years old, but I think procedural programming does it right. It seems most OOP programmers want an excuse to do 10 levels of inheritance and split the functionality in weird ways. The rest seems likely to derive from google's broken hiring process.
- roguecoder 14y ago
  Your complaint is the opposite of what he was complaining about. He wanted to be allowed to split functionality in weird ways, abstract more and employ meta-programming, which is way less procedural than OO.
- Jare 14y ago
  Nah, I've been around long enough to know that local simplicity ruled the day just as much if not more in pre-OOP days. OOP is great because it allows programmers and architects to create reliable and clearly defined types as data building blocks. But sometimes the hard parts of the problem are not in the structure of runtime data. Classic imperative and structured programming focused on the format of input data as the driver for code architecture, and that is the right way to design processes. Performance-oriented code needs to pay attention to data access more than to data structure or even to operations. Doing only OOP takes your attention away from those issues, and thus limits your design. Also, OOP focuses your attention on abstraction, and with a large enough problem, lack of visibility and clarity of requirements lead you to abstraction for abstraction's sake.
- evincarofautumn 14y ago
  Even as a relatively young† programmer, I’m with you to a certain extent. OOP‡ is both technically and philosophically unsound. However, though I use C quite a bit, I don’t think procedural programming is the paradigm to end all paradigms. My knowledge, productivity, and code quality have all benefited from functional programming (Haskell and Scheme) and generic programming (C++). Also, splitting up functionality is a part of good abstraction, and “weird ways” might only appear weird because you’re unfamiliar with them. That’s how I felt for a while about monads, for example. Some of it is just having the experience to see what qualities make code good in a particular paradigm. And regardless of paradigm, good abstractions are essentially about factoring and reducing repetition (DRY). †though not terribly new ‡the “classes and inheritance” kind that Java epitomises
smattiso 14y ago
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.
drivebyacct2 14y ago
The only Con that really made me nervous was 15 and even without context it doesn't say a lot. Boilerplate isn't always bad though it usually hints at things that could be better and more reliably solved. Funny, he complains about over-usage of OOP but off-handedly dismisses Go. Not sure I understand that.
arkitaip 14y ago
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.
- greggman 14y ago
  It sounds like you're reading an awful lot into one person's experience. Lots of people at google love their jobs, feel challenged and fulfilled, see all the oppertunities google provides from touching the lives of millions to open source projects to 20% time to access to every project at the company etc etc etc as an amazing blessing. Others have either bad experience, a bad attitude or maybe a little of both. I don't think one guy's opinion is really a reflection of most employee's experiences at google. I've been here 4 years. Haven't written one line of Java. Get paid to contribute to open source, have started 5 to 20 side projects, all open sourced. I could go into a lot more things but suffice it to say Google is by far the best place I've worked out of the 10 places I've worked so far.
ajross 14y ago
This bit seems wrong (about private open source projects): > Technically, Google owns everything you write while you work there, even if it's on your own time and with your own equipment. 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?
- wpietri 14y ago
  I'm pretty sure you're correct. This is the relevant CA law: http://www.leginfo.ca.gov/cgi-bin/displaycode?section=lab&group=02001-03000&file=2870-2872 http://www.leginfo.ca.gov/cgi-bin/displaycode?section=lab&#3... However, these things can have subtleties introduced by the courts, so anybody reading this should talk with a good lawyer before betting a lot on this point.
  - d503 14y ago
    It looks like that's true, "except for those inventions that ... Relate at the time of conception or reduction to practice of the invention to the employer's business, or actual or demonstrably anticipated research or development of the employer." With a company like Google it would seem that quite a lot of things might fall into that category.
    - ajross 14y ago
      True enough. But that's still a far cry from "all your codes are belong to us, get in line for the committee". I suspect this is an instance of policy getting ahead of legality. It makes sense for Google to want to review employee open source work (and they could even do things like fire people who don't honor the process). But if it was represented to him that he needed approval to legally release code, then I think someone lied to him.
      - DannyBee 14y ago
        Nobody represented that to him. Let me quote what I wrote in the thread we had on hackernews on this exact subject of spencer leaving yesterday (with the same title, no less :P), then let me explain something additional First, a quote "First, this is not the normal open sourcing process. He says "This uncertainty bothered me a lot, since I wasn't sure whether my project could be legally released as open source.". The normal open sourcing process takes about 3-7 days. If he really wanted certainty about releasing it as open source, he could have gone through that process and been done with it. The process he is talking about is the process of Google granting ownership of various IP rights that google would normally own, to the employee. For various reasons (ethics, patents, copyright, etc) this is more complicated, and takes longer. Google is one of the few large companies that even lets you do this, AFAIK. The humorous part of all this is that the page describing the process, states quite clearly it will take about 2 months to make a decision. So it's not like the 2 month wait was unexpected, either, and phrasing it like he does implies that there was some amount of uncertainty in the time period where he was being strung along, which is simply not the case." In addition to the above, let me add that at least in the case that took two months, Spencer wasn't asking the committee about open sourcing. He asked "If possible, I would like to own all IP (though Google can use it too, just not patent it) and possibly not release the results of this research to the open source community." This is the one that took 2 months to decide about. He had said "this is probably not related to what Google is doing", and I explicitly warned him the day he applied that what he wanted to get a release for was in an area google did care about, and was doing research in.
jacalata 14y ago
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?
- wpietri 14y ago
  For the same reason that broadsheet newspapers and magazines put the text in columns, I imagine. Because if you make text too wide it's hard to read.
  - spencertipping 14y ago
    That, and because my main machine is a 1024x600 netbook, so I sized it to fit on that screen.
  - CamperBob2 14y ago
    How about letting the user make that call?
    - wpietri 14y ago
      That is the sort of thinking that gave us the X Windows configuration file. Nobody wants to make that call for most things in their life. Nobody has time. There is definitely a minority of people who do want to carefully size each browser window for optimal reading, but it is a pretty small minority.
deleted 14y ago
[deleted]
akanet 14y ago
As a guy who basically did Java/GWT at Google for a year, I feel like I could have written this exact article.
CUR10US 14y ago
Correction: Pathological love of Java and C++ 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?
- michaelochurch 14y ago
  http://www.paulgraham.com/pypar.html http://www.paulgraham.com/pypar.html
MikeCampo 14y ago
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.
- michaelochurch 14y ago
  I have two years experience with Clojure and about a year working with Scala (plus use of Ocaml and a bit of Haskell). Clojure and Scala both have warts. Many, many warts, as all languages do. Still, I can't say that I've found major, intractable "design flaws" (as in, design decisions leaving me convinced I could do it better) in either. They run on the JVM, and they're ambitious languages, so warts are inevitable. That's hella hard, and both languages do an excellent job considering the constraints involved. Most of the things I find myself disliking in these languages have more to do with JVM legacy (e.g. type erasure in Scala) but that's also what gave them a chance at being mainstream, so no complaints there.
  - Dn_Ab 14y ago
    It's worth noting that Reifeid generics also have their limitations. I believe Haskell also does a similar level of erasure. Reified generics makes it harder to include higher order types and so the level of abstraction in Scala's collections or monad transformers would be much harder without type erasure. Haskell's type system is better at keeping the annoyance of erased types away by not just casting every thing to a top type.
  - swah 14y ago
    Surely Ocaml also has its warts - in the end my feeling is that of Simoni "you must create a programming language, or be enslav'd by another man's." (http://axisofeval.blogspot.com.br/2010/06/letter-to-young-pl-enthusiast.html http://axisofeval.blogspot.com.br/2010/06/letter-to-young-pl...) And for now use whatever gets the job done.
- tensor 14y ago
  From Spencer's twitter a bit ago: "Clojure inherits many problems and flawed patterns from common lisp." http://twitter.com/#!/spencertipping http://twitter.com/#!/spencertipping
icefox 14y ago
"High turnaround time for my own open-source projects. [5] ... two-month lag before I got an official reply from them .." 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.
- DannyBee 14y ago
  See what Chris Dibona/I wrote above. The turnaround is not really two months for open sourcing, it's 3-7 days.
  - sporkmonger 14y ago
    FWIW, Chris Dibona's record response time to a request I've made to open source a project was somewhere on the order of seconds. Maybe 10 seconds I think. It was like he had his finger hovering over the "Approve" button. Patent approval takes longer and does seem to push things into the 3-7 day range, but I once didn't get a response from them, and Chris basically just said, "Well, that's their problem. They were supposed to respond and they didn't, so you can go ahead and release." The open source team at Google is amazing and frankly, more companies should copy them. This stuff matters.
varelse 14y ago
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... 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.
- peter_l_downs 14y ago
  I don't know what you meant by tarbaby but that's a pretty offensive term. HN is not the place for that kind of speech. http://ycombinator.com/newsguidelines.html http://ycombinator.com/newsguidelines.html
  - orionvmjoseph 14y ago
    I gather he meant the colloquial meaning in most places of the world which is something to the tune of "Something best avoided rather than confronted.". I believe it originates from a story or fable as such. However I assume you meant he was using it in the more offensive slang usage for african-american. Chances are he might not even know it has the connotation as it's pretty specific to America.
    - waqf 14y ago
      Here is your story or fable as such: (2004 retelling) http://americanfolklore.net/folklore/2010/07/brer_rabbit_meets_a_tar_baby.html http://americanfolklore.net/folklore/2010/07/brer_rabbit_mee... (1886 version) http://en.wikisource.org/wiki/Uncle_Remus:_His_Songs_and_His_Sayings/The_Wonderful_Tar-Baby_Story http://en.wikisource.org/wiki/Uncle_Remus:_His_Songs_and_His...
    - Resident_Geek 14y ago
      Nobody uses "tar baby" as a slur in America. It's like "niggardly" - ignorant people use an incorrect interpretation to try to shut down people they don't like.
beosrocks 14y ago
Dupe from the other day: http://news.ycombinator.com/item?id=4044219 http://news.ycombinator.com/item?id=4044219 The only difference in the URL is the unnecessary "www." prefix. Perhaps news.arc could be updated to treat both URLs the same?
cromwellian 14y ago
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. 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. 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.
jpdoctor 14y ago
> Efficient, well-managed HR system with minimal bureaucracy and red tape. Noobs are under the impression that HR somehow supports employees. That is not the function. There is one and only one function for HR: CYA for the company.
- Drbble 14y ago
  Why would you ever work somewhere where employees were not considered part of the company?
jrockway 14y ago
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. 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. 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 :) 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. (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&M restocking policies, quit out of protest, and realize how horrible the real world is. IMHO.) Now on to some specific points: Programming-related: Pathological love for Java and anything resembling Java. 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 fun like Perl is.) 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. Most engineers were not comfortable with {functional, concatenative, combinatory, logic, meta} programming. 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.) Reviews preferred local simplicity over global simplicity; abstraction was discouraged. The first half is true, simply because reviews are line-based rather than repository-based. But there is a design review 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. 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. Abstraction is not discouraged. Productivity was graded without much regard to the amount of technological debt accrued. (Though to be fair, this is a hard problem.) 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. 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. 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. 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. (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 :)
Apocryphon 14y ago
I wonder if there are similar articles from ex-Apple people.
zobzu 14y ago
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. Employment is always so taboo. Not so much freespeech if you don't wanna live with the "consequences".
- spencertipping 14y ago
  That's not why I did it. I felt bad because my family and friends know me as being unreasonable, idealistic, etc. But HN doesn't know anything about me and might assume I'm an otherwise reasonable person. So I wanted to make sure I wasn't badmouthing Google here. They really are an awesome company and the point was never to make them look bad. More just to explain about where the incompatibility was.
physicslover 14y ago
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. 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. But you are free to take on a 20% project to show the value of other ideas. I would also challenge technology cons #2, #10, and #11. I think a lot of Google Engineers do tackle fundamental problems.
jdefarge 14y ago
Java was viewed as being "good enough"; alternatives like Scala and Clojure were not considered. If a company enter the what-is-the-hottest-language-of-the-week 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. Scala and Clojure each have significant design flaws, in my opinion, and neither would have been a significantly better choice. 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 amazingly 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++.
antirez 14y ago
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. 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. 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. 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. 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. 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 may tell you that the candidate is focused on the details, and the brain is a zero-sum game sometimes. Another thing I'm pretty convinced of is that this kind of candidates is not the only kind of employees 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. So the #1 problem of Google IMHO is to allow more internal divesification of cultures and programming backgrounds.
- Hurdy 14y ago
  Did it ever occur to you that 5 questions at a recruitment desk might not be representative of the whole Google hiring process?
caustic 14y ago
> Pathological love for Java and anything resembling Java. 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. 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. 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. 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. PS 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?
gbog 14y ago
> "I'm certainly not saying I'm right" When you said it, if you did not believe in what you said, you better have not said it. 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? 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). If you still think it is right, please stand for your opinion, it may have some value for others. [] Just finished a nice podcast about Wittgenstein...
- spencertipping 14y ago
  Hang on, you're being a little unfair about this. I believe in what I said. I think FP is a great step forwards and I think it's going to win out. I'm biased because I think this. But Google is worth billions of dollars and is succeeding wildly at innovating and changing the world, and I'm a lone developer. I can't very well stand here and tell Google, "hey you billionaire company, you're doing it all wrong; I've got the magic bullet right here." Part of the dichotomy is whether to define success as financial wealth or as some kind of more abstract software quality. And I think that's a legitimate variable; if Google is wealthy but has lower-quality software for it, then they and I just have different priorities. I stand for my opinion by investing all of my spare time into FP language development and research, but until I see a billion-dollar company using it, I'm not going to call anyone a loser for choosing Java.
  - gbog 14y ago
    OK. Maybe it should be another discussion but to me FP is a step backwards. Anyway I am glad to see you defending your position a bit.

224 points by InfinityX0 14y ago

zemo 14y ago

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

cwills 14y ago

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

Drbble 14y ago
Yes :-(
Drbble 14y ago
Yes :-(

Steko 14y ago

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

Drbble 14y ago
Passing the torch to the next generation of tourist cum expert. You can't expect these folks to stick with their avocatiom more than a few months before quitting.
- heretohelp 14y ago
  You two are contributing to HN becoming cattier than a brothel of backbiters.

sodelate 14y ago

everybody leaves Google if there are better company

herval 14y ago

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?

ChuckMcM 14y ago
When I was there is was more by 'layer' so if you were in the customer facing side you were pretty much talking Java or C++ but if you were in operations it could be Python, C, or bash scripts even.
- heretohelp 14y ago
  > if you were in operations it could be Python, C, or bash scripts even. As the case may be of late...Haskell.
j_baker 14y ago
Google's a bit ambivalent about Python. On one hand, you have a contingent of programmers who don't consider python a "real" programming language. These types seem to be mostly on the search team. On the other hand, there are plenty of pockets within the company where Python is used pretty heavily. The most notable is arguably the App Engine team.
- tim_sw 14y ago
  and youtube
- myko 14y ago
  I found this out during my interviews at Google; after I solved a problem using Python the interviewer gave me another and said "this time use a real language." Ouch.
  - underwater 14y ago
    That's pretty bad. Interviewing should also be about selling the candidate on the company. If they get an offer you want them to accept. If they don't then you don't want them bad mouthing you to other potential candidates. If an interviewer insulted me or my language choice in an interview it would definitely make me wonder how they would treat me as a coworker.

cageface 14y ago

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. 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.

dsrguru 14y ago
Have you witnessed any problems resulting from Scala "integrating every single academic PL research feature of the last 20 years"? (I was under the impression that aside from the actor model of concurrency, Scala typically gets used just like Java but with cleaner code.)
- guelo 14y ago
  I think the signature of the map function is now the standard example of Scala being too smart for its own good. def map[B, That](f: A => B)(implicit bf: CanBuildFrom[Repr, B, That]): That
  - DannoHung 14y ago
    Yeah, this is really a consequence of Scala trying to do much shit for you automatically with the map function. See, it's not just a map function, but also an auto-conversion function from any generic sequence to any other generic sequence. What the hell does that mean? Okay, so basically, take your standard map function. Run it on the structure you're mapping over. Great, now you've got your updated structure! Now, you don't just want to return the same type of structure you just had, you also want it to be a different structure, but with those modified elements you had for its contents. Now build that new structure from the thing you just modified (Scala may actually optimize the traversal and construction of the new collection into one pass, although I am not positive). And there's your return value. It actually gets more complicated due to the Liskov principle and the way that Java handles type erasure, but thinking about that shit just makes me fuckin' tired. You want to know what the map type signature should look like if the Scala guys weren't going overboard on trying to make things seem outwardly simple? class Functor f where fmap :: (a -> b) -> f a -> f b

cletus 14y ago

No mention seems to be made of how long Spencer was at Google. 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. Also there are lots of people who use Python but ultimately its production use is limited. 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. 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). Anyway, sorry it didn't work out. Good luck, Spencer.

trimbo 14y ago
Yeah, I read his list of cons mostly thinking "gee, this sounds like an environment I'd enjoy". What look like cons when you're younger often end up being pros once you've been around the programming block a few times and inherited code that should be featured on the Daily WTF.
- dwc 14y ago
  I've been around the programming block a few times myself and inherited some perfectly horrible code, and his list of cons makes me shudder. But people differ. I've (purposefully) worked at smaller companies where I had more influence over the technical direction. I think a good amount of his cons list come from the size of Google, and all that large size brings with it. Many of those things are probably needed in a large enough company, to prevent the very things you seem to think they'd bring (Daily WTF time!) But in a small company with decent people, those rules and attitudes would be overly restrictive.
AdrianRossouw 14y ago
"Pathological love for Java and anything resembling Java." I've often sensed this, when they push stuff like [1] GWT and to some extent Dart. and of course the entire android brouhaha. [1] https://developers.google.com/web-toolkit/ https://developers.google.com/web-toolkit/

raverbashing 14y ago

Ouch this seems painful 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 exactly on this: "Reviews preferred local simplicity over global simplicity; abstraction was discouraged" I feel like I'm a million years old, but I think procedural programming does it right. It seems most OOP programmers want an excuse to do 10 levels of inheritance and split the functionality in weird ways. The rest seems likely to derive from google's broken hiring process.

roguecoder 14y ago
Your complaint is the opposite of what he was complaining about. He wanted to be allowed to split functionality in weird ways, abstract more and employ meta-programming, which is way less procedural than OO.
Jare 14y ago
Nah, I've been around long enough to know that local simplicity ruled the day just as much if not more in pre-OOP days. OOP is great because it allows programmers and architects to create reliable and clearly defined types as data building blocks. But sometimes the hard parts of the problem are not in the structure of runtime data. Classic imperative and structured programming focused on the format of input data as the driver for code architecture, and that is the right way to design processes. Performance-oriented code needs to pay attention to data access more than to data structure or even to operations. Doing only OOP takes your attention away from those issues, and thus limits your design. Also, OOP focuses your attention on abstraction, and with a large enough problem, lack of visibility and clarity of requirements lead you to abstraction for abstraction's sake.
evincarofautumn 14y ago
Even as a relatively young† programmer, I’m with you to a certain extent. OOP‡ is both technically and philosophically unsound. However, though I use C quite a bit, I don’t think procedural programming is the paradigm to end all paradigms. My knowledge, productivity, and code quality have all benefited from functional programming (Haskell and Scheme) and generic programming (C++). Also, splitting up functionality is a part of good abstraction, and “weird ways” might only appear weird because you’re unfamiliar with them. That’s how I felt for a while about monads, for example. Some of it is just having the experience to see what qualities make code good in a particular paradigm. And regardless of paradigm, good abstractions are essentially about factoring and reducing repetition (DRY). †though not terribly new ‡the “classes and inheritance” kind that Java epitomises

smattiso 14y ago

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.

drivebyacct2 14y ago

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

arkitaip 14y ago

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.

greggman 14y ago
It sounds like you're reading an awful lot into one person's experience. Lots of people at google love their jobs, feel challenged and fulfilled, see all the oppertunities google provides from touching the lives of millions to open source projects to 20% time to access to every project at the company etc etc etc as an amazing blessing. Others have either bad experience, a bad attitude or maybe a little of both. I don't think one guy's opinion is really a reflection of most employee's experiences at google. I've been here 4 years. Haven't written one line of Java. Get paid to contribute to open source, have started 5 to 20 side projects, all open sourced. I could go into a lot more things but suffice it to say Google is by far the best place I've worked out of the 10 places I've worked so far.

ajross 14y ago

This bit seems wrong (about private open source projects): > Technically, Google owns everything you write while you work there, even if it's on your own time and with your own equipment. 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?

wpietri 14y ago
I'm pretty sure you're correct. This is the relevant CA law: http://www.leginfo.ca.gov/cgi-bin/displaycode?section=lab&group=02001-03000&file=2870-2872 http://www.leginfo.ca.gov/cgi-bin/displaycode?section=lab&#3... However, these things can have subtleties introduced by the courts, so anybody reading this should talk with a good lawyer before betting a lot on this point.
- d503 14y ago
  It looks like that's true, "except for those inventions that ... Relate at the time of conception or reduction to practice of the invention to the employer's business, or actual or demonstrably anticipated research or development of the employer." With a company like Google it would seem that quite a lot of things might fall into that category.
  - ajross 14y ago
    True enough. But that's still a far cry from "all your codes are belong to us, get in line for the committee". I suspect this is an instance of policy getting ahead of legality. It makes sense for Google to want to review employee open source work (and they could even do things like fire people who don't honor the process). But if it was represented to him that he needed approval to legally release code, then I think someone lied to him.
    - DannyBee 14y ago
      Nobody represented that to him. Let me quote what I wrote in the thread we had on hackernews on this exact subject of spencer leaving yesterday (with the same title, no less :P), then let me explain something additional First, a quote "First, this is not the normal open sourcing process. He says "This uncertainty bothered me a lot, since I wasn't sure whether my project could be legally released as open source.". The normal open sourcing process takes about 3-7 days. If he really wanted certainty about releasing it as open source, he could have gone through that process and been done with it. The process he is talking about is the process of Google granting ownership of various IP rights that google would normally own, to the employee. For various reasons (ethics, patents, copyright, etc) this is more complicated, and takes longer. Google is one of the few large companies that even lets you do this, AFAIK. The humorous part of all this is that the page describing the process, states quite clearly it will take about 2 months to make a decision. So it's not like the 2 month wait was unexpected, either, and phrasing it like he does implies that there was some amount of uncertainty in the time period where he was being strung along, which is simply not the case." In addition to the above, let me add that at least in the case that took two months, Spencer wasn't asking the committee about open sourcing. He asked "If possible, I would like to own all IP (though Google can use it too, just not patent it) and possibly not release the results of this research to the open source community." This is the one that took 2 months to decide about. He had said "this is probably not related to what Google is doing", and I explicitly warned him the day he applied that what he wanted to get a release for was in an area google did care about, and was doing research in.

jacalata 14y ago

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?

wpietri 14y ago
For the same reason that broadsheet newspapers and magazines put the text in columns, I imagine. Because if you make text too wide it's hard to read.
- spencertipping 14y ago
  That, and because my main machine is a 1024x600 netbook, so I sized it to fit on that screen.
- CamperBob2 14y ago
  How about letting the user make that call?
  - wpietri 14y ago
    That is the sort of thinking that gave us the X Windows configuration file. Nobody wants to make that call for most things in their life. Nobody has time. There is definitely a minority of people who do want to carefully size each browser window for optimal reading, but it is a pretty small minority.

deleted 14y ago

[deleted]

akanet 14y ago

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

CUR10US 14y ago

Correction: Pathological love of Java and C++ 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?

michaelochurch 14y ago
http://www.paulgraham.com/pypar.html http://www.paulgraham.com/pypar.html

MikeCampo 14y ago

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.

michaelochurch 14y ago
I have two years experience with Clojure and about a year working with Scala (plus use of Ocaml and a bit of Haskell). Clojure and Scala both have warts. Many, many warts, as all languages do. Still, I can't say that I've found major, intractable "design flaws" (as in, design decisions leaving me convinced I could do it better) in either. They run on the JVM, and they're ambitious languages, so warts are inevitable. That's hella hard, and both languages do an excellent job considering the constraints involved. Most of the things I find myself disliking in these languages have more to do with JVM legacy (e.g. type erasure in Scala) but that's also what gave them a chance at being mainstream, so no complaints there.
- Dn_Ab 14y ago
  It's worth noting that Reifeid generics also have their limitations. I believe Haskell also does a similar level of erasure. Reified generics makes it harder to include higher order types and so the level of abstraction in Scala's collections or monad transformers would be much harder without type erasure. Haskell's type system is better at keeping the annoyance of erased types away by not just casting every thing to a top type.
- swah 14y ago
  Surely Ocaml also has its warts - in the end my feeling is that of Simoni "you must create a programming language, or be enslav'd by another man's." (http://axisofeval.blogspot.com.br/2010/06/letter-to-young-pl-enthusiast.html http://axisofeval.blogspot.com.br/2010/06/letter-to-young-pl...) And for now use whatever gets the job done.
tensor 14y ago
From Spencer's twitter a bit ago: "Clojure inherits many problems and flawed patterns from common lisp." http://twitter.com/#!/spencertipping http://twitter.com/#!/spencertipping

icefox 14y ago

"High turnaround time for my own open-source projects. [5] ... two-month lag before I got an official reply from them .." 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.

DannyBee 14y ago
See what Chris Dibona/I wrote above. The turnaround is not really two months for open sourcing, it's 3-7 days.
- sporkmonger 14y ago
  FWIW, Chris Dibona's record response time to a request I've made to open source a project was somewhere on the order of seconds. Maybe 10 seconds I think. It was like he had his finger hovering over the "Approve" button. Patent approval takes longer and does seem to push things into the 3-7 day range, but I once didn't get a response from them, and Chris basically just said, "Well, that's their problem. They were supposed to respond and they didn't, so you can go ahead and release." The open source team at Google is amazing and frankly, more companies should copy them. This stuff matters.

varelse 14y ago

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... 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.

peter_l_downs 14y ago
I don't know what you meant by tarbaby but that's a pretty offensive term. HN is not the place for that kind of speech. http://ycombinator.com/newsguidelines.html http://ycombinator.com/newsguidelines.html
- orionvmjoseph 14y ago
  I gather he meant the colloquial meaning in most places of the world which is something to the tune of "Something best avoided rather than confronted.". I believe it originates from a story or fable as such. However I assume you meant he was using it in the more offensive slang usage for african-american. Chances are he might not even know it has the connotation as it's pretty specific to America.
  - waqf 14y ago
    Here is your story or fable as such: (2004 retelling) http://americanfolklore.net/folklore/2010/07/brer_rabbit_meets_a_tar_baby.html http://americanfolklore.net/folklore/2010/07/brer_rabbit_mee... (1886 version) http://en.wikisource.org/wiki/Uncle_Remus:_His_Songs_and_His_Sayings/The_Wonderful_Tar-Baby_Story http://en.wikisource.org/wiki/Uncle_Remus:_His_Songs_and_His...
  - Resident_Geek 14y ago
    Nobody uses "tar baby" as a slur in America. It's like "niggardly" - ignorant people use an incorrect interpretation to try to shut down people they don't like.

beosrocks 14y ago

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

cromwellian 14y ago

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. 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. 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.

jpdoctor 14y ago

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

Drbble 14y ago
Why would you ever work somewhere where employees were not considered part of the company?

jrockway 14y ago

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. 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. 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 :) 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. (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&M restocking policies, quit out of protest, and realize how horrible the real world is. IMHO.) Now on to some specific points: Programming-related: Pathological love for Java and anything resembling Java. 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 fun like Perl is.) 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. Most engineers were not comfortable with {functional, concatenative, combinatory, logic, meta} programming. 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.) Reviews preferred local simplicity over global simplicity; abstraction was discouraged. The first half is true, simply because reviews are line-based rather than repository-based. But there is a design review 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. 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. Abstraction is not discouraged. Productivity was graded without much regard to the amount of technological debt accrued. (Though to be fair, this is a hard problem.) 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. 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. 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. 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. (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 :)

Apocryphon 14y ago

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

zobzu 14y ago

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. Employment is always so taboo. Not so much freespeech if you don't wanna live with the "consequences".

spencertipping 14y ago
That's not why I did it. I felt bad because my family and friends know me as being unreasonable, idealistic, etc. But HN doesn't know anything about me and might assume I'm an otherwise reasonable person. So I wanted to make sure I wasn't badmouthing Google here. They really are an awesome company and the point was never to make them look bad. More just to explain about where the incompatibility was.

physicslover 14y ago

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. 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. But you are free to take on a 20% project to show the value of other ideas. I would also challenge technology cons #2, #10, and #11. I think a lot of Google Engineers do tackle fundamental problems.

jdefarge 14y ago

Java was viewed as being "good enough"; alternatives like Scala and Clojure were not considered. If a company enter the what-is-the-hottest-language-of-the-week 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. Scala and Clojure each have significant design flaws, in my opinion, and neither would have been a significantly better choice. 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 amazingly 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++.

antirez 14y ago

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. 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. 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. 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. 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. 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 may tell you that the candidate is focused on the details, and the brain is a zero-sum game sometimes. Another thing I'm pretty convinced of is that this kind of candidates is not the only kind of employees 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. So the #1 problem of Google IMHO is to allow more internal divesification of cultures and programming backgrounds.

Hurdy 14y ago
Did it ever occur to you that 5 questions at a recruitment desk might not be representative of the whole Google hiring process?

caustic 14y ago

> Pathological love for Java and anything resembling Java. 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. 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. 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. 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. PS 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?

gbog 14y ago

> "I'm certainly not saying I'm right" When you said it, if you did not believe in what you said, you better have not said it. 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? 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). If you still think it is right, please stand for your opinion, it may have some value for others. [] Just finished a nice podcast about Wittgenstein...

spencertipping 14y ago
Hang on, you're being a little unfair about this. I believe in what I said. I think FP is a great step forwards and I think it's going to win out. I'm biased because I think this. But Google is worth billions of dollars and is succeeding wildly at innovating and changing the world, and I'm a lone developer. I can't very well stand here and tell Google, "hey you billionaire company, you're doing it all wrong; I've got the magic bullet right here." Part of the dichotomy is whether to define success as financial wealth or as some kind of more abstract software quality. And I think that's a legitimate variable; if Google is wealthy but has lower-quality software for it, then they and I just have different priorities. I stand for my opinion by investing all of my spare time into FP language development and research, but until I see a billion-dollar company using it, I'm not going to call anyone a loser for choosing Java.
- gbog 14y ago
  OK. Maybe it should be another discussion but to me FP is a step backwards. Anyway I am glad to see you defending your position a bit.