Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software Engineering at Google

arxiv.org

Post reply on HN
Print view View original

111–120 of 161 posts

Re: Software Engineering at Google

#111

Post by varelse »

findateamfirst wrote: post #108
varelse wrote: post #96

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

I didn't even apply until finding a team I was really excited about. I had coffee with a couple TPMs and managers, found the right group, applied, and have been really happy. The median tenure of the folks I work with is 5 years, and so far it's been great.

Google is awesome if you can avoid the allocation problem, I agree. I was not given such options.

Re: Software Engineering at Google

#112

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

Re: Software Engineering at Google

#113

Post by kyrra »

jondubois wrote: post #112

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…

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.

Re: Software Engineering at Google

#114

Post by jmillikin »

supremesaboteur wrote: post #91

> 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... "All of SREs have to pass a full software interview to get hired"

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.

Re: Software Engineering at Google

#115

Post by qu1j0t3 »

wingless wrote: post #95
benzewdu wrote: post #62

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.

And on the other end of the spectrum we had Jobs era Apple, with One True God overseeing all demigods who oversee projects. IMO the things that made Apple products so successful was this structure which left no room for confusion and that the company was run by QA people. My impression of Jobs is that he was a QA guy himself.

Jobs was notoriously a capricious micromanager at NeXT; see e.g. "The NeXT Big Thing", Randall Stross.

Thanks to the secrecy that shrouds everything Apple, it's hard to get a handle on whether he became a more evolved manager (or, let's not euphemise: less of a flaming asshole) later on at Apple.

Re: Software Engineering at Google

#116

Post by delroth »

hueving wrote: 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 spend 10-20% of my time at Google (depending on the needs) developing and maintaining an internal tool that is used by 100-1000 engineers across 10-100 teams (not including my current team). Not only have my last 3 managers been extremely supportive of this, I've netted a few peer bonuses from this, and some nice feedback from senior people that appreciated my work.

The "approval from my manager" amounted to telling them in our weekly 1:1 meeting that I wanted to spend my 20% time on that project.

Of course, if you spend 20% of your time working alone on something that produces 0 results in the span of several quarters, I suspect your experience is not going to be the same.

Re: Software Engineering at Google

#117

Post by Upvoter33 »

varelse wrote: post #102
Upvoter33 wrote: post #100

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

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

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

Re: Software Engineering at Google

#118

Post by namelezz »

varelse wrote: post #111
findateamfirst wrote: post #108

Earlier quoted context omitted.

I didn't even apply until finding a team I was really excited about. I had coffee with a couple TPMs and managers, found the right group, applied, and have been really happy. The median tenure of the folks I work with is 5 years, and so far it's been great.

Google is awesome if you can avoid the allocation problem, I agree. I was not given such options.

Could not you switch team while you were at Google?

Re: Software Engineering at Google

#119

Post by hak8or »

aioprisan wrote: post #94
hiddencost wrote: post #85

Earlier quoted context omitted.

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

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

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.

Re: Software Engineering at Google

#120

Post by tehlike »

throwawayGogEng wrote: post #35
__strisk wrote: post #29

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

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…

Git5 bridge exists, though it is not supported.

Single version of a library is actually a good decision, makes sub libraries pulling different version of the same code managable and error free.

Not to mention security auditd and ease of maintenance.

Disclaimer: goog emp

Post reply on HN