Live data from Hacker News

Software Engineering at Google (2020)

abseil.io

41–50 of 352 posts

Re: Software Engineering at Google (2020)

#41

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.

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.

Re: Software Engineering at Google (2020)

#43

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.

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.

> If Google's code writing process really was superior, you'd expect them to consistently produce killer products in other fields.

This is a very simplistic notion of what enables the creation of killer products. That has much more to do with understanding users' needs and identifying market opportunities. Good code writing processes are about code maintenance and scaling engineering effort, not dreaming up the next killer app.

Re: Software Engineering at Google (2020)

#44

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…

Just glancing at Dawn, which I never heard of until now, it appears their use of absl is similar in purpose to the way other Google open source projects use it: faced with the choice between requiring C++20 (or 17, or 14) or requiring only C++11 and using absl as a kind of polyfill, they chose the latter.

Re: Software Engineering at Google (2020)

#45

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

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.

Re: Software Engineering at Google (2020)

#46

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

"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 for slowly on-boarding junior people into a team, and introducing them to google coding style and practices. Eg, the senior, mentoring folks on the team do the reviews and bring the new person up to speed. I imagine it must work well in that context.

However, this breaks down when your entire team is new. How do you find somebody to review the code? All several million lines of the product that was acquired? Especially when it is written in multiple languages.

So we were basically locked out of the main corporate repo, unable to do anything productive. We finally figured out that there was a paved path with a git repo used by the kernel team (and android?) that had none of these hurdles, where we could put our code and get productive immediately.

Re: Software Engineering at Google (2020)

#47

"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-FAANG look like college senior undergrad projects. I think we should celebrate what Google has done for software engineering instead of nitpicking every little detail that they got wrong.

Re: Software Engineering at Google (2020)

#48

The "3. Thesis" section [0] seems empty. Anyone know what's up with that? [0] https://abseil.io/resources/swe-book/html/part1.html

It's just a separator page. Each of the parts is like that: https://abseil.io/resources/swe-book/html/part2.html

This is an html copy of a physical book. In book, that's nothing unusual.

Re: Software Engineering at Google (2020)

#49

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

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

Interesting -- having not had any experience inside Google I'm having difficulty painting a picture, could you give an example or two of some of these internal coups?

Re: Software Engineering at Google (2020)

#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.

Post reply on HN