Software Engineering at Google • Hacker News Board

Re: Software Engineering at Google

#61

Post by Bahamut » Sat, Feb 11, 2017, 12:07 PM UTC

throwawayGogEng wrote: post #48

jmillikin wrote: post #37

Earlier quoted context omitted.

Everything you posted is wrong, which makes me believe you know everything you posted is wrong. Nobody writes things that inaccurate by accident. For the benefit of YC, here are corrections: > 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 t…

Thanks for the info! > Piper has branches I've worked on two teams so far, neither of which used the branches you described. They opted to either flag off features or keep long-running CLs. However, I'll try to learn more about Piper branches. I doubt my team will make large workflow shifts, but it would still be good to understand! > CLs are equivalent to Git commits I'd argue that CLs are not equivalent to Git comm…

> Best practices in git are to have frequent, small commits.

I'd qualify that to only on a working branch - it's preferable to squash it all to 1 commit when merging upstream in order to make reverting painless if there is something wrong with the proposed change.

Lots of small commits cause massive pain with git :( .

Re: Software Engineering at Google

#62

Post by benzewdu » Sat, Feb 11, 2017, 12:08 PM UTC

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.

Re: Software Engineering at Google

#63

Post by Chasmo » Sat, Feb 11, 2017, 12:12 PM UTC

> 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

#64

Post by throwaway40483 » Sat, Feb 11, 2017, 12:34 PM UTC

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…

Even when 20% was in existence, it was (mockingly) called 120%. I will leave you to guess as to why.

Re: Software Engineering at Google

#65

Post by brown9-2 » Sat, Feb 11, 2017, 12:35 PM UTC

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

I am pretty sure that engineers there don't sync the entire repo to their workspace. Look up the talk that introduced Piper and Client in the Cloud (I think it was at the BUILD conference 1-2 years ago).

Re: Software Engineering at Google

#66

Post by Chyzwar » Sat, Feb 11, 2017, 12:37 PM UTC

arjie wrote: post #57

milesrout wrote: post #49

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…

One True Version force you to move whole company in the same pace. Even if you have legacy project you need to keep updating because your dependencies are moving. In the same time if you want to refactor or redesign API you need to wait for all your users and communicate changes since you cannot have beta/alpha release.

I am guessing that in Google people they try to avoid above issue by creating and then depreciating a lot of projects instead having new major release. Older projects will become frozen because too many things depends on them.

This is visible in Google products that take years to change in any way. Gmail/Search are basically the same as long I remember. Given number of engineers in Google it is hard to see any output.

Re: Software Engineering at Google

#67

Post by throwaway40483 » Sat, Feb 11, 2017, 12:37 PM UTC

hueving wrote: post #58

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…

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

Re: Software Engineering at Google

#68

Post by JeremyBanks » Sat, Feb 11, 2017, 1:15 PM UTC

throwawayGogEng wrote: post #48

jmillikin wrote: post #37

Earlier quoted context omitted.

Everything you posted is wrong, which makes me believe you know everything you posted is wrong. Nobody writes things that inaccurate by accident. For the benefit of YC, here are corrections: > 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 t…

Thanks for the info! > Piper has branches I've worked on two teams so far, neither of which used the branches you described. They opted to either flag off features or keep long-running CLs. However, I'll try to learn more about Piper branches. I doubt my team will make large workflow shifts, but it would still be good to understand! > CLs are equivalent to Git commits I'd argue that CLs are not equivalent to Git comm…

While Piper does technically have SVN-like branches, they're so unwieldy and poorly supported by lots of tooling (our team could never get TAP and our slightly-unusual testing to work on branches) that they're a much more niche tool than something like Git branches.

I agree with you with respect to CLs/snapshots. I would sometimes try chains of DIFFBASE-linked CLs in a crude emulation of linear Git branches (I want to experiment with taking things different ways, and I want the version control to store/back up my work), which sort-of worked when you're writing the code, but merging could be nasty. But there was also ad-hoc Git hosting available internally. I started using that for my experimenting, squashing into Piper commits when it was ready to share. It wasn't terrible, though still not optimal for collaboration.

Re: Software Engineering at Google

#69

Post by jeremyjh » Sat, Feb 11, 2017, 1:22 PM UTC

richsinn wrote: post #23

aanm1988 wrote: post #2

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.

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

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.

Re: Software Engineering at Google

#70

Post by mining » Sat, Feb 11, 2017, 1:28 PM UTC

Chasmo wrote: 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...

http://www.gwtproject.org/

Slightly tongue in cheek (since Google obviously uses javascript), but Java :)