
Why I Left Google - InfinityX0
http://www.spencertipping.com/posts/2012.0530.why-i-left-google.html
======
cletus
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.

~~~
AdrianRossouw
"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/>

~~~
cgs1019
GWT takes the (very large) pool of capable Java programmers and magically
enables them to become capable web programmers without mastering cross-browser
subtleties. It's all about compartmentalization. For any/all its faults,
that's an astoundingly immense value.

~~~
chubot
It depends what you mean by "capable". It's more accurate to say it takes
large pool of Java programmers and lets them write slow and bloated UIs with
canned widgets that are subtly (or not so subtly) inappropriate for the task
at hand.

Google should be producing best-of-breed UIs, not ones that are easy for the
unskilled to write. It's not like Google can't afford to hire the best.

A main reason for the slowness is that GWT obscures the boundary between the
client and the server. People end up writing things like:

    
    
      for (x in hugelist) {
        doSynchronousCall()
      }
    

without realizing it. And then people test it on fast internal network
connections and they don't realize what a poor experience results for average
users/mobile users.

Another problem with GWT is that the JavaScript world has moved extremely fast
in the 4 or 5 years since GWT was developed -- and most programmers don't know
how to interface GWT with native JS (and that would defeat the "purity'
anyway). So they're locked out of that functionality.

No matter how big the GWT team is, it can't keep up with the rest of the web
advancing the state of the art in JavaScript.

I've also heard from people working on the Wave codebase that GWT was a big
part of the reason they were locked into a particular design and couldn't
iterate. For some reason Java just encourages people to dump out mountains of
code. Maybe you can get away with that on the server, but when generating JS
it just leads to UIs that crash the browser.

~~~
cromwellian
Maybe you shouldn't comment on GWT if you don't know anything about it. Pretty
much everything you state about GWT is wrong.

1) GWT does not emulate synchronous APIs. That would incredibly expensive to
do, requiring the implementation of continuation emulation or CPS
transformation of the entire program.

2) GWT does not advocate "shielding" the developer from DOM or CSS. You are
free to use the widgets, or not, just as you are free to use JS libraries with
widgets, or not. The purpose of GWT isn't to hide the browser.

3) Most GWT programmers know how to interface with JS. I have not encountered
any non-trivial GWT app that does not contain at least some portion that makes
calls to JS.

4) On Javascript evolution. Sorry, Javascript has moved glacially slow. What
has moved fast is the HTML5 API bindings. When ES6 arrives and GWT doesn't
support it, then you have a point.

5) GWT is open source. It doesn't matter how big the GWT team is, it only
matters how big the community is.

6) GWT UIs don't "crash the browser". Google derives the majority of its
revenue from AdWords and AdSense, which are GWT, and if they were crashing
customer's browsers like you say, I'm pretty sure Google would be in trouble.

GWT is a compiler. You can write bad code, or you can write good code. In 2009
I ported jQuery to GWT. The resulting code was smaller than jQuery, and faster
than all other competing libraries at the time. See the result here:
<http://www.youtube.com/watch?v=sl5em1UPuoI>

I don't have anything against JS, and I don't think GWT is the right tool for
every project, but I don't think you should respond to threads like this and
make what appear to be authoritative statements which are obviously and
completely false (synchronous calls)

~~~
chubot
As mentioned below, the point about synchronous calls was made based on seeing
30+ second latencies in more than one GWT app and opening them up in firebug,
and seeing a crazy number of roundtrips (with many of them serialized). With
async APIs people can somehow still structure their applications so that
logically many full round trips are needed to render the page.

I'm not necessarily saying that's GWT's "fault" -- the claim is that the
developers writing GWT don't understand what they're writing. I said
essentially what I said here to a tech lead of a GWT app and he's like...
that's EXACTLY the problem we're having. This happened to be an app I've never
even used, but he was shaking his head in agreement.

I think GWT was written by skilled engineers who had written tons of JS and
got sick of the repetitiveness and the primitiveness of it in 2007 or
whenever. But the claim of the OP: "GWT takes the (very large) pool of capable
Java programmers and magically enables them to become capable web programmers"
is not true. Empirically, people who've never written JS are writing GWT, and
they are writing terrible web apps.

I guess you can say that tools create apps with a "smell". PHP creates web
apps with injection security holes. C creates apps riddled with dangerous and
costly buffer overflows (or used to before crazy amounts of compiler/library
work). I'll take a dig at my favorite and say Python creates apps that dump
stack traces on invalid input and don't handle signals correctly.

GWT's smell is creating bloated and slow apps now with bad UIs. I was pretty
surprised at the number of upvotes I received, so I'm not the only one that
smells it. Like C and others, it's possible that people will derive so much
value the tool that they eventually learn how to overcome the pitfalls.

~~~
cromwellian
I smell selection bias. Have you never visited HuffingtonPost, Gizmodo, or
PandyDaily and looked at the network tab? Javascript does not automatically
make people produce fast and snappy sites. That is based on experience,
regardless of language. There are tons of websites that make a boatload of
script include requests and image requests because the developers haven't
learned about UglifyJS or Closure Compiler yet, or don't know about CSS
spriting. Take a look at flights.google.com, it is a GWT app of non-trivial
functionality that loads faster than most comparable sites (<2 secs) and makes
far fewer requests. Another good one is the SpeedTracer app for Chrome (it
runs as an extension). It has a very very nice UI, better than Firefox and
WebKit WebInspector, and it's a GWT app.

Anyway, why do you think Google does all of their hand-coded JS apps with
Closure and the Closure Compiler? It's not because JS 'out of the box' is
conducive to producing best-of-breed apps. Web programming requires a large
amount of on-the-job acquired knowledge. How many people are aware of CSS
selector performance, or the performance effect of reading
element.offsetWidth?

GWT doesn't prevent you from shooting yourself in the foot, just like any
other language. Producing optimal apps in any language requires experience in
that language. Knowing how to arrange non-blocking behavior in script
inclusion, or batching requests, is something that comes with experience. I
wish I could produce a boilerplate framework that could make amateurs produce
absolutely optimal apps out of the box, but that would trade off a lot of
freedom.

However, GWT does offer tools to reduce your HTTP requests, and it's been
doing this for years before they became common place in JS. For example, GWT
has had automatic CSS spriting and image optimization since 2007. It's been
doing CSS optimization nearly as long. GWT 'perfect caching' has been in from
the beginning, which guarantees that most of the time, the app is loaded via a
single HTTP request to a small 2k bootstrap file. In fact, it's possible to
load your initial page: html, js, css, images in just 1-2 requests if you
desire. Obviously, there are tradeoffs there too, that are platform and app-
dependent.

There certainly are some APIs in the GWT SDK that can produce bloat if you use
them, and that is wholly dependent on your preference. The GWT RPC system, for
example, is great for internal apps, because it makes server communication
trivial, but GWT also includes regular JSON/JSONP/XHR support. You can choose
to use Widgets, or you can built your UI with HTML templates and CSS, just
like you might do with Handlebars in JS.

I guess my point is this: I don't deny that an amateur Java programmer could
take GWT and unknowingly compile a huge amount of junk into their app or make
an insane number of HTTP requests. I just don't think producing apps with
terrible startup latency is GWT specific, and I've seen enough websites in JS
that are absolutely terrible to know that the way you get an optimal UI is by
hiring good engineers with web experience, not by language choice.

And on that note, it's quite easy to get upvotes IMHO when you start a
language war, because people are so opinionated on one side or another about
it. My own personal opinion is that you should use the tools you feel most
productive in, period, and if that's JS, or GWT, or CoffeeScript, or
Objective-J, than more power to you.

~~~
white_devil
> Javascript does not automatically make people produce fast and snappy sites.

He never claimed otherwise. His point seemed to be that if someone just picks
up GWT and whips up an application, it's likely to exhibit some (severely)
suboptimal behaviour here and there.

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

~~~
tikhonj
From what I've heard, Go goes too far in the opposite direction and integrates
basically _no_ modern research.

~~~
duaneb
Go is not a research language (e.g. Haskell), it is pragmatic. I suspect a
part of the design decisions of Go factored in training for people using that
language. At a certain point, features that are alien cost more in training
costs than they will gain in "elegance" or whatever.

~~~
luriel
I don't think the concern is training, but the complexity caused by how
various features interact, and how hard they make to reason about code.

Go is designed so it is very easy to read and reason about what code does.

~~~
tikhonj
I don't know. Maybe it's because I've been mostly looking at Haskell and OCaml
recently, but most of the more "researchy" features and languages I've seen
aim to be _easier_ to reason about.

Unlike most languages (including Go, I believe), researchy languages tend to
have very well defined semantics based on well-understood math--really going
out of the way to be easy to reason about!

------
antirez
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
Did it ever occur to you that 5 questions at a recruitment desk might not be
representative of the whole Google hiring process?

~~~
lucian1900
They are quite representative.

~~~
Hurdy
You don't have to know Java to get hired, any programming language is fine.
You do get asked design questions. I think making the leap from these 5
questions to "This is the #1 problem Google has and why they fail at social
networks" is a bit far fetched, but it looks like I'm the only one...

~~~
lucian1900
The impression I got was that you don't have to know Java, but you should know
at least one of Python/Java/C++. They strongly prefer the latter two.

The leap from the questions to google failing at social networks is far
fetched, though.

------
ajross
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?

~~~
DannyBee
As a lawyer (IP, not employment), i can affirmatively state you are wrong
about this, for reasons various folks mentioned below (the actual phrasing
deals with relating to your company's business, not directly related to your
work).

Additionally, court interpretations of this statute are not as favorable as
engineers like to believe (IMHO).

Living in !California, from what I see, California is only theoretically
different from most states. In practice, for technology companies, the law
basically means your employer owns stuff on your free time, in the general
case.

(IE If you were working for a startup that does online home rentals, and you
were making a video game, you may have an argument)

~~~
ajross
Surely those court interpretations are situations where employees left to
pursue products though, right? Is there really case law where a company sued
to recover ownership of a free software project? That just seems lose-lose all
around. Bad PR, bad karma, no deep pockets to sue, no damages to recover.

Personally, I find this kind of bureaucratic nonsense infuriating. And I guess
I thought Google was better about it, but it doesn't seem to be. My past
employers have, for the most part, simply shrugged when told about open source
work I've done. Honestly I have to think that if I really ran afoul of a rule
like this I'd just call your bluff and see if you'd fire me over it (because
as I mentioned, we both know you won't sue).

~~~
DannyBee
There is plenty of caselaw I can find where, for example, employees have _not
left_ , but refused to sign over patents on stuff done in spare time, and
companies sued to recover them while the employee was still working there. I
have yet to find one where the company lost.

For open source work, if you go through the process, it's short and we're
happy to approve it (patches take about 30 minutes, projects, 3-7 days). In
the IP release process, it's longer. That is better than every company i have
worked at.

You seem to think it's not very important, and just nonsense in general.
Knowing who the legal copyright owners of the source code in your open source
project are is quite important (in the cases you posit where everyone is just
saying "whatever", the owner is unclear) If you don't think so, I can tell you
in the _one_ important case in the US where an open source project had to
defend itself, Jacobsen v. Katzer, that Victoria Hall (the lawyer) spent a
very large amount of her time trying to get all this sorted after the fact,
and it is only by luck that the 50+ contributors she had to wrangle were still
around and accessible.

This is probably 300k in legal fees that could have been saved by having done
the right thing up front at a cost of about 30 minutes. Note that these legal
fees were paid by the poor guy who was running the open source project, not by
his contributors.

If you want me to be blunt, no offense, I've met folks like you, who think all
this is a waste of time, and you are generally not worth the eventual expense
in legal fees to the open source projects you contribute to (IE when the open
source project needs to actually defend its rights, or the company behind the
OSS project gets sued). Shrugging and saying "whatever" also has a funny way
of turning into "that was really mine and guess what, we want damages" when
the company you worked for gets bought.

It's great to want the world to be different. I support all efforts to make
life better for engineers around owning stuff in their spare time. I also
spend a lot of my life trying to help open source in general.

But to be blunt some more: The world we live in right now is not a happy
pretty place. The reality is if folks like me, and the companies we work for,
tell you than when you release a new open source project we probably own, that
you should spend 5 minutes filling out a 4 field form and waiting a day for
some folks to click approve before you fly and be free, it's not because we
are power tripping bureaucrats. It's because we're trying to save millions in
legal fees when it matters, and make sure the open source project you want to
release is not going to be in a bad place, at a cost of 5 minutes of time and
a small amount of waiting.

So my advice is if you think you really want to "call someone's bluff", I
would instead think hard about whether you are really expert enough in this
stuff to be able to say it's all nonsense, and stop to think about whether the
people who are perpetuating "nonsense" may actually have your best interests
at heart. That is, trying to save you from yourself. If you really think it's
a great idea to have an awesome open source project used by 1 million people,
when it's not clear who actually owns the code, then all i can say is that i
pity those people.

~~~
ajross
You're projecting pretty badly here, and are flaming where I really don't
think it's appropriate ("People like you", indeed).

For clarity, though, when you say "the open source process", you mean the
process where Google gets assigned ownership. An employee who wants to release
something under an OSD compatible license without assigning copyright (for
whatever reason, say because they want to use the GPLv3 and you don't, or
because they simply don't trust a public company) does _not_ simply fill out a
4-line form and get an answer in a day, as I understand it.

( _edit: And you continue to euphemize this. It's not "special treatment",
it's a flat out copyright assignment. Ownership isn't completely clear, so one
of the parties needs to give up stake. And the process is clearly asymmetric
in Google's favor. That's not surprising, really, but what is surprising is
that you won't come straight out and say this._ )

And my advice to _you_ is that you consider the costs of this sort of thing to
the employees and the engineering work when making your conservative legal
pronouncements. As we've seen in the news today, even Google's rigorous IP
process isn't enough to keep you from getting sued. The world is indeed not a
happy pretty place; cavalier avoidance of process may not help things, but
neither does paranoia.

~~~
DannyBee
1\. I'm perfectly comfortable with what I wrote. I neither believe it was
inappropriately flaming given what you wrote, nor do I think it is "projecting
pretty badly", as you say (The "people like you" was intentional, and given
the evidence I have, seems correct. If it turned out not to be correct, i'd
happily retract it).

2\. Yes, people who want special treatment take time. We've made the common
case fast, and the exceptional case possible.

3\. We do consider the costs, and try to keep the process as simple as
possible while still accomplishing its goals. Note that I am an engineer as
well as a lawyer, and contribute to a large number of open source projects and
so I have to go through the same process everyone else does.

4\. You honestly don't know what you are talking about when it comes to things
you've "seen in the news", and i'll just leave it at that.

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

------
jdefarge
_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++.

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

------
caustic
> 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?

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

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

~~~
evincarofautumn
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

~~~
mayanksinghal
> both technically and philosophically unsound.

Philosophically? Can you please elaborate on this? Technically, I don't think
there is any unsoundness in OOPs as compared to functional programming (or
procedural or generic). Technically, there are paradigms available for all
requirements. It might end up being messy or boring or bloated, but that is
not a technical issue but more human. OO code on the other hand is incredibly
easy to grasp and the ubiquity of OOP fuels itself. May be we would have been
at a higher level in our enterprise codes if we had chosen a _superior_
language like Haskell, Scheme or Python for everything; but we don't it for
sure. Code is as much an art as it is science, and sometimes better art is
possible with outdated paradigms likes paint and paper than touch interfaces
and brilliant applications.

~~~
mappu
I believe the GP is quoting[1] from Alexander Stepanov (author of the C++
STL).

Saying "pick the right paradigm for the task" is of course the correct answer,
but it's fun to argue sometimes, and OOP is definitely overhyped in certain
markets (for instance, university CS)

______________________

[1] <http://www.stlport.org/resources/StepanovUSA.html>

~~~
evincarofautumn
Yes, I was (somewhat accidentally) paraphrasing Stepanov. It’s been a while
since I read that.

But actually, I think “pick the right paradigm for the task” needs the
qualification of “…within your other constraints”. The most _expressive_
language for a job might not work in your situation—whether for reasons of
efficiency, of maintainability (i.e., finding maintenance programmers), or of
interoperability with the rest of your stack.

------
herval
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?

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

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

~~~
majormajor
That's the sort of thing that would make me strongly consider ending the
interview, at least if I was going to be working directly for the interviewer.
No need to waste more of their or my time than necessary, and I really
wouldn't like working in that kind of insulting environment. And from a
probably-immature perspective, the feel of power from being the guy saying
"sorry, I'm not interested anymore" instead of hoping they call you back is
nice.

Or, if I was really annoyed: bust out some Common Lisp for the next problem,
then leave.

~~~
Goladus
Seriously, he said the next question was string manipulation or something:

    
    
        #include <stdio.h>
        char f[8] = {70, 117, 99, 107, 32, 121, 111, 117};
        int main(){
          int u; for(u=0; u<8; u++) { printf("%c", f[u]); }
          printf(".\n");
        }
    

Thank them for their time and walk out.

------
jrockway
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 :)

~~~
robrenaud
Mostly I agree with you.

But Google does have a strong C++/Java/Python bias. Even if it hasn't touched
you personally, it is very likely that a new Googler will be using one of
those 3 languages as her main language.

~~~
martinvanaken
Most large companies (and even mid-sized ones) have some kind of
"technological environment of choice" that sort of given (three languages is
already not so bad). It does not means it cannot change or be lifted for a
specific project, just that it is "what you are supposed to use", and that you
are expected to provide heavy arguments to be allowed deviate from it.

In most situations, this is actually wise : behind development, you have a
whole process (deploy, quality control, etc), and they will have the required
tools and expertise for the languages they use on a regular basis. And when
you start a project at a large company, you know that other people will take
it after, so it is easier if it is close to the company technical standards.

Having written an application in Ruby in a Java shop, I remember protesting on
the "rewrite in Java" that happened just after the prototype phase. With some
distance, I think I understand the decision.

~~~
tikhonj
There's nothing wrong with having a uniform set of languages. I just wish they
were _good_ languages and not Java or Python.

Having everybody use their own programming language would be crazy. Unless
they're domain-specific languages, in which case it would actually be very
cool.

Still, if I'm to be bound by a language choice, I'd really like to be the one
making it. Which is why I think working for a tiny startup would be more fun.

~~~
martinvanaken
It is important to know your own preferences, but as you said yourself, then
you need to make your choices accordingly : it could be the startup, or aiming
for a position in a big company where you have something to say about those
choices. Both are interesting.

For the first point, I will not start a discussion about what is a "good"
language (a large part of it being in the eye of the beholder and in the
requirements of the projects).

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

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

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

~~~
jongraehl
That said, you'd have to be crazy to use "niggardly" now after the reaction it
got whoever that was. If you use words that most of your audience doesn't
know, what does it say about you? :)

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

------
cwills
"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
Yes :-(

------
CUR10US
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
<http://www.paulgraham.com/pypar.html>

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

------
jpdoctor
> _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
Why would you ever work somewhere where employees were not considered part of
the company?

------
beosrocks
Dupe from the other day:

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

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

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

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

------
icefox
"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
See what Chris Dibona/I wrote above. The turnaround is not really two months
for open sourcing, it's 3-7 days.

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

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

~~~
Drbble
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
You two are contributing to HN becoming cattier than a brothel of backbiters.

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

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

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

------
sodelate
everybody leaves Google if there are better company

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

~~~
CamperBob2
How about letting the user make that call?

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

