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

51–60 of 352 posts

Re: Software Engineering at Google (2020)

#51

Post by rb2k_ »

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…

Last I talked to people about Apple's internal tooling, it was still pretty fragmented between different organizations.

I was told about e.g. multiple internal CI/build systems because one org didn't want to rely on the other, so they both built their own little software stacks.

That's a bit different than what I've heard from meta/google/amazon who seem to be more open to running centralized internal services

Re: Software Engineering at Google (2020)

#52

Post by shadowgovt »

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…

You're not wrong. Google gets to sidestep a lot of problems other lower-margin companies have because they've spent their whole history being near market-leader on search and ads. Things like "deadlines" were foreign to the company for a long time; when you're already the pack leader, you release new features when you feel like it, not to play catch-up with competitors. You can see them struggle in spaces where that's not true (Cloud, for example).

There is one underlying technology special sauce they refined to an art form, which is building a reliable system on incredibly unreliable components. This comes from their inception when the two guys building out the company knew how to write code but not build custom machines; their initial attempts at racks (hard drives and motherboards mounted to flexible plywood) are hilarious-looking by modern standards and broke down all the time, so they had to learn how to write software that was fault-tolerant at every link in the chain. That resulted in building an infrastructure that was extremely supportive of experimentation (if the system can survive half of it disappearing, it can survive a software bug crashing half the machines), and the rest of the shape of the company kind of flows from that.

It is worth repeating a lot that most companies do not operate at the scale or constraints Google does, and their approach to engineering is emphatically not one-size-fits-all.

Re: Software Engineering at Google (2020)

#53

Post by fractalb »

lapcat wrote: post #34
FartyMcFarter wrote: post #27

Earlier quoted context omitted.

I don't understand your argument - why is the one trick pony revenue generation incompatible with high quality systems and processes for writing code? Both can be true at the same time, and my feeling is that they are, having worked there. The business is not very diversified, and the tools are great.

> I don't understand your argument - why does the lack of a diversified business have imply a lack of quality for systems and processes for writing code? That wasn't the argument. The argument was simply that having a profitable monopoly doesn't imply the presence of quality.

How did they achieve monopoly if it weren't for the quality?

Re: Software Engineering at Google (2020)

#54

Post by 7e »

For all of this, Google doesn’t create very good products anymore. This is a guide that came into being _after_ Google was successful. It’s not _why_ Google became successful.

Yes, if you have a mountain of money and a horde of underutilized employees, it’s easy to gold plate your engineering and navel-gaze at your biases.

Re: Software Engineering at Google (2020)

#56

Post by matwood »

FartyMcFarter wrote: post #27
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…

I don't understand your argument - why is the one trick pony revenue generation incompatible with high quality systems and processes for writing code? Both can be true at the same time, and my feeling is that they are, having worked there. The business is not very diversified, and the tools are great.

It's not incompatible, but making money hand over fist can hide many problems.

Re: Software Engineering at Google (2020)

#57

Post by danpalmer »

88913527 wrote: post #45
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…

I have yet to be impressed by internal software tools developed by one team and consumed by another. You're likely being friendly and understating the degree of jank which is present.

Is this at Google, or elsewhere? If it's at Google I'd be happy to try to persuade you via chat :)

If elsewhere, I think there are 2 kinds of tool: those developed by individuals/small groups in informal ways, some of these are bad, but much like with open-source tools, the ones that are good survive and become popular. The other type is those with more formal backing, dedicated dev/design/UX/PM resources, and those are good at surveying users to figure out what the right problem to solve is, so they're normally pretty good, and when they're not, they still accept fixes (I regularly contribute fixes to other teams codebases when I find issues).

Re: Software Engineering at Google (2020)

#59

Post by jollyllama »

fnordpiglet wrote: post #29
nosefrog wrote: post #14

Earlier quoted context omitted.

I used to work there. The tooling is pretty good.

I’ve not worked there but I’ve worked with many exgooglers. They tend to think Google * is the best in the world and they created it before anyone else and everyone else with similar capabilities copied them, and that Googlers are smarter. However every company of their size and technical complexity has built almost exactly the same tooling and processes, but don’t carry the same attitude around. At a certain point I…

Great comment. Google and others blazed a trail, but by 2010 you could find similar, often specialized tooling and practices emerging at most Fortune 500 tech companies.

Re: Software Engineering at Google (2020)

#60

Post by lapcat »

dudul wrote: post #50

I've always found it weird that people seem to obsess so much on how Google does things. From hiring to writing code and tooling. Google is so much not like any other company, especially 20 employee startups. Trying to apply their recipes to 99% of companies is solving problems that don't exist and most likely creating new ones you don't need to deal with.

Related: The Carrot Problem https://news.ycombinator.com/item?id=37100226
Post reply on HN