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

Software Engineering at Google (2020)

abseil.io

Post reply on HN
Print view View original

291–300 of 352 posts

Re: Software Engineering at Google (2020)

#291

Post by choppaface »

flohofwoe wrote: post #21

Probably a bit off-topic, but since I'm a bit triggered by the 'abseil' in the domain name: I wish Google would relax their 'guidelines' when it comes to software that's also published outside of Google. Case in point: the Dawn C++ library (Google's native WebGPU implementation) has a dependency on abseil, and from what I've seen when glancing over the code, the only reason seems to be some minor string-related stuff…

Part of the pressure behind abseil is that perf and promotions are correlated with open source (Tensorflow, Chromium, TFX, etc) and it would be essentially impossible to translate internal projects for public release without a public library like abseil.

In contrast Facebook Folly has much less overall clout because engineers there have more incentive to build-from-scratch, which can include simply not using C++.

Re: Software Engineering at Google (2020)

#292

Post by limonkufu »

codeapprove wrote: post #277
sa46 wrote: post #275

Earlier quoted context omitted.

Of all the Google dev tools, I miss Critique the most. GitHub is terrible at giving enough context to efficiently review a PR on a second or third pass. I think coupling commits with review progress was a mistake.

Shameless plug but if you're missing Critique and working on GitHub, try CodeApprove ( https://codeapprove.com ) which brings as much of the Critique magic to GitHub as possible.

This seems very simiilar to Gitlab's MR. Does anyone know all of them to highlight their strengths and drawbacks?

Re: Software Engineering at Google (2020)

#293

Post by jrockway »

pclmulqdq wrote: post #243
raldi wrote: post #83

Earlier quoted context omitted.

Off-topic for this thread, but one of the most poignant quips I remember about Google culture was that the performance-review process was really good at rewarding hard, challenging work that didn't produce much value and not very good at recognizing work that produced lots of value but was not astoundingly difficult. I think you were the one who first noted this.

I recently explained Google's perf process to an employee of the US federal government, and was told that the performance review and promotion processes in the government were simpler and less wasteful.

Is the government getting good results out of their process? Remember when a bunch of ex-Google engineers had to step in and save healthcare.gov? If their simple promotion process works, why didn't they curate that talent in-house.

People at L4 might not really like Google's process, but if some Distinguished Engineer shows up at your design review you're pretty much guaranteed to get some sort of valuable feedback. That is not a given in other organizations.

Re: Software Engineering at Google (2020)

#294

Post by darkwater »

codeapprove wrote: post #277
sa46 wrote: post #275

Earlier quoted context omitted.

Of all the Google dev tools, I miss Critique the most. GitHub is terrible at giving enough context to efficiently review a PR on a second or third pass. I think coupling commits with review progress was a mistake.

Shameless plug but if you're missing Critique and working on GitHub, try CodeApprove ( https://codeapprove.com ) which brings as much of the Critique magic to GitHub as possible.

Offtopic but, aren't you scared by "GitHub improves its PR workflow" and put your product out of business?

Re: Software Engineering at Google (2020)

#295

Post by codeapprove »

darkwater wrote: post #294
codeapprove wrote: post #277

Earlier quoted context omitted.

Shameless plug but if you're missing Critique and working on GitHub, try CodeApprove ( https://codeapprove.com ) which brings as much of the Critique magic to GitHub as possible.

Offtopic but, aren't you scared by "GitHub improves its PR workflow" and put your product out of business?

Yes that's a real risk! CodeApprove is not (yet) anyone's full time job so it's also an acceptable risk.

However I think the biggest issue with the landscape for code review tools is that 99% of developers use the default system that ships with their VCS. So on most teams, that's GitHub. People should be actively choosing their code review tools just like they choose their VCS, IDE, CI/CD platform, Issue Trackers, etc. It's one of many tools that makes up your SDLC "Stack".

Re: Software Engineering at Google (2020)

#296

Post by hn_throwaway_99 »

nostrademons wrote: post #266
choppaface wrote: post #263

Earlier quoted context omitted.

One conspicuous omission in the ex-google is reflection on killed products like Google Wave, Plus, Glass etc etc etc .. for many of the [whatever] was the gross imbalance between Eng owning the product but ignoring the userbase. What ex-googlers often fail to grapple with is the product lifecycle (how short it may be) and the value of having diversity in the loop of product testing. Google is designed to be a safe pl…

Google's penchant for killing promising products is 100% the result of poor incentives. People are incentivized for launching challenging projects, but they are generally not responsible for the bottom line (which is going to be dwarfed by Search Ads revenue anyway) or for user happiness & brand loyalty (which is challenging to measure). As a result, lots of promising and exciting products are brought to market and t…

I'm not sure why your comment was previously downvoted. I've often heard, and it's not hard to find these comments from ex-Googlers on HN, that Google's "promotion-oriented development" is one of their biggest factors in some of their cultural shortcomings. That is, launching a big new product is seen as one of the best ways to get promoted, while working on the little nits (which in my experience, especially with some of Google's enterprise products, can languish for years, even though they can be really important but "boring" issues to fix) is not seen as high-value work.

Re: Software Engineering at Google (2020)

#297

Post by jeffbee »

jimmaswell wrote: post #284
jeffbee wrote: post #17

Earlier quoted context omitted.

In my ex-Google experience, here are the stages of denial about something that Google does which is good but the industry doesn't yet embrace. Stage 1: "We're not Google, we don't need [[whatever]]"; Stage 2: Foreseeable disaster for which [[whatever]] was intended to address happens; Stage 3: Giant circus of P0/SEV0 action items while everyone assiduously ignores the [[whatever]]; Stage 4: Quiet accretion, over seve…

> pre-commit code review Unless you're referring to automated precommit hooks, this sounds baffling. What's wrong with reviewing pull requests? What if I want to push a WIP while I switch to another branch, I still need a review? Is the final PR reviewed again at the end?

That's a git user's perspective and Google doesn't use git or anything analogous. Under their system, and generally under Perforce, it is never necessary to "push a WIP" because your client just contains whatever edits it contains. You never need to manually checkpoint, stash, or commit. People with multiple changes in flight will usually use two different clients, one for each change, although that is not strictly mandatory and in the perforce model you can have disjoint sets of files in multiple changes in the same client.

Anyway, TL;DR, the problems you suggest are git-specific and one solution to them is not using git.

Re: Software Engineering at Google (2020)

#298

Post by jrockway »

greiskul wrote: post #226
opportune wrote: post #190

Earlier quoted context omitted.

I kind of disagree in the sense that readability indirectly forces someone who has been at Google for a while/ is more experienced to have to sign off on new people’s code. Without it, you could have some very junior members with OWNERS reviewing other very junior members’ code. And there is more to style than just linting, IMO. For example in C++ there are some complex macro-based test predicates that are hard to le…

> I kind of disagree in the sense that readability indirectly forces someone who has been at Google for a while/ is more experienced to have to sign off on new people’s code. Without it, you could have some very junior members with OWNERS reviewing other very junior members’ code. Exactly. It is very likely for a lot of junior engineers will be working with other junior engineers, and they will in fact have the most…

I dunno, I am pretty sure I got Java readability the second month I was at Google and was already in the OWNERS file.

I was a readability reviewer and most of the readability CLs were the first project a person worked on at Google, often rather unnecessary but redone strictly to meet readability requirements (largely new code, more than X lines, etc.). I would go back and forth for quite a while to turn 1000 careless lines of throwaway code into 50 lines that were actually good, but I basically had to grant readability after that one interaction, and it never felt great to me.

The most hated readability process at Google was Go's process (at least in the early days; k8s is obviously not using it), but I think it was actually one of the best. It took me a long time to get Go readability, but after going through the process I feel like I'd write the same Go code as anyone on the Go team. When I look at people's open source projects I think to myself "don't they know that that Simply Isn't Done?" But of course they don't; Go readability can only be experienced, not explained. People didn't like that process, and I am sure I said nasty things about it at the time, but in retrospect I really like it.

Re: Software Engineering at Google (2020)

#299

Post by AlbertCory »

mushufasa wrote: post #4

Cool. Could someone, maybe an ex-googler, comment on which parts of these work well and which don't? A lot of other companies get into trouble trying to cargo-cult what Google does when they are operating in very different environments wherein those practices aren't optimal. E.g. different levels of scale. Additionally, critics of Google may point out that their engineering culture may not be great on its own terms -…

Personal story from ex-Googler: after getting exasperated at yet one more internal tool launched with great fanfare and almost no testing, let alone documentation, I suggested to the Internal Tools group that we have a contest for BEST internal tool.

Not "worst" since that would be too hurtful. The hope was to recognize excellence, motivate people to be better, and maybe shame the people whose tools received no votes. This suggestion was summarily dismissed.

There were, indeed, some truly excellent tools: Dremel comes to mind. And lots of tools that were nearly unusable.

Re: Software Engineering at Google (2020)

#300

Post by deanCommie »

jeffbee wrote: post #17
mushufasa wrote: post #4

Cool. Could someone, maybe an ex-googler, comment on which parts of these work well and which don't? A lot of other companies get into trouble trying to cargo-cult what Google does when they are operating in very different environments wherein those practices aren't optimal. E.g. different levels of scale. Additionally, critics of Google may point out that their engineering culture may not be great on its own terms -…

In my ex-Google experience, here are the stages of denial about something that Google does which is good but the industry doesn't yet embrace. Stage 1: "We're not Google, we don't need [[whatever]]"; Stage 2: Foreseeable disaster for which [[whatever]] was intended to address happens; Stage 3: Giant circus of P0/SEV0 action items while everyone assiduously ignores the [[whatever]]; Stage 4: Quiet accretion, over seve…

I'm sorry are you saying Google invented multi-tenant services, unit testing, or user data encryption?

I'll give you "pushed the WEB industry to have transport-layer encryption for the entire industry by default".

I'll even give you "code reviews".

But not the first 3.

Post reply on HN