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

331–340 of 352 posts

Re: Software Engineering at Google (2020)

#331

Post by emodendroket »

londons_explore wrote: post #268
emodendroket wrote: post #223

Earlier quoted context omitted.

If 80% of buyers express a strong preference for having Carplay/Android Auto I don't think it's reasonable to say that they haven't seen "widespread acceptance."

I read that as "strong preference for having Carplay/Android Auto over the car manufacturers own UI". And everyone is just frustrated with laggy UI's in cars. But in reality they'll probably still just use Waze with a 10 buck phoneholder suction-cupped onto the windscreen.

Why on earth would you do that instead of using Waze on the larger, built-in screen? Especially if you are a buyer who "strongly prefers" having that in the first place? Nobody is using that kind of holder on a car with Android Auto or Carplay.

Re: Software Engineering at Google (2020)

#332

Post by jimmaswell »

underdeserver wrote: post #272
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 -…

I left Google around six months ago. I worked in medium and small companies, currently at a startup with ~30 devs. I would say the vast majority of it works well, some you just don't need until you hit scale (here, scale in the number of developers). For example, policies work if you have Blaze/Bazel I miss a lot. Just wrangling the dependencies between shared packages is a mess (though we might just suck at configur…

Small commit reviews sound miserable. You have no context of the rest of the branch unless you look for it, you have no idea what's in the author's head for future commits (I can imagine some devout YAGNI follower rejecting a commit because a function argument is unused, which the author planned to use tomorrow..), and it sounds like it would encourage minor nitpicking when there's not that much to review. As opposed to a whole branch PR where I can see the entire feature at once and how it comes together.

Re: Software Engineering at Google (2020)

#333

Post by cratermoon »

SNosTrAnDbLe wrote: post #247
cratermoon wrote: post #240

Earlier quoted context omitted.

You're confusing software engineering with corporate product support. You can have top-notch ongoing lifetimes for trash products. See for example SAP or anything Oracle.

Product support is an integral part of enterprise software engineering. Product management does not know what adding a new feature or deprecating an old feature means. It is the responsibility of engineering to provide the dependency matrix. For example, engineering usually tells product, if you change feature A, then it will also affect feature B, C and Z. Otherwise you may end up with contract breaches and SLA viol…

> SAP and Oracle have been successful in the enterprise space

Yes, but are the well-engineered software?

Re: Software Engineering at Google (2020)

#334

Post by underdeserver »

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?

They haven't done it yet. What's been stopping them?

As long as CodeApprove and Reviewable remain niche they've got nothing to worry about.

Re: Software Engineering at Google (2020)

#335

Post by abenga »

londons_explore wrote: post #171
saalweachter wrote: post #110

Earlier quoted context omitted.

Android Auto was 2015.

Hasn't really seen widespread acceptance. I bet a sample of 100 cars on the freeway, perhaps only 25% would have carplay or android auto connected in the USA, and outside the USA adoption is far lower.

This sounds like a result of how often cars are replaced. What if you stopped a sample of 100 cars released in the last five years? That proportion would be far higher. Pretty much every car review I watch mentions support for either or both.

Re: Software Engineering at Google (2020)

#336

Post by underdeserver »

jimmaswell wrote: post #332
underdeserver wrote: post #272

Earlier quoted context omitted.

I left Google around six months ago. I worked in medium and small companies, currently at a startup with ~30 devs. I would say the vast majority of it works well, some you just don't need until you hit scale (here, scale in the number of developers). For example, policies work if you have Blaze/Bazel I miss a lot. Just wrangling the dependencies between shared packages is a mess (though we might just suck at configur…

Small commit reviews sound miserable. You have no context of the rest of the branch unless you look for it, you have no idea what's in the author's head for future commits (I can imagine some devout YAGNI follower rejecting a commit because a function argument is unused, which the author planned to use tomorrow..), and it sounds like it would encourage minor nitpicking when there's not that much to review. As opposed…

For a large feature you work off a design doc or an issue tracker issue (Jira ticket equivalent). If you're going to call the function tomorrow tell your reviewer you're going to call it tomorrow. We're all adults.

Re not that much to review, it's the exact opposite. When people get 400 line code reviews they tend to nitpick on style. When they get a 100 line CR, they critique on naming, organization, consistency.

Re: Software Engineering at Google (2020)

#337

Post by zahllos »

Macha wrote: post #327
zahllos wrote: post #287

Earlier quoted context omitted.

I am a big fan of Anki, and for reasons I wanted to build it on a machine I have on an uncommon architecture (it has a graphical desktop). I have all of the components... rust, typescript, qtwebengine, etc) installed and working. I invested some time in trying to convince bazel that the required dependencies existed, to no avail. Rules broke left right and centre and every time I found the solution, other things brok…

Anki's build seems particularly problematic for some reason - both Arch and NixOS have given up on updating their from source builds and just repackage the first party builds

Sadly first-party builds aren't available for my platform. I suspect the complexity might be in the number of languages they're trying to simultaneously use, plus the complexity of qtwebengine, which requires a working chromium port, which outside of {x86-64, arm64} is not a given.

Re: Software Engineering at Google (2020)

#338

Post by nvm0n2 »

systemBuilder wrote: post #312
londons_explore wrote: post #28

Earlier quoted context omitted.

Google search was 1998. Google Maps was 2005. Gmail was 2004. Android was 2008. Youtube was 2005. Chrome was 2008. Docs was 2006. Translate was 2006. Yet in the last decade, they really haven't had many successes (perhaps with the exception of Google Photos - 2015) One would imagine that with nearly 200,000 employees at least one of them would have a good enough idea for a new product people like. But management and…

You have the wrong impression of Google Translate. Translate was started in 2006 and it sucked. 60% accuracy at best. Janky incoherent sentences. Translate revolutionized the entire field of language translation in 2016. Seriously. Went to 94% accuracy when Jeff Dean joined the project and spurred them to train against all languages at once. It revolutionized the whole research field of language translation. Translat…

Translate did not suck in 2006, it was a big leap over the competitors at the time. It was really the first time a company had launched productized statistical machine translation at all. Before that there was the Altavista Babelfish which was rules based.

Going neural definitely made a big difference but Translate was called "statml" by the infrastructure internally for years, maybe still is, because just using statistics and having training at all was a big deal back then.

Re: Software Engineering at Google (2020)

#339

Post by nonethewiser »

marcyb5st wrote: post #301
nonethewiser wrote: post #245

Earlier quoted context omitted.

> I think there's no nice off-the-shelf offering for running monorepos out there. I think Git works perfectly well for 99% of monorepos though. It just doesn’t work for the massive ones. I think its a perfect example of something most codebases shouldn’t follow google on.

Maybe if you only allow for shallow clones/pulls. I am not sold on vanilla git handling monorepo well. If anybody in the company pushes a huge blob you mess up everyone else and so on. Git and some modifications perhaps yes though

> If anybody in the company pushes a huge blob you mess up everyone else and so on

Again, this is really only a problem at larger scale. The segmented number of people that pull this large blob at Google may be higher than the entire engineering team at other companies.

Re: Software Engineering at Google (2020)

#340

Post by nonethewiser »

UncleMeat wrote: post #252
nonethewiser wrote: post #238

Earlier quoted context omitted.

I dont think its fair to classify code review and test coverage as “the google way.” Should evaluate more by the unique things google does or the things they specifically invented (not code review and testing). And of course volunteers working on open source projects have lower standards. Lets instead compare Google to companies which say “we arent google.”

What I am describing is not code review and test coverage. What I am describing is the ability to run all of the tests for the entire company in one go so you can safely make absolutely massive changes to the codebase.

So having a monorepo?
Post reply on HN