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

121–130 of 319 posts

Re: Software Engineering at Google (2017)

#121

Post by ranma42 »

weinzierl wrote: post #86
hknd wrote: post #67

Earlier quoted context omitted.

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

FWIW coreboot is an open-source project that uses a similar style, where you need to upload your change to the review tool (https://review.coreboot.org/, which is using gerrit https://www.gerritcodereview.com/) and people comment and LGTM in there and then it gets committed to the master branch once everything looks good.

Re: Software Engineering at Google (2017)

#122

Post by CamouflagedKiwi »

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…

Unfinished work is not typically checked into master (and it's certainly not regularly broken).

What is more common is that very large changes are checked in as a series of individually compatible changes, and often broken up across the repository (there are of course tools to help with this). It's relatively rare for multiple developers to work on a single changelist; it's much more common to break the work into separate changelists.

Haven't worked there for some years now so I'm a bit rusty on some of the detail.

Re: Software Engineering at Google (2017)

#123

Post by dharmab »

yjftsjthsd-h wrote: post #99
lordnacho wrote: post #27

Earlier quoted context omitted.

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?

Just do one thing at a time? Today, I am working on X; my commits are for X, and details are in the commit message.

That breaks as soon as you have to interrupt working on Nice To Have Feature X to working on Inportant Bugfix/CVE Y.

Re: Software Engineering at Google (2017)

#124

Post by sytelus »

gtirloni wrote: post #110
sytelus wrote: post #91

Earlier quoted context omitted.

If you have engineers with physiological problem of “not invented here”, you have a very serious issue. I am currently seeing this in real time in one of the projects and I was told almost exact same words as “reason” to recreate what we already have and working beautifully. It was clear to me that some developers are just too lazy to dive in to complex system. They get ticked off by one imperfection here and other o…

It's hard to relate without more information about the specific situation. What is the current programming language used? Is the project mostly legacy (few or no changes in the last few years)? Is the project critical to the company? How many people are working on it today? Are they fully assigned to it or is it a "touch when it breaks" kind of situation? Is the project following modern CI/CD practices? If not, how h…

Yes, there are many legitimate reasons to rewrite like dieng frameworks/languages. However we are discussing here the case where reason proposed for the rewrite is solely to satisfy physiological need of some developers to work on code they can call it their own. A lot of things can be done by refactoring but the devs with these issues often just start new projects of their own that does same thing. In companies like Google, for example, there are at least 5 different products for messaging.

Re: Software Engineering at Google (2017)

#125

Post by skj »

webmaven wrote: post #76
scarface74 wrote: post #41

Earlier quoted context omitted.

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.

Well, if you exceed expectations, doesn't that mean you didn't set your goals high enough?

Ideally expectations are relative to your position at the company, not what people think you can accomplish.

Re: Software Engineering at Google (2017)

#126

Post by zorked »

lugg wrote: post #9
yakshaving_jgt wrote: post #8

Earlier quoted context omitted.

Thanks for highlighting this. To me it seems an important idea that contradicts conventional wisdom, similar in the way that most people over-encourage DRY, blind to the fact it increases coupling.

I frequently find myself drastically refactoring code to understand it. I don't commit those changes because it's not worth the effort to justify the cleanup to people who treat these rules as gospel. Apparently me spending half a day reading code is no big deal but cleaning it up is a waste of time. Shrug.

Five people understand the system.

You refactor it.

Now one person understands the system.

Re: Software Engineering at Google (2017)

#127

Post by lmilcin »

sytelus wrote: post #91
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”."

If you have engineers with physiological problem of “not invented here”, you have a very serious issue. I am currently seeing this in real time in one of the projects and I was told almost exact same words as “reason” to recreate what we already have and working beautifully. It was clear to me that some developers are just too lazy to dive in to complex system. They get ticked off by one imperfection here and other o…

Remember, we are talkin about a bunch of good, well supported engineers working within rather well oiled machine with a lot of other teams doing similar work and sharing experience and advice.

Nobody said it is good general advice. There is so much stuff you need to do well to have a good chance at successful rewrite that it become good advice that it is a bad idea. Nobody said rewrites cannot be done. If you have a company that knows how to do rewrite (and makes it constantly which, I guess, helps a lot) then a lot of problems can be solved by starting from scratch and it it may be it is well worth it.

Re: Software Engineering at Google (2017)

#128

Post by phonebucket »

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…

>Sure it sounds wonderful everyone can see/fix anyone else code but 99% people shouldn't have time to do so (if they do their work load is not full, increase the load).

A developer shouldn't have time to fix other people's bugs?

Re: Software Engineering at Google (2017)

#129

Post by aaaaaaaaaab »

hopler wrote: post #90
aaaaaaaaaab wrote: post #43

Earlier quoted context omitted.

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.

W-hat? Where did you get that from?

I'm telling you, fixing a serious issue in a legacy component is anything but amusing. I'd be happy writing blogposts about the current framework of the week, but if I uncover an issue while working on my regular tasks, I'm gonna try to fix it instead of sidestepping it.

Re: Software Engineering at Google (2017)

#130

Post by afpx »

ownagefool wrote: post #74
afpx wrote: post #23

Earlier quoted context omitted.

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 think you mistunderstood that link is arguing for. It's basically github flow with tagging on what you release, only goes into a bit more details and discussed alternatives and suffers a "bit from too much information" https://guides.github.com/introduction/flow/ Is a cleaner and more obvious guide. The idea is you have a constantly usable master, and your branches should be short lived so you don't hit a brick wal…

Thanks - I should have read through it more.
Post reply on HN