

Why I Left Google - dphassler
http://spencertipping.com/posts/2012.0530.why-i-left-google.html

======
beosrocks
Fascinating account, but even more fascinating is the author's consultancy:

<http://spencertipping.com/zeroconsulting/>

 _You email me with a problem you'd like me to solve. (Be sure to put "zero"
in the subject so that my email filter catches it.) This could be anything: a
debugging project, advice about something, a library you need, end-user code,
etc. Anything you send me is confidential. I'll then follow up with you with
any additional information I need and any initial impressions I have._

 _I will then try to implement a solution _and will never send you a bill_. I
may or may not be able to implement something, depending on a variety of
factors including my skill set. If I'm successful, I'll send you what I come
up with. You may, at your option, pay me whatever you think my solution is
worth. It's fine if this is nothing at all; that's useful information for me
(I won't nag you about it, for instance)._

~~~
mikescar
Wow, that's cool. Clearly a guy with a love for the art. I'd be interested to
hear how this approach works out for him and the breakdown of his project
offers once he's been at it a while.

------
bozho
So, one of the major reasons is because you don't like Java. I don't like some
things people do with Java, but generally it is indeed good enough. In fact,
as far as I'm aware, there are three official languages in Google: Java, C++
and Python. Wasn't it possible to get assigned to python stuff?

~~~
dwj
Agreed. To be honest I don't see why he left...from his description it would
almost make me want to work there.

Java and C++ have their problems, but in general they work very well. If I was
in charge of software development at Google I wouldn't be using some obscure
language.

I agree with his comment about bugs...Google's products seem very buggy, and
they don't seem to give much of a crap about fixing them.

~~~
bandy

            Google's products seem very buggy, and they don't seem to give much of a crap about fixing them.
    

That's the essence of Silicon Valley right there. The Cool Kids don't fix
bugs. They don't test their code much beyond "Well, it doesn't crash for me.".
The Cool Kids only write new code using the latest and greatest programming
languages - because they're cool, naturally. (Yes, this flies in the face of
the JavaJavaJava slant mentioned in the article - must be some interesting
forces there to keep all of the Interns and College Grads from incessantly
advocating for whatever teaching language they used in school.)

------
rachelbythebay
"My experiences working with this committee were completely positive, but
there was often a two-month lag before I got an official reply from them." --
he's describing the situation where they own everything you do if it has
anything to do with them.

I have a pet hypothesis which is that these non-competes are strangling
innovation in the Valley (and beyond). I know I personally made sure to shut
off the "ideas" part of my brain until I was free and clear lest they try to
claim ownership of things I would later invent.

This "delay for long enough to kill it" thing happened to a friend of mine. I
wrote about it here: <http://rachelbythebay.com/w/2011/09/16/squashed/>

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

------
trimbo
"Coding standards and reviews prevented bad low-level decisions, but not bad
high-level ones"

This is true for coding standards and reviews everywhere. That's what _design_
standards are for -- i.e. some kind of process around specifying a technical
design.

