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.
Software Engineering at Google (2020)
41–50 of 352 posts
Re: Software Engineering at Google (2020)
#42Re: Software Engineering at Google (2020)
#43Earlier 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.
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)
#44Probably 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…
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…
Re: Software Engineering at Google (2020)
#46Cool. 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 -…
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…
Re: Software Engineering at Google (2020)
#48The "3. Thesis" section [0] seems empty. Anyone know what's up with that? [0] https://abseil.io/resources/swe-book/html/part1.html
This is an html copy of a physical book. In book, that's nothing unusual.
Re: Software Engineering at Google (2020)
#49Cool. 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.
Re: Software Engineering at Google (2020)
#50Google 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.