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

61–70 of 319 posts

Re: Software Engineering at Google (2017)

#61

Post by taivokasper »

Izmaki wrote: post #26
taivokasper wrote: post #15

Earlier quoted context omitted.

Could you bring a any examples of individual goals? How are they worded for devs and how different they are from the product goals?

It's not easy to list goals from the top of my head as it's not my strong side, and especially not if they have to be measurable (which good goals should be, rather than your boss evaluating whether or not you did something), but here goes: Goals could be "Pick up language X in order to help development on project Y" or "Get formally introduced to all R&D team leaders, and get introduced to their roadmaps" or "Facili…

Thank you. I asked because in the previous company I worked for we had difficulties setting measurable goals for devs and ended up tracking only product goals.

Re: Software Engineering at Google (2017)

#62

Post by davidwihl »

MichaelMoser123 wrote: post #53
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”."

I am wondering if the rewriting rule applies to AdWords and search, I mean they probably would get very upset if their cashcow stops working, all of a sudden.

The AdWords API is now being re-written, the biggest change in ten years. It is migrating from XML to gRPC / protobuffers.

https://developers.google.com/google-ads/api/docs/start

Disclosure: I co-author the Python client library and have written a few of the docs on the site listed above.

Re: Software Engineering at Google (2017)

#63

Post by quietbritishjim »

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.

Re: Software Engineering at Google (2017)

#64

Post by elmozyz »

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…

> Not necessary when your misery not-product-market-fit-yet website only gets 100 users. Just roll-the-f-out , let it break and fix later. Building the canary system is a huge overkill in the early stage.

Being a startup does not excuse this kind of cavalier attitude

Re: Software Engineering at Google (2017)

#65

Post by weinzierl »

hknd wrote: post #48
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.

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.

Re: Software Engineering at Google (2017)

#66

Post by thetechlead »

elmozyz wrote: post #64
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…

> Not necessary when your misery not-product-market-fit-yet website only gets 100 users. Just roll-the-f-out , let it break and fix later. Building the canary system is a huge overkill in the early stage. Being a startup does not excuse this kind of cavalier attitude

When you face life-or-death scenarios everyday as a startup founder.

Not a single startup was killed by software bugs or design faults. Never. Many other things do.

Re: Software Engineering at Google (2017)

#67

Post by hknd »

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

If you have a question to a specific example I'm happy to answer it in the way it would've been done within Google/Facebook.

Re: Software Engineering at Google (2017)

#68

Post by xw1001 »

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?

Mostly negative experiences:

1) While writing up the goals, you don't have a full view of the problem. Goals change, but once written down, there is a strong pressure to implement what has been written down.

2) It selects for people who are good at writing convincing design docs. Often these people write sub-optimal code and the designs only look good on paper.

Actually, the products (aside from search+ads) that come out of Google look exactly like the have been produced using this methodology; and that's not a good thing.

Re: Software Engineering at Google (2017)

#69

Post by laurentlb »

patothon wrote: post #31

Not worth a long discussion, but is the Blaze build system they are referring to in fact Bazel?

Yes. Blaze is the name of the binary inside Google. 90% of the code is in common. Differences are 1. integration with Google-internal tools, and 2. legacy misfeatures we plan to remove.

(I work on Bazel)

Re: Software Engineering at Google (2017)

#70

Post by puzzle »

Cursuviam wrote: post #32
patothon wrote: post #31

Not worth a long discussion, but is the Blaze build system they are referring to in fact Bazel?

Blaze is the internal version, such as borg vs kubernetes

Except that Blaze/Bazel share code, are very similar and converging over time. The plan is for Google to use Bazel+extensions at some point in the future. Borg and Kubernetes don't share code (they are written in different languages: C++ and Go), look similar only from a very high level perspective and are diverging over time.
Post reply on HN