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

81–90 of 319 posts

Re: Software Engineering at Google (2017)

#81

Post by thetechlead »

quietbritishjim wrote: post #63
thetechlead wrote: post #54

I used to be proud of many things in the article when working at the G. Not anymore. Let me talk startup anti-Google pattern here. * Most of Google’s code is stored in a single unified source-code repository, and is accessible to all software engineers at Google This can be the worst nightmare from a management POV in a startup. Sure it sounds wonderful everyone can see/fix anyone else code but 99% people shouldn't h…

> definitely never Python which is a maintenance nightmare Did you just say that all startups should never use Python? This is such a ridiculous statement I could hardly imagine where to begin with it.

Yes.

Re: Software Engineering at Google (2017)

#82

Post by hopler »

weinzierl wrote: post #65
hknd wrote: post #48

Earlier quoted context omitted.

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.

That's what I meant in my question with "share code by other means". It works but in my opinion it is a large pain and I can't believe people at Google work by sending patches back and forth.

Your changes aren't sitting on your machine. They are hosted on a server or in a git fork. After test and code review, you merge to head before deploying to production or other people make follow-on changes.

Re: Software Engineering at Google (2017)

#83

Post by hopler »

lordnacho wrote: post #27
philosopher1234 wrote: post #24

Earlier quoted context omitted.

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

Isn't it essential for mental organisation? How do you think about what's different about a set of changes without some sort of DAG?

Make one change at a time.

Re: Software Engineering at Google (2017)

#84

Post by ithkuil »

weinzierl wrote: post #39
mateuszf wrote: post #12

Earlier quoted context omitted.

You don't have to check in unfinished work, you can break your work in parts and make people work on independent parts, every one of which moves progress forward incrementally. Well, you could actually call that "unfinished" because in the beginning the code doesn't accomplish the task, but progressively it will become more useful.

> you can break your work in parts You can when you can but you can't when you can't. I 100% agree with you that we should work this way whenever possible and we should work hard to keep our code in a state that lets us cleanly divide work. In my experience it is not always possible to split up work that way. Think of untangling dependencies of a larger part of the code as an example.

Sometimes you think you can't because you either haven't learned the right tricks, or because it takes more effort and thus you opt to fork off your work in a separate long standing branch in order to optimize your development velocity at the expense of possible surprising costs during merge (if other people also make your same choice).

Other times it's genuinely necessary to make a long standing branch. In those cases, you just do it. Trunk based development should not be a dogma, just a different default choice.

Re: Software Engineering at Google (2017)

#85

Post by hopler »

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 need to communicate with your colleagues to coordinate your work.

Re: Software Engineering at Google (2017)

#86

Post by weinzierl »

hknd wrote: post #67
weinzierl wrote: post #65

Earlier quoted context omitted.

That's what I meant in my question with "share code by other means". It works but in my opinion it is a large pain and I can't believe people at Google work by sending patches back and forth.

It's actually really easy to create a "patch", so people usually create small "patches" and send them to people if they need any feedback on those. A "patch" is actually just a commit (actually a changelist) which can be viewed, commented and edited in the browser based code review and IDE tool. Imho I find it much easier to get an url of a "patch" and comment on it inline, instead of having to checkout a branch etc.…

Thank you, I appreciate your effort to help me understand this better and our exchange helped me to make progress.

One thing I infer from your answer is that it seems that there is an established process and dedicated tooling for working with patches at Google. I think a lot of my pain with patches stems more from the lack of process and lack of an agreement on formats and standards in my environment than from the use of patches per se.

Where I still see an advantage of branches is that they facilitate documentation of what has been done by whom and when. All of this documentation is in the same place and form as the documentation of changes in the trunk. It all is in commit messages whereas patches are only documented somewhere else, possibly in the Email or IM used to send the patch. Even if most of the branch documentation does not survive on trunk when we squash the final merge it is still there and easy to find as long as the branch doesn't get deleted. When I want to look up why I applied a certain patch I'll have to dig through my messages. I think that makes it harder to work with patches than with branches.

Re: Software Engineering at Google (2017)

#87

Post by richardwhiuk »

weinzierl wrote: post #25
jsty wrote: post #17

Earlier quoted context omitted.

You could also gate experimental code behind feature flags which aren't set in prod

I agree that feature flags can be a solution sometimes. The presentation and the paper I linked to in my question discusses this, but they also mention large-scale refactorings and this is where I don't see how feature flags can help. For example: How do they untangle a wad of code that is large enough that it takes longer than a few days and more than a single developer to get the code back into a state that is acce…

You don't do that - you lots of small incremental refactors. I think Google also have tools to make a large refactor into a small change.

(i.e. you create the new API, migrate stuff to use it, deprecate the old one, migrate the rest, retire the old one).

Re: Software Engineering at Google (2017)

#88

Post by Radim »

snorkel wrote: post #79
Radim wrote: post #5

Buried in the "2.11 Frequent rewrites" section, but a great hack for "productivity via a sense of ownership": "In addition, rewriting code is a way of transferring knowledge and a sense of ownership to newer team members. This sense of ownership is crucial for productivity: engineers naturally put more effort into developing features and fixing problems in code that they feel is “theirs”."

After working with banks that still run production code on obscure and obsolete platforms written by people who retired decades ago, I totally endorse this practice ... as long as I’m not doing the rewrite.

The dance between death by ossification and death by excessive chaos is a delicate one.

Be too quick and you're constantly chasing shadows… wait too long and you're immobile.

Re: Software Engineering at Google (2017)

#89

Post by skj »

weinzierl wrote: post #65
hknd wrote: post #48

Earlier quoted context omitted.

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.

That's what I meant in my question with "share code by other means". It works but in my opinion it is a large pain and I can't believe people at Google work by sending patches back and forth.

It's not like we (I am a Googler) email patch files around. Everything is integrated into the system. You create a CL (change list), it automatically gets a number. People can review it, test it, or fork it (make a new CL using your CL as a starting point) as much as they want, all from that CL number.

Re: Software Engineering at Google (2017)

#90

Post by hopler »

aaaaaaaaaab wrote: post #43
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 compone…

It's OK if we lose people who don't care about contributing to the organizational goals and coordinating with teammates, who just want to mess around on whatever amuses them.
Post reply on HN