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

71–80 of 352 posts

Re: Software Engineering at Google (2020)

#71

Post by water-your-self »

danpalmer wrote: post #57
88913527 wrote: post #45

Earlier quoted context omitted.

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…

>if its google id be happy to try to persuade you via chat.

I would be curious as to how you view projects that are staffed entirely 20%.

Re: Software Engineering at Google (2020)

#72

Post by water-your-self »

danpalmer wrote: post #40
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…

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?

Re: Software Engineering at Google (2020)

#73

Post by [deleted] »

fractalb wrote: post #53
lapcat wrote: post #34

Earlier quoted context omitted.

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

[deleted]

Re: Software Engineering at Google (2020)

#74

Post by water-your-self »

ownagefool wrote: post #68
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…

Probably all of the above is true. From an outsiders, it looks like all of FAANG has scaled to the point where delivery, perf and managing the business has become quite cumbersome. This, I suspect is why they're all used the economic climate to cut back, as they largely are unable to see the benefit of the additional hiring. I have no doubt most of the talent is top tier, but being a strong engineer doesn't deliver p…

Hiring is always profitable as it lowers the average cost of your engineers. Layoffs are a way to accelerate that cost averaging.

Re: Software Engineering at Google (2020)

#75

Post by shadowgovt »

fsociety wrote: post #41
BurningFrog wrote: post #36

Earlier quoted context omitted.

If Google's code writing process really was superior, you'd expect them to consistently produce killer products in other fields. But I can't think of anything like that in the last 15 years.

Unfortunately good code does not mean a good product, and Google is anything but a good product company.

If anything, these are orthogonal.

I had a front-row seat to some really revolutionary ideas in Google getting to the prototype stage before being squashed in the gears of "We're chasing a market and that's not how users see this product working." Stuff where, if it caught on, it'd be a paradigm shift... But it turns out users don't want every paradigm shift that comes down the lane.

Because Google has (traditionally; this has changed in recent years) a real push-pull in authority between management and engineering leadership, the company can't commit fully to building a quality implementation of a status quo. Nor can it commit fully to chasing entirely new ways of doing things that could shake up an established market. In general, this... Actually kind of works out fine for them, more fine than critics often realize, because neither of those answers are always correct. Sometimes you get Gmail. Sometimes you get Google Drive. And sometimes you get iGoogle or Wave. And sometimes you get the stuff in between, like Reader or App Engine (really popular among the users, but the users don't have the money to make it profitable to commit to it).

Re: Software Engineering at Google (2020)

#76

Post by danpalmer »

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?

Most engineers create tools, Google is not special in that way.

But even when there's a similar open-source tool, it may be difficult to integrate with internal systems. There's a lot of benefit to a consistent set of technologies (data formats, storage systems, etc) so that's often a reason to write internally.

There is a lot of open source software in use at Google so I wouldn't say there's a lot of reinventing the wheel. And when there is an internal clone, the requirements are often necessarily different enough to warrant writing an internal version.

Re: Software Engineering at Google (2020)

#77

Post by marcyb5st »

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

DISCLAIMER 1: Current Googler here, but opinions are my own.

DISCLAIMER 2: I think from a hands-on-keyboard SWE there is a lot of useful stuff. What you mentioned about Google culture of killing products and such I am not gonna talk about.

I recommend chapters about testing first and foremost. Among all the codebases I saw (both OS and proprietary) Google tests are the most comprehensive and reliable. However, If you are in a startup-like environment you should pick and choose and not try to follow every single principle listed as they could sink your velocity drastically in the short run.

Other interesting points (IMHO) are Monorepo, Build System, and Code Reviews.

For the Monorepo I discover being a huge lover although I was skeptical. The sad thing is that it's a rather niche practice and tools like Git don't play ball very well (i.e. each time you pull you have to retrieve changes for all the codebase, even files you never saw/heard of managed by another team). I think there's no nice off-the-shelf offering for running monorepos out there. However, not having to fight with git submodules, library versions, ... is great. If the change I am submitting breaks something else in the company you are immediately aware and so can act accordingly (e.g. keep the old implementation alongside the new one and mark it as deprecated so the other team will get a warning next time they do anything).

The build system is a bit more controversial. I learned to love blaze/bazel, but admittedly, the OS version is a bit messy to set up. Additionally, being so rigorous about the build rules felt like a massive chore at the beginning, but now I appreciate it a lot. I can instantly know the contacts of all the teams that use a build rule I declared and hence can be contacted to warn them about bugs, ... . I can create something experimental and have private visibility so only my team can use it and only later expose it to the wider world with just a one liner.

Finally, the code review AKA Critique. Google has the best review tool I had the joy to use hands down. It's clear about what happens, at which stage is the review of a particular section/file and is focused on discussion. The evolution of each change is easy to follow along. These are things I really miss when using GitHub/GitLab PR view. The tooling is incredibly confusing to me. Luckily (I am not affiliated in any way) an ex-Googler (I believe) is working on an alternative that works with GitHub (https://codeapprove.com/).

Re: Software Engineering at Google (2020)

#78

Post by secondcoming »

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…

C++ stdlib didn’t have string_view for ages. Also, until recently, C++ sucked for things like convert to/from strings and string buffers. std::stringstream is awful.

Re: Software Engineering at Google (2020)

#79

Post by danpalmer »

water-your-self wrote: post #71
danpalmer wrote: post #57

Earlier quoted context omitted.

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…

>if its google id be happy to try to persuade you via chat. I would be curious as to how you view projects that are staffed entirely 20%.

Feel free to reach out internally! But in general, it seems to work ok for many popular tools. I haven't attempted to do it, maybe it sucks as the maintainer?

Re: Software Engineering at Google (2020)

#80

Post by x86x87 »

7e wrote: post #54

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.

It depends how you look at it. A lot of products created by Google were good/high quality but were killed anyway. It's sad to see things being killed because they were not "big enough".
Post reply on HN