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

101–110 of 352 posts

Re: Software Engineering at Google (2020)

#101

Post by asoneth »

water-your-self wrote: post #67
danpalmer wrote: post #35

Earlier quoted context omitted.

The tooling is great in some ways, but possibly not in the way you'd expect. There is a tool that will do almost anything, but the tools are often just a bit janky. Rather than thinking of the toolchain as some polished, tightly integrated, perfect system, think of it more like an internal open-source ecosystem of things that work together but which are made by individuals, with limited resources, that still feature…

>most tools are exactly the same sort of thing that you'd create in any other place, we just have more of them Why? Why reinvent the wheel 10 times?

I did not interpret their statement as meaning they have many variants of the same tool, but that they have tools that cover a wider variety of situations.

I found the same thing moving from a very large company to a smallish company. Both had good tooling, the latter just had significantly less and there were gaps in coverage. Whenever I encountered one of those areas I often found myself wishing I had access to some niche tool I had gotten used to at my prior company.

Re: Software Engineering at Google (2020)

#102

Post by fatnoah »

mliker wrote: post #47
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 software engineering may not be perfect, but that's because we all have high standards probably. I've worked at both FAANG and non-FAANG companies, and while the sample size is small and not representative of ALL non-FAANG companies, I will say that my experience at FAANG companies is the engineers there do to get dream big and come up with ingenious engineering solutions that make engineering work at non-FAAN…

> I will say that my experience at FAANG companies is the engineers there do to get dream big and come up with ingenious engineering solutions that make engineering work at non-FAANG look like college senior undergrad projects

My own experience at FAANG and non-FAANG is that __some engineers__ at FAANG get to dream big and demonstrate ingenuity, whereas at non-FAANG (especially startups I've been at) everyone can do this, though not all take the opportunity.

At my last FAANG where I was a manager, my opinion is that performance management and the focus on bullet points, metrics, and peer feedback for review time is a huge limiter for everyone else. I spent a lot of time creating cover for people on my team to actually try something new and innovative. More senior management constantly wanted to know why person X on my team was working on a new thing instead of trying to move some incremental metric somewhere else. Based on my experience during performance reviews for senior ICs, risk taking wasn't particularly encouraged at L6 (or even L7) and below as the cost of failure was substantial.

Re: Software Engineering at Google (2020)

#103

Post by andsoitis »

The Beyoncé Rule

More colloquially, this is phrased as “If you liked it, you should have put a CI test on it,” which we call “The Beyoncé Rule."13 From a scaling perspective, the Beyoncé Rule implies that complicated, one-off bespoke tests that aren’t triggered by our common CI system do not count.

Re: Software Engineering at Google (2020)

#104

Post by UncleMeat »

water-your-self wrote: post #67
danpalmer wrote: post #35

Earlier quoted context omitted.

The tooling is great in some ways, but possibly not in the way you'd expect. There is a tool that will do almost anything, but the tools are often just a bit janky. Rather than thinking of the toolchain as some polished, tightly integrated, perfect system, think of it more like an internal open-source ecosystem of things that work together but which are made by individuals, with limited resources, that still feature…

>most tools are exactly the same sort of thing that you'd create in any other place, we just have more of them Why? Why reinvent the wheel 10 times?

Google has 180,000 employees. There's an org that is responsible for internal tooling, but they are an org with priorities and challenges like any other. So sometimes Search needs a thing and Core won't do it so some people in Search build a tool. Maybe later somebody in Ads needs a similar tool but has never heard of the thing that Search built. So there is an organic force to this sort of complexity.

There are systems to resist this and people whose whole job is to focus on unifying systems, but they aren't perfect. In general, I'd say that Google is way way way more uniform than most other companies because of the monorepo, centralized tooling, and (mostly) uniform development process across the company.

Re: Software Engineering at Google (2020)

#105

Post by mdgrech23 »

ChrisMarshallNY wrote: post #16
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…

Apple has undergone a similar ossification. I think it's just something that happens to companies that get a certain size. The Process becomes more important than the Product. When I was younger, I wanted so badly, to work at Apple. A few years ago, they actually approached me, and I found out that the culture seems to have drastically changed. They ended up not wanting me anyway, so maybe it's just sour grapes, on m…

I don't work there but am curious can you share what you saw?

Re: Software Engineering at Google (2020)

#106

Post by foldr »

biztos wrote: post #96
foldr wrote: post #33

Earlier quoted context omitted.

Has it really? The transition to Apple Silicon was pretty impressive, and something that Apple could have simply decided not to do at all while still remaining hugely profitable. I don't know anything about the company's internal culture, but it's not exactly resting on its laurels just yet.

The hardware people certainly aren't: I think they're reveling in their newfound freedom to make the best, not just the thinnest, computers. But the software side? There seems to be a massive variance in both ability, and giving-a-shit across the software orgs, and no leadership filter on the output of these disparate groups. Perhaps they have the opposite of the resting-on-laurels problem: a smattering of very senio…

The Apple Silicon transition also involves software (Rosetta), which works absurdly well given the complexity of what it's doing.

Re: Software Engineering at Google (2020)

#107

Post by londons_explore »

water-your-self wrote: post #72
danpalmer wrote: post #40

Earlier quoted context omitted.

This is a common meme, but it depends how you define "product". There are companies with millions in VC backing that would just be a feature on a Google (or other big tech company) product as most people define them. I would argue that taking a product from 100m to 1bn users is a whole new level of success, and that has been done multiple times in the last decade.

Why should scaling matter? I thought google tried to solve problems regardless of scale? Or maybe youre commending google for its ability to more effectively commodify datacenter labour in the past decade?

'free' ad supported products usually have engineering costs greater than compute costs, even up to billions of users.

Compute scales with the userbase. Engineering scales with the product featureset. That means a small userbase in general cannot support much engineering and therefore cannot have much complexity/features if it wants to be profitable.

That in turn puts big companies at a massive advantage. And in fact we see that - the vast majority of my time using the web is spent on big products (google, youtube, reddit, twitter), and only a small fraction on small sites (perhaps HN being the one exception here). Those big products won the battle for my attention.

Re: Software Engineering at Google (2020)

#108

Post by fizigura »

londons_explore wrote: post #97
fizigura wrote: post #85

Earlier quoted context omitted.

If you compare the Android from 2008 and the Android from 2023 then you'd soon agree that within these 15 years, the whole thing was re-invented multiple times. And I'm not talking the UX, which has already changed substantially, but I mean the underpinnings.

Sure. But as far as the user is concerned, it is much the same. Touchscreen apps, app store, camera, wifi and phone abilities, app switcher and back button. The user doesn't care that the wheel has been reinvented 3 times along the way... There hasn't been any revolutionary new features in android since shortly after launch really. There have been revolutions in apps. For example, pre 2017 I couldn't just tap a butto…

> There hasn't been any revolutionary new features in android since shortly after launch really.

Not visibly. But the tech stack has changed substantially.

I'd find it quite an achievement if the UX has largely stayed the same while things under the hood got modernized over and over again and went with the times, subtly bringing innovations to the UX as well without people realizing. It's a feature that things don't look substantially different every two years.

Re: Software Engineering at Google (2020)

#109

Post by layer8 »

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…

> perhaps with the exception of Google Photos

Which is somewhat offset by Google dropping Picasa.

Re: Software Engineering at Google (2020)

#110

Post by saalweachter »

fizigura wrote: post #108
londons_explore wrote: post #97

Earlier quoted context omitted.

Sure. But as far as the user is concerned, it is much the same. Touchscreen apps, app store, camera, wifi and phone abilities, app switcher and back button. The user doesn't care that the wheel has been reinvented 3 times along the way... There hasn't been any revolutionary new features in android since shortly after launch really. There have been revolutions in apps. For example, pre 2017 I couldn't just tap a butto…

> There hasn't been any revolutionary new features in android since shortly after launch really. Not visibly. But the tech stack has changed substantially. I'd find it quite an achievement if the UX has largely stayed the same while things under the hood got modernized over and over again and went with the times, subtly bringing innovations to the UX as well without people realizing. It's a feature that things don't…

Android Auto was 2015.
Post reply on HN