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

Software Engineering at Google (2017)

arxiv.org

Post reply on HN
Print view View original

41–50 of 319 posts

Re: Software Engineering at Google (2017)

#41

Post by scarface74 »

MeteorMarc wrote: post #2

"Individuals and teams at Google are required to explicitly document their goals and to assess their progress towards these goals" This seems attractive for other large organizations. Any positive or negative experiences from readers?

My experience is that the difference in raises between an employee that got an “Exceeds Expectations” and one that “Meets Expectations” isn’t significant enough to be worth wasting the time worrying about it.

The best way to make more money is to change jobs. Google may be different.

Re: Software Engineering at Google (2017)

#42

Post by hknd »

raverbashing wrote: post #29
philosopher1234 wrote: post #24

Earlier quoted context omitted.

Or, don’t branch. Is branching so essential?

If you don't want to be stuck while a colleague does changes that conflict with what you're changing then yes, you need branching.

You don't need branching for this.

If 2+ people are working on the same file which might result into a conflict, you can either: - handle the conflict as soon as you merge your branches somewhen in the future or - handle it when trying to commit your change to head

Only difference is whether you handle the conflict now, or in the future.

Re: Software Engineering at Google (2017)

#43

Post by aaaaaaaaaab »

MeteorMarc wrote: post #2

"Individuals and teams at Google are required to explicitly document their goals and to assess their progress towards these goals" This seems attractive for other large organizations. Any positive or negative experiences from readers?

Ah yes! It's not enough if you're great at your job, or even if you do other people's jobs...

Instead you have to have this checklist of your quarterly goals, on which you can go through with your engineering manager on biweekly 1-on-1 meetings! And of course you should make a nice spreadsheet and a confluence page documenting your progress, since we're data driven :)

Did you fix a major fuckup in some legacy component? Where are the numbers? Ah, then it's not visible enough for a promotion, here's your 1% raise instead. Do you see Paul over there? He made great progress this quarter! One of his goals was to write a blogpost each week, and guess what, he did! He's on a great growth trajectory, and well deserves his promotion.

Long story short: it's a great way to drive away your best talent while keeping the confluence page and blogpost writers.

Re: Software Engineering at Google (2017)

#44

Post by tieze »

weinzierl wrote: post #11

What I don't understand is how they accomplish larger collaborative changes. The paper says: "Almost all development occurs at the 'head' of the repository, not on branches." Googler Rachel Potvin made an even stronger statement in her presentation about "The Motivation for a Monolithic Codebase" [1]: "Branching for development at Google is exceedingly rare [..]" In the related ACM paper she published with Josh Leven…

It might be a practical thing. I've heard from a Googler (a couple of years back) that getting changes in can take ages, and by the time the change lands, there's a good chance that there are merge conflicts, and the cycle starts over. Branches would make this even more painful.

Re: Software Engineering at Google (2017)

#45

Post by majikandy »

weinzierl wrote: post #40
_cs2017_ wrote: post #20

Earlier quoted context omitted.

Can you clarify why branching helps collaboration? In other words, why is it harder to commit to trunk when you have several developers working on a feature?

Branching enables me to share unfinished work with my collaborators. Sometimes I don't want to commit to trunk yet but still share code and collaborate on a part of the code base.

Make the changes smaller and more valuable and do it on trunk.

Re: Software Engineering at Google (2017)

#46

Post by weinzierl »

afpx wrote: post #23
weinzierl wrote: post #11

What I don't understand is how they accomplish larger collaborative changes. The paper says: "Almost all development occurs at the 'head' of the repository, not on branches." Googler Rachel Potvin made an even stronger statement in her presentation about "The Motivation for a Monolithic Codebase" [1]: "Branching for development at Google is exceedingly rare [..]" In the related ACM paper she published with Josh Leven…

I found this for you: https://trunkbaseddevelopment.com/ I only scanned through it, but it seems similar to the de facto way of doing things before distributed version control systems became popular (in the late 2000s?).

I know about this and it doesn't answer my question. This was in part my motivation to post this question here.

Re: Software Engineering at Google (2017)

#47

Post by weinzierl »

wahnfrieden wrote: post #22
weinzierl wrote: post #11

What I don't understand is how they accomplish larger collaborative changes. The paper says: "Almost all development occurs at the 'head' of the repository, not on branches." Googler Rachel Potvin made an even stronger statement in her presentation about "The Motivation for a Monolithic Codebase" [1]: "Branching for development at Google is exceedingly rare [..]" In the related ACM paper she published with Josh Leven…

There’s a wealth of reading available to you if you look up “trunk-based development” as a keyword. Likewise with “continuous integration” (the actual practice, not the build tooling). Jez Humble for instance has written extensively on this.

I know about this but haven't found an answer to my question. This was in part my motivation to post this question here.

Re: Software Engineering at Google (2017)

#48

Post by hknd »

weinzierl wrote: post #40
_cs2017_ wrote: post #20

Earlier quoted context omitted.

Can you clarify why branching helps collaboration? In other words, why is it harder to commit to trunk when you have several developers working on a feature?

Branching enables me to share unfinished work with my collaborators. Sometimes I don't want to commit to trunk yet but still share code and collaborate on a part of the code base.

So you can prepare a change for trunk, and share the change with your colleagues to collaborate on.

Don't see why branching should be needed for this.

Re: Software Engineering at Google (2017)

#49

Post by weinzierl »

majikandy wrote: post #45
weinzierl wrote: post #40

Earlier quoted context omitted.

Branching enables me to share unfinished work with my collaborators. Sometimes I don't want to commit to trunk yet but still share code and collaborate on a part of the code base.

Make the changes smaller and more valuable and do it on trunk.

This should always be Plan A but in my experience it is not always possible. Think of untangling dependencies between a large number of components as an example.

Re: Software Engineering at Google (2017)

#50

Post by hknd »

tieze wrote: post #44
weinzierl wrote: post #11

What I don't understand is how they accomplish larger collaborative changes. The paper says: "Almost all development occurs at the 'head' of the repository, not on branches." Googler Rachel Potvin made an even stronger statement in her presentation about "The Motivation for a Monolithic Codebase" [1]: "Branching for development at Google is exceedingly rare [..]" In the related ACM paper she published with Josh Leven…

It might be a practical thing. I've heard from a Googler (a couple of years back) that getting changes in can take ages, and by the time the change lands, there's a good chance that there are merge conflicts, and the cycle starts over. Branches would make this even more painful.

Depends on the size of the change. Small changes are preferred in most trunk-based-dev companies.

FYI: There are (multiple) tools in Facebook and Google which are an abstraction on top of their VCS. (e.g. which feels more like git, where you can work on a stream of changes which depend on each other without actually pushing anything to head)

Post reply on HN