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

211–220 of 352 posts

Re: Software Engineering at Google (2020)

#211

Post by fizigura »

emodendroket wrote: post #192
londons_explore wrote: post #171

Earlier quoted context omitted.

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.

Are you sure? https://appleinsider.com/articles/23/05/23/carplay-android-a... > A report from Straits Research found that 98% of newly produced vehicles were compatible with either CarPlay or Android Auto. Meanwhile, 80% of prospective car buyers strongly preferred having these smartphone-based infotainment systems in their new vehicles. The same research also shows Asia-Pacific to be the biggest market for these pro…

"connected" vs "compatible with"

Tbf. 25% connected is huge. If you just jump into your car to quickly do groceries or pick up your kids, you may not be interested in connecting your phone to your car, even if you really like that feature. So there could be a natural ceiling for the "connected" number and 25% feels getting close to that ceiling actually.

Re: Software Engineering at Google (2020)

#212

Post by summerlight »

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

> comment on which parts of these work well and which don't?

I don't think there is a visible distinction between those parts that work/doesn't work. In fact, most of the cases each practice has pretty strong rationales. The problem is, when you take everything as whole, its cumulative complexity and cognitive overhead tends to go wild and almost no one can understand the whole stack when its original writers/maintainers leave the team.

In fact, this might play a certain role of the Google graveyard narrative; it's not because its engineering culture is bad, but sometime its standard is too high for many cases so it's nearly impossible to keep it up for newcomers, especially when you have external pressures that you cannot ignore. Even if you make an eng team of 3~4 people for a small product, they'll likely suffer from tens of migration/deprecation/mandates over years.

Re: Software Engineering at Google (2020)

#213

Post by opportune »

eddd-ddde wrote: post #161
n0zmer wrote: post #26

Earlier quoted context omitted.

I thought so too, but since then I moved over to Cloud and things are a LOT better.

I always here about Cloud having the worst culture tho? Has that not been the case to you?

Some teams in Cloud suck but the core engineering teams have some top talent and solve some very hard problems. Keep in mind Borg and Spanner are both “cloud”, but so are many field sales teams with an average tenure <2y

Re: Software Engineering at Google (2020)

#214

Post by VirusNewbie »

londons_explore wrote: post #28
ye-olde-sysrq wrote: post #11

"As far as this outsider can tell, the systems and processes for writing code at Google must be among the best in the world, given both the scale of the company and how often people sing their praises." Is this really the case? In high school I sure thought Google was a magical software heaven us mortals could but dream of working for, but now (and increasingly as of late) I'm strongly under the impression that 20 ye…

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…

K8s,

TPU

Colab

Tensorflow

hmmm.

Re: Software Engineering at Google (2020)

#215

Post by [deleted] »

n0zmer wrote: post #26
hiddencost wrote: post #9

Earlier quoted context omitted.

Engineering culture has somewhat collapsed at Google. The things that made engineering great didn't really survive the last couple rounds of internal coups.

I thought so too, but since then I moved over to Cloud and things are a LOT better.

[deleted]

Re: Software Engineering at Google (2020)

#216

Post by neilv »

jimbooonooo wrote: post #138

Cool, is this available as a PDF?

"https://www.ebooks.com/en-us/book/209970024/software-enginee..." includes PDF and EPUB formats.

(I bought it, intending it as interview prep for an experienced engineer interview, but seems they are doing student-startup-style Leetcode interviews.)

Re: Software Engineering at Google (2020)

#217

Post by robertlagrant »

sumtechguy wrote: post #144
MarceColl wrote: post #38

Earlier quoted context omitted.

The tools, design and manpower needed to build a skyscraper are different from those needed to build a 1-story wood house. It's not that the ones that build the wood house are failing to study and adopt the ways of their extremely successful competitors. Now, some of the things you say like unit-testing and user data encryption are ones that I've never seen associated with the "We're not google" mindset, so maybe peo…

"were not google" is usually good for things where people are using cargo cult. I saw at one company that went open floor plan because google did it. No one was happy about that. Retention became very low and everyone bailed out. Emulating google does not fix process and management issues. As what may be at google for a good reason may be an utter failure at another company. There are things all shops can adopt that…

> "were [sic] not google" is usually good for things where people are using cargo cult

It's no different to cargo culting. That should not be the reason for not doing something, any more than the opposite should be a reason for doing it. Just see if the practice makes sense in your context and decide that way.

Re: Software Engineering at Google (2020)

#218

Post by saalweachter »

fizigura wrote: post #211
emodendroket wrote: post #192

Earlier quoted context omitted.

Are you sure? https://appleinsider.com/articles/23/05/23/carplay-android-a... > A report from Straits Research found that 98% of newly produced vehicles were compatible with either CarPlay or Android Auto. Meanwhile, 80% of prospective car buyers strongly preferred having these smartphone-based infotainment systems in their new vehicles. The same research also shows Asia-Pacific to be the biggest market for these pro…

"connected" vs "compatible with" Tbf. 25% connected is huge. If you just jump into your car to quickly do groceries or pick up your kids, you may not be interested in connecting your phone to your car, even if you really like that feature. So there could be a natural ceiling for the "connected" number and 25% feels getting close to that ceiling actually.

My older car requires a hardwire connection for Android Auto, but my newer car will automatically connect over wifi so I no longer need to take my phone out of my pocket unless I want to charge.

Re: Software Engineering at Google (2020)

#219

Post by summerlight »

Espressosaurus wrote: post #169
badlucklottery wrote: post #158

Earlier quoted context omitted.

This. Someone dropped the ball. There's a form to get your corner of the codebase exempted from readability temporarily. This gives your team a quarter or two to build up readability.

A quarter or two isn't going to be enough for a drastic realignment of a large codebase. It's a start, but only a start.

Readability is usually applied in an incremental way. You don't have to fix all the code to make it conformant. If there are concerns about consistency, the style guide actually encourages people to prefer consistency over its own rule.

Re: Software Engineering at Google (2020)

#220

Post by compiler-guy »

MH15 wrote: post #153
drewg123 wrote: post #46

Earlier quoted context omitted.

"Readability" works terribly when your company is acquired and your team enters all at the same time. Google has (or had ~10 years ago), a thing called "readability" for each language, where in order to be allowed to commit code to the central "google3" repo, you needed to have written some large amount of code in that language, and needed to have a readability reviewer sign off on your code. The process is designed…

"Readability" is very much still a thing. It's a mess and would be one of the worst things to take from Google. If you can't enforce the code style you like through autoformatters and linting, it's not worth enforcing.

Readability is far, far more than formatting and linting. I hate the current system a lot, but no linter or autoformatter knows if an identifier is appropriately named or if a function is properly decomposed.
Post reply on HN