
Software Engineering at Google - asnt
https://arxiv.org/abs/1702.01715
======
varelse
Not one word about what I consider the most toxic aspect of working at Google:
blind allocation.

Unless one absolutely does not care what one wishes to work on, joining Google
is throwing your future into the Hogwarts hat of an ill-defined cabal of
billionaires to pick your job at Google. Sometimes that works out, but most of
the time you are allocated to whatever mission-critical project is currently
leaking buttcheeks.

In my brief time there, I was placed on a 7-person team that lost one person
per month. That is the single worst retention rate I have ever seen. I left
after 4 months for that and the realization that the powers-that-be were in
denial about the coming impact of an emerging technology that they have since
embraced a year or so after my departure.

That said, the SCCS and the build process were top-notch.

But there are good reasons why despite all the perks and smart people,
Google's overall retention rate is barely a month longer than Amazon's.

[http://www.slate.com/blogs/business_insider/2013/07/28/turno...](http://www.slate.com/blogs/business_insider/2013/07/28/turnover_rates_by_company_how_amazon_google_and_others_stack_up.html)

~~~
fhoffa
Blind allocation?

When I joined Google I was given 4 teams in 2 different locations to choose. I
had lunch with each of the teams, and chose the one that better suited my
style.

To be fair, your experience at Google will depend a lot on what team you land
in. Not everyone's given a choice, but now I know better: Talk to your
recruiter and make them clear what you want.

~~~
varelse
Sure, that would be great, but as a result of leaving, I have been blacklisted
by HR from ever returning. And the one guy that tried to bring me back in a
year ago met in the lobby of his building and then walked me out to the marsh
behind the GooglePlex before saying a word to me.

I then asked if I could use said technology for which I am a recognized
expert, he said no, and that was the end of that.

I have been tempted to print myself a "Bad Cultural Fit - Google HR" T-shirt
in response, but I have better things to do.

~~~
amscanne
People aren't blacklisted for leaving, that's blatantly false. Your story is
obviously missing some key elements.

Median tenure does not necessarily indicate retention issues for core roles at
any company. It could simply be rapid growth or lots of roles that typically
come with high turnover (e.g Amazon's warehouse employees).

~~~
nostrademons
You get classified as "regretted" or "non-regretted" attrition. If you're
"regretted", you can come back anytime within I think 2 years without
interviewing, or with favorable interview afterwards. If you're "non-
regretted", it can become very difficult to come back unless you have a really
strong recommendation from some other manager within Google, or come in
through a company they acquire. They already have data on your job performance
that's a lot more reliable than an interview, and if it's negative, it'll take
a lot to overcome that.

~~~
varelse
That sounds right. I was on a team leaking personnel managed by a manager who
clearly wanted to be doing other things with his other team and who forgot I
existed for the 3 out of the 4 months I was there until I reminded him I
existed whereupon I was told I was failing to meet his expectations.

Upon complaining that it was unfair to judge me behind the curve when there
had been zero feedback whatsoever up to that point, he then reported me to HR
and offered to let me leave the team. There were two other potential teams
making use of the technology for which I have expertise: one was new and it
had zero openings at the time but which is now arguably one of the most
prominent teams at Google and the other one's manager asked me one question
"Where did you get your degree?" and didn't like my answer (I suspect) because
it wasn't Stanford (desirable attributes for the position listed a Stanford
degree) but I don't know for sure because he cut off communication at that
point

And yes, in a perfect world I should have reminded my manager sooner of my
existence but he was off on paternity leave as well with no one to run things
in his absence so I really don't know the winning move here other than what I
did: leave for one of Google's competitors where I spent the next 4.5 years or
so focusing exclusively on the aforementioned technology.

If Google HR is dismissing the AUC of my entire career over 4 blind-allocated
months at Google, that's asinine, but it would explain a lot and fit the
facts. Thanks for the info.

------
hueving
>Engineers are permitted to spend up to 20% of their time working on any
project of their choice, without needing approval from their manager or anyone
else.

From what I understand talking to current employees, this is now bullshit. You
_could_ spend 20% on other stuff, but the culture in many of the groups is
such that you are putting your peer review at risk by doing so because of your
reduced output.

Any current Googlers that spend 1 day of every week working on something
completely unrelated to their main job want to comment?

~~~
Itaxpica
This (like a lot of things at Google) varies wildly across PA and even among
managers within a PA. All my managers so far have been extremely supportive of
20% time, and I've personally worked on three different 20% projects over my
last four years (including two which have been open-sourced). That being said
my engagement model has generally been less "one solid day a week" and more "a
few days in a row once a month or two" in quieter times for my 80% gig, or "an
hour or two every day" in busier ones.

My understanding is that while I'm a little bit of an outlier, in general 20%
time at Google is nowhere near as dead as people on the internet tend to claim
(at least for engineers).

~~~
pyb
What is a PA ?

~~~
Itaxpica
Product Area (so Ads, Cloud, Search, etc).

------
benzewdu
_Although there is a well-defined process for launch approvals, Google does
not have a well-defined process for project approval or cancellation. Despite
having been at Google for nearly 10 years, and now having become a manager
myself, I still don’t fully understand how such decisions are made._

The reason why I quit Google.

~~~
kyrra
The rest of the paragraph you quote is fairly important as it goes on to
explain cases and how a project can be cancelled.

The rest of the quote:

 _In part this is because the approach to this is not uniform across the
company. Managers at every level are responsible and accountable for what
projects their teams work on, and exercise their discretion as they see fit.
In some cases, this means that such decisions are made in a quite bottom-up
fashion, with engineers being given freedom to choose which projects to work
on, within their team’s scope. In other cases, such decisions are made in a
much more top-down fashion, with executives or managers making decisions about
which projects will go ahead, which will get additional resources, and which
will get cancelled._

~~~
benzewdu
The question isn't how, it's why. I wish i could share the details.

------
__strisk
Is the practice of shoving all disparate pieces of proprietary software (or
individual projects) in the same repo a common occurrence? I have found that
pulling unrelated changes just so that I can push my changes is an
inconvenience. Furthermore, tracking the history of a particular project is
confounded due to unrelated commits. I am sure that their vcs (piper?) makes
this a feasible task, but for git, it seems like it would suck.

The article posted by kyrra, mentions this.

 _Given the value gained from the existing tools Google has built and the many
advantages of the monolithic codebase structure, it is clear that moving to
more and smaller repositories would not make sense for Google 's main
repository. The alternative of moving to Git or any other DVCS that would
require repository splitting is not compelling for Google._

It seems like they have just too much invested in this "shove it in the same
repo" style. Or is this the more appropriate way to do things in a large
organization?

~~~
throwawayGogEng
Coming from companies that use reasonably-sized git repos, I absolutely
_hated_ Google's VCS.

Here's some of my painpoints with it:

* _No branches._ If you want to make a temporary code branch, you create a CL (Google's version of a pull request), but never submit it. This means nobody else can collaborate on it with you, and it must be manually updated to HEAD.

* _No CL collaboration._ Unlike Git branches, CLs can only contain changes from one user.

* _No stable branch._ Since everything is essentially on one long branch, it's a real hassle when a project is broken at HEAD. Sure, integration tests should ideally prevent this. In practice, HEAD is often broken. Teams have created bash scripts and mailing lists to determine 'stable' old versions that can be checked out for development.

* _Single versions of libraries._ Any library that is used is also checked into the VCS. However, only one version of the library can exist in the codebase, which is rarely updated. However, there are exceptions to this.

At one point, Sergey mentioned bringing Google "up to industry standards"
regarding VCS's. However, that would be a monumental task and I doubt it will
happen.

~~~
mikekchar
It's interesting. This is exactly how it's worked at every large company I've
been at. You have these enormous source trees that are essentially
unbranchable. Then you have load build teams that build the latest checked in
version. When you want to do anything that uses a component you aren't working
on, you grab the built version and use it locally. They you hope like crazy
that any changes you make don't break any downstream users (who are
integrating with yesterday's build). If the build breaks (which happens
frequently), then people use builds from 1, 2, or 3 days ago, leading to
inevitable "integration hell".

Although I seriously doubt that Google has this problem, one of the biggest
drawbacks of the scheme is that nobody knows how to build anything -- not even
their own project. If you are coordinating with another project, then you're
always having to wait days for the load build to finish so you can get their
changes. If the build breaks for an unrelated reason, you can lose a whole
week of development to screwing around.

When working in that kind of environment, I tend to maintain my own VCS, then
squash my commits when integrating with the main VCS. I also do all my own
load build. Everywhere I've worked, I've been heavily criticised (usually by
management) for doing this, but productivity has been on my side, so people
reluctantly accept it. I often find it strange how so many people prefer doing
it the other way...

~~~
throwawayGogEng
> If the build breaks for an unrelated reason, you can lose a whole week of
> development to screwing around.

This happens often on some projects at Google (although 2 days is the longest
I've seen it broken). Others have told me they use this time for documenting
code and writing design-documents.

> When working in that kind of environment, I tend to maintain my own VCS,
> then squash my commits when integrating with the main VCS.

Google actually has a tool that allows developers to use Git on their local
machine, which is squashed into a CL when pushed. However, some projects are
too reliant on the old system for this to work.

------
NumberSix
Google is highly non-representative of businesses and technology businesses in
particular. It has a near monopoly on the search business and has enormous
amounts of money from a single source -- advertising.

Google Fiscal Year 2015

Revenues: $74.54 Billion (source: Google) Advertising Revenue: $67.39 Billion
(source: [https://www.statista.com/statistics/266249/advertising-
reven...](https://www.statista.com/statistics/266249/advertising-revenue-of-
google/)) Profits: $23.4 Billion

Market Capitalization: $570 Billion

Google Not a Startup/Has Not Been a Startup for Many Years

Founded: September 4, 1998 (19 years ago) IPO: August 19, 2004 (13 years ago)

Number of Employees (2015): 57,100 Revenues per Employee: $1.3 Million Profits
per Employee: $409,000

The issue is that Google has so much money and is so successful that it can do
all sorts of things that are extremely inefficient, even very harmful and
still do fine, unlike smaller companies or startups in particular.

For example the arxiv article states:

 _2.11. Frequent rewrites_

 _Most software at Google gets rewritten every few years._

 _This may seem incredibly costly. Indeed, it does consume a large fraction of
Google’s resources._

Google has the money to do this. As the article argues, it may work for
Google. On the other hand, Google has so much money and such a dominant market
position, it probably can keep succeeding even if continual code rewriting is
actively harmful to Google.

In orthodox software engineering _theory_ , competent software engineers, let
alone the best of the best that Google claims to hire, should write modular
highly reusable code that does not need to be rewritten.

Many rewrites and "refactorings" are justified by claiming the "legacy" code
is "bad code" that is not reusable and must be written by "real software
engineers" to be reusable/maintainable/scalable etc. One rewrite ought then to
be enough.

Even highly successful businesses, for example $1 Billion dollars in revenues
with $50 million in profits and 5000 employees (revenues per employee of
$200,000), have nowhere near these vast resources --- either in total dollars
or per employee or product unit shipped. Blindly copying highly expensive
software development processes from Google or other super-unicorn companies
like Apple or Facebook is likely a prescription for failure.

~~~
cookiecaper
>Blindly copying highly expensive software development processes from Google
or other super-unicorn companies like Apple or Facebook is likely a
prescription for failure.

Yes, this can't be stressed enough. Out here with the little people like non-
Google-employed me, there's almost a desperation to copy the things that
Google and Facebook do, and it's often justified with "Well, Google, Facebook,
or Netflix use it!"

A _huge_ amount of tech fads over the last decade have been the direct result
of Google's publications and public discussions. Google might need BigTable,
but that doesn't mean we should all bury our SQL RDBMS and use a crappy open-
source knockoff "based on the BigTable paper". More than likely, Google
would've been happy to _keep_ a SQL RDBMS.

Google has the engineering staff, including two extremely technical founder-
CxOs with PhDs on which Google's initial technology was based, and the
hundreds of millions of dollars necessary to do things The Google Way. They
can rewrite everything that's slightly inconvenient and do a lot of cutting-
edge theoretical work. They have the star power and the raw cash to hire the
people who invented the C language back in the 70s and ask them to make a
next-gen C on their behalf.

Google has the technical and financial resources to back this type of stuff
up, provide redundancy, put out fires, and ensure a robust deployment that
meets their needs. They keep the authors of these systems on-staff so they can
implement any necessary changes ASAP. In many cases, Google is operating at a
truly unprecedented scale and existing technologies don't work well, so that
theoretical cutting-edge is _necessary_ for them.

None of those things are going to be true for any normal company, even other
large public ones. Google's solutions are not necessarily going to meet _your_
needs. Their solutions are not necessarily even good at meeting their own
needs. Stop copying them!

I'm _so. sick._ of sitting through meetings that have barely-passable devs
making silly conjectures about something they heard Google/Facebook are doing
or that they read about on a random hyper-inflated unicorn's engineering blog.

You want your stack? OK, here it is: a reasonably flexible, somewhat
established server-side language (usually Java, .NET, Python, Ruby, or PHP;
special applications may need a language that better targets their specific
niche, like Erlang), a caching layer (Redis or Memcached) that's actually used
as cache, NOT a datastore, a mainstream SQL database with semi-reasonable
schemas and good performance tuning, and a few instances of each running
behind a load balancer. That's it, all done. No graph databases, no MongoDB,
no quadruple-multi-layered-massively-scalable-Cassandra-or-Riak-clusters, no
"blockchain integration", no super-distributed AMQP exchanges, _ABSOLUTELY NO_
Kubernetes or Docker (use Ansible), none of that stuff.

Just sit down and get something done instead of wasting millions of your
employers' dollars trying to make yourself feel important. If you _do_ need an
AMQP exchage, bolt it on after the fact to address the specific issue at hand,
once you know why you need it, and make sure you know what you're doing before
you put it in production (it's apparently difficult to grasp that AMQP servers
are NOT data stores and that you can't just write directly to them and wait
for some worker to pick it up if you care about data integrity).

Don't start a project with the primary intention of making a convoluted mess;
let it get that way on its own. ;)

~~~
annnnd
While I agree with the spirit of your post, I think you are taking the
argument too far in places. For instance, we are a small team of devs and
Docker solved a real problem for us. Our deployment was once on bare OS and it
was a nightmare. Different distributions, different library versions (with
their own sets of bugs)... Unfortunately we couldn't demand a specific
environment from our customers and at the same time it drained our resources
trying to accommodate all installation variants. When Docker came out we tried
it out, saw that it solves all these issues beautifully and never looked back.
But we use it only because it insulates our installation from Linux (apart
from the kernel that is), not because it is _hip_.

More general advice is: take G, A, FB, NF... papers (and HN posts, while we
are at it ;) ) with a grain of salt, test before use and make sure it solves
more problems than it creates - for _you_.

~~~
cookiecaper
Yeah, I don't mean it to be an all-encompassing prohibition. It's just
important that people start with the basics and complicate their software with
esoteric solutions only as a matter of necessity. This also ensures that the
engineers understand the functionality that the esoteric solution needs to
provide instead of making grossly incorrect assumptions and misuses that lead
to major disasters (e.g., treating AMQP servers as a data store; a client lost
data _last week_ due to this silly assumption).

------
hueving
Google has gotten so large so quickly in the past 3 years, that I wonder how
much damage has been done to their engineering culture. A lot of "less than
stellar people" have joined in these recent years according to several of my
friends that work there (in infrastructure and some ML groups).

It seems the push to golang is entirely to sustain large projects with average
engineers. Maybe somewhere high up they decided that it's better to just have
a massive engineering workforce rather than only hiring top talent? At what
point does brain drain start as the best people get sick of dealing with
mediocrity?

~~~
jboggan
I've only been there 13 months but I've found the quality of previous and new
hires are ridiculously high. Given the number of talented people applying
every day I think Google could increase hiring by 100% with no appreciable
drop in quality.

Google has a lot of imperfections addressed elsewhere in the comments here but
the engineering culture is extremely strong and one of the best parts about
being there. I think the overall "Googley culture" is suffering but it isn't
for technical reasons.

Then again maybe I'm one of those C players who snuck in the past year.

~~~
hueving
>I've only been there 13 months but I've found the quality of previous and new
hires are ridiculously high.

Seek out the people that were there 6+ years ago and compare their quality
with the average Googler. You'll likely notice a difference.

Google now has over 50,000 employees. It's not possible to get that big that
quickly without a reduction in hiring rigor. There wasn't a sudden influx of
geniuses to fill that demand.

~~~
jboggan
They're pretty much the same raw talent, just with 6+ extra years of
navigating the Goog and collecting all the arcana that makes you an effective
engineer there. Of all of the complaints I have heard from older and newer
Googlers, not a single one (in person or on Memegen) has ever complained about
a drop in engineer quality. If anything it is a continuing frustration over
how high the hiring bar continues to be and how we can't get referral bonuses
for any of our friends.

------
Upvoter33
So much snark and negativity on this thread, when the paper is just a factual
description of a pretty impressive feat of software engineering (still way
better than most companies I have seen the inside of).

~~~
varelse
I really like the first part of the paper and it describes a lot of their best
practices, but the last 1/3 or so of the paper is more about Google's culture,
no? IMO that opens them up for the snark here.

Google has some amazing perks and it's a wonderful overall employer, but I
really wonder how much cash is left on the table by not addressing its
shockingly low retention rate or at least explaining why it's not a problem.

There are a lot of articles estimating the cost of a departure is anywhere
from 6-12 months of the lost employee's salary. Does that seem like something
that should be ignored like they seemingly do? Why do shareholders even
tolerate this?

~~~
Upvoter33
Fair point - I was mostly focused on the build system. It is quite something
and a marvel of engineering. The culture is actually good in parts of the
company -- like core systems infra -- but yes it is hard to spread that
throughout, it seems. A separate article about culture and what's good and bad
would be interesting, but probably not likely to be seen in public,
particularly if it's honest...

------
dj-wonk
I read most of the paper. For the most part, it struck a nice tone as being
mostly descriptive and not too promotional. However, the final paragraph in
the conclusion section differs:

> "For those in other organizations who are advocating for the use of a
> particular practice that happens to be described in this paper, perhaps it
> will help to say “it’s good enough for Google”.

In my opinion, this style of writing doesn't fit nor belong.

I would leave that paragraph out. Instead, let's judge on the merits and
applicability of an engineering practice based on thinking, reasoning, and
experimentation.

That said, as I've read various comments about Google's processes, I'm struck
by the cognitive dissonance. On one hand, I see bandwagoning; e.g. "monolithic
source control is nuts; we don't do that; no one I know does that". There is
also some appeal to authority; e.g. "well, Google is the best, they do X, so
we should too." I'm glad to see different argumentation fallacies colliding
here.

~~~
benashford
With one-or-two exceptions, what the paper describes is very familiar and
sounds like most software teams, but most teams don't achieve Google-like
performance/stability/success.

The differentiation is in details that the paper doesn't explore.

I agree, this paper will just lead to more monolithic Git repos "because it's
good enough for Google", without the appreciation of Google's other tooling
and processes.

------
jondubois
The single-repo is quite surprising. How do they manage to store that much
data in a central place? I guess they're using some sort of distributed
network file system - This seems overly complex though. It would be
interesting to know if this was intentional (if there is a reason for this) or
things just evolved like this out of habit.

I think that engineers in most large software companies don't actually
accomplish much on a day-to-day basis. I'm saying this after having worked in
both corporations and startups. Large companies are laughably inefficient -
Engineers tend to focus all of their energy on very narrow (often tedious)
problems at great depth.

These huge companies never try to reign-in the complexity because they don't
really need to - Soon enough, the employees at these companies get used to the
enormous complexity and start thinking that it's normal - And when they switch
jobs to a different company; they contaminate other companies with that
attitude. That's why I think startups will always have an advantage over
corporations when it comes to productivity.

In these big companies, the most clever, complex solutions tend to win.

~~~
kyrra
See my reply elsewhere in this post to the ACM article. It's custom in-house
based on their own distributed databases. The front-end UI is based on
perforce, but there is a Git front-end (but logically it behaves a lot like
perforce).

As the ACM paper calls out, files are loaded asynchronously like on access, so
you only have the files you need on your desktop. From a developer's point of
view, you can see all the files in the entire repo at all times. And with how
CITC (client in the cloud) works, I can move from a laptop to a desktop
without any effort (all of the files I have in a working state on one are
immediately available everywhere I can access CITC).

As far as complexity... how would a large company solve these problems without
these large and complex systems? Google is probably one of the more efficient
ways I've seen large companies work. When you want all your devs to share
code, thing get hard at scale.

------
anonsockpuppet
> hunger is never a reason to leave

But good luck finding a free restroom at 10am. Is this an issue at other
companies?

~~~
menssen
Nobody drives in New York because the traffic is so bad.

------
mlinksva
"Most software at Google gets rewritten every few years" at incredible
expense. That sounds crazy, but the article claims it has benefits including
keeping up with product requirements, eliminating complexity, and transferring
ownership. Would be interesting to see some kind of metric indicating how much
of an outlier Google really is here, and what measures it takes to make sure
rewrites aren't worse (second system).

------
OneMoreGoogle
I spent ~18 months at Google, and one of the annoying aspects was the
diversity of build systems. I built with Ninja, emerge, Blaze, and Android's
Rube-Goldberg-shell-script system.

~~~
762236
> Android's Rube-Goldberg-shell-script system

Perfect! We need a t-shirt.

------
Chasmo
> Software engineers at Google are strongly encouraged to program in one of
> four officially-approved programming languages at Google: C++, Java, Python,
> or Go​.

I wonder which of these languages they use to develop the google front page or
any other frontend when no Javascript is allowed...

~~~
Itaxpica
Those are the primary, general four languages, but other languages are used as
necessary for specific domains (e.g. Javascript, Objective-C/Swift), they're
just not guaranteed to get the same level of internal tooling and
infrastructure support (though in practice they do).

------
Matthias247
Interesting, compared to what's common in the automotive industry it doesn't
even mention the terms "requirements", "specifications", "estimations",
"project plan", "tracability", "UML", etc...

~~~
hueving
Right, if it mentioned those, search would still be the version we saw in
2007. None of the other products would exist yet because they would still be
conducting user studies based on wire frame mock ups of workflows designed by
committees of behavioral psychologists.

That's a bit dramatic, but when your product development has a fast turnaround
for fixes (git push vs 100 million dollar recall) and it won't kill people
when it breaks, you should immediately throw most of that process shit out the
window.

You can't be competitive in consumer SaaS if you get bogged down in 'real
engineering' processes.

~~~
nickpsecurity
A clear statement of what you're going to do, some constraints on the design a
la Design-by-Contract, and languages/libraries that mitigate errors by design
are so easy to do that small shops do them on a regular basis. Ada/SPARK,
Eiffel, Ocaml, and Haskell are examples with steady business in industry with
last three used on relatively-fast-moving projects. Add in static analysis,
spec-based generation of tests, and/or fuzzers to get lots of reliability for
free. Guess what? This method also scales excellently if the company has
access to a huge pile of servers and engineers whose build system can automate
all the checks with every submitted change.

Your idea that it has to be as ridiculous as process junkies is a strawman. A
strawman that happens in a lot of places for sure but doesn't have to. Google
can just take the few, easy-to-apply practices from high-integrity systems to
get tons of benefit. It's the 80/20 rule for increasing assurance.

~~~
hueving
All of the processes you just described are antithetical to the processes I
was referring to. Writing URL, design specs, etc is not the same thing is
automated test generation, static analysis, and an API contract agreement. The
thing you just described is exactly what I'm saying replaces all of the "on
paper" crap that was taught as "software engineering" in schools as short as 4
years ago.

~~~
losalamosal
Or 40 years ago! I'm no fan of "process", but if you don't at least write down
what you're trying to do (requirements) and some metrics for judging success,
you open yourself up to two equally troublesome outcomes (depending on who's
doing the evaluating): it's all a success or everything's a failure. Well
written requirements and metrics (even brief ones) remove some of this
evaluation ambiguity.

------
mck-
A lot of the things they had to build in-house for repo/build/test/deploy as
described in chapter two, all of us are fortunate enough to get for (almost)
free with all the tools these days.

It's a good time to be a founder :)

------
wmu
Things I'm envy for: 1) documenting changes, 2) compulsory code review, 3)
post-failure reports. I wish my company introduced at least one of those.

------
l1feh4ck
>>Engineers are permitte d to spend up to 20% of their time working on any
project of their choice, without needing approval from their manager or anyone
else.

Can someone tell more about what they did and the things are that permitted
(even though without needing approval.

~~~
wutbrodo
It's all kinda of things: I did mine on another team I was thinking of
transferring to (as a sort of pilot program), a friend of mine in ads worked
on a cloud robotics team (this was like 5 years ago), another friend spent
some time on a research team for the stuff he had done his thesis on, etc

------
harryjo
Is section 3.1 "20%" time still true?

~~~
mamon
You guys seem to think that Google is benevolent by giving engineers that 20%,
while in fact they do that for very selfish reasons: it is all about
copyrights.

They hire the smartest Software Engineers in the world, so it is only a matter
of time that some of them will create new, disruptive product.

If they weren't given that 20% of time at Google they would do that anyway, on
weekends, but since they do it in company-sponsored time then Google owns the
copyrights to all of their work.

~~~
hiddencost
Companies own your work even if you do it off the clock, in many cases.

~~~
aioprisan
That's not the case in most states, like California, New York and
Massachusetts, due to state laws.

~~~
hak8or
What new York state law prohibits this? My contract says that as a salaried
employee I work at the company for 23:59 hours Monday to saturday, so it's
only Sunday that's off the clock.

And from what I understood, all inventions they own, but I am still very iffy
on what's qualified as an invention.

A coworker even asked for bosses blessing to sell some stuff on the side
unrelated to the company, he said no because as per the contract that wouldn't
let coworker give full undivided attention to the company.

------
supremesaboteur
> The maintenance of operational systems is done by software engineering
> teams, rather than traditional sysadmin types, but the hiring requirements
> for software engineering skills for the SRE are slightly lower than the
> requirements for the Software Engineering position.

but from

[https://www.youtube.com/watch?v=H4vMcD7zKM0&feature=youtu.be...](https://www.youtube.com/watch?v=H4vMcD7zKM0&feature=youtu.be&t=424)

"All of SREs have to pass a full software interview to get hired"

~~~
jmillikin
I'm an SRE. Both the OP article and the YouTube video are making
generalizations that aren't really accurate.

There's two positions called "SREs", SRE-SWE and SRE-SA. SRE-SWE has to pass a
full software interview, and are equivalent to SWEs working for other
departments. SRE-SA are not expected to have Google-level software engineering
skills, but make up for that in other knowledge areas.

------
fenollp
> has released over 500,000 lines of open-source code

Interesting metric. I wonder why no "social" VCSs report that metric?

------
sjakobi
Why aren't OKR scores used as an input to performance appraisals?

~~~
bskap
Because they aren't measures of how good you are at developing, testing, and
releasing software, they're just measures of how good you are at estimating
the amount of work it'll take to complete a project 3 months in advance.

------
aanm1988
They have a billion files in their repo, 9 million are source files.

What the heck is the other 991000000?

I skimmed this. Mostly just stuff any competent company would/should be doing.
it's google though, so they act like it's super awesome.

~~~
richsinn
> Mostly just stuff any competent company would/should be doing. it's google
> though, so they act like it's super awesome.

Yes, you're absolutely correct. But here's the thing - it was actually Google
that pioneered many of this. Many of the big/competent companies that are
following these practices are because of Google's "DNA" leaking into those
companies (via former employees bringing along the best practices learned at
Google, etc.)

~~~
jeremyjh
They may have done a better job instituting these practices across a large
organization, and some of their tools have very useful and novel features, but
I very much doubt there is a single practice that they actually invented. If
you think there is one, please be specific. I think what Google contributed is
evidence that these practices can be instituted at scale, which really was
sorely lacking in some cases. This helped the industry disseminate them.

~~~
richsinn
Of course it's hard to say if they completely, 100% invented anything from
scratch. But they sure did "pioneer" a lot of unique practices that other
software companies were not following at the time.

A specific example - the practice of keeping the entire codebase at the
company under a single "source" repo. Pre-Google - it would've been considered
outrageous to have the entire codebase of a sophisticated software company
keep their entire software contents under a single repo. But Google did it,
and other companies have followed suit successfully (as Google DNA has leaked
to other companies).

Yes, of course keeping code in a single repo is not a "new invention". Linux
is a single repo; many smaller companies have only a single repo because their
only product is a single web app. Google keeps nearly 100% of their entire
codebase in a single repo - and that was definitely a novel approach at the
time.

