>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…
Software Engineering at Google
81–90 of 161 posts
Re: Software Engineering at Google
#82Although 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 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
#83Earlier 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 ?
Re: Software Engineering at Google
#84Earlier 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..
Re: Software Engineering at Google
#85Is 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…
Re: Software Engineering at Google
#86I 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.
Perfect! We need a t-shirt.
Re: Software Engineering at Google
#87> 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...
Re: Software Engineering at Google
#88> 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...
Re: Software Engineering at Google
#89Google 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
#90Earlier 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…
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.