Live data from Hacker News

Software Engineering at Google

arxiv.org

81–90 of 161 posts

Re: Software Engineering at Google

#81
post #60

>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 Goo…

I'm not currently, but I was doing that for the last couple years with no ill consequences. I'm only not doing that now because I don't have a 20% idea that's particularly exciting to me.

Re: Software Engineering at Google

#82

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.

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.

Re: Software Engineering at Google

#83
post #74

Earlier quoted context omitted.

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 co…

I've heard Google's VCS is basically their own reimplementation of Perforce. Are there any major differences ?

Other than "works at Google scale?" That not a dig at Perforce, it scales well but not to the absurd scale Google dials it up to. That is the major feature that drives any differences.

Re: Software Engineering at Google

#84
post #78

Earlier quoted context omitted.

As some point you have to hire someone to take out the trash. They can't all be Einsteins.

Funnily when I got to visit the Google office in London people just left their trash on the floor of the cafeteria for the cleaners..

I think his comment was mostly figurative.

Re: Software Engineering at Google

#85
post #55
post #15

Is section 3.1 "20%" time still true?

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 compa…

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

Re: Software Engineering at Google

#87
post #63

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

Clearly there is some use of Dart and JavaScript (vanilla, Angular and Polymer). It would be interesting to hear percentages across Google development.

Re: Software Engineering at Google

#88
post #63

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

That's actually an error in the paper -- JavaScript is now an officially approved programming language at Google.

Re: Software Engineering at Google

#89
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...) 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.

Re: Software Engineering at Google

#90
post #57

Earlier quoted context omitted.

No, it's not common. It's something that a couple of big companies have done, and while it might work for them it does NOT work for most people. It's a really, really bad way of doing development.

Why is it so bad? It seems incredibly effective for them and there are very good outcomes: • no trailing dependencies so you never have to backport fixes, maintain multiple released versions, etc. • extensive integration testing of libraries since they go live instantly • forced library developer and library user collaboration • deployed code is not out of date What's the problem with only One True Version? All the c…

Because smaller shops want the benefit of monorepo without paying the cost/discipline it requires. Mono repos without excellent unit tests and integration tests, review processes and various tools, is a disaster. And, in fairness to Google and Facebook, when they talk about the benefits of monorepo, they always mention these costs (it just gets ignored by people: Headline Driven Development)

And I'm sure that the number of companies doing really good integration tests in somewhere in the 1/10000 range (or worse). Every dependency, external provider, internal API, data store, taking into account versioning....it's hard.

I'm a huge believer in automated testing, I've written about it and done it for almost two decades now. My views on it have continuously evolved...and comprehensive and effective integration testing is still a complete mystery to me. The only reason I'd want to work at BigTechCo would be to learn about that specific aspect of software development.

Post reply on HN