The book itself is a bit abstract and generalised (on purpose I suppose).
People who have worked within Google vs not will think differently on how they can apply it in practice in their own company/team. Many of the practices that work very well at Google don't work as well elsewhere primarily due to bootstrapping problems. Google's developmental practice are built on top of so many layers of highly complex and large tech-infra capabilities that don't exist outside. The process/culture practices also have cyclic dependencies with those infra capabilities.
Interestingly, so many things that are quite easy everywhere else aren't so easy to do at Google. Software engineering within Google is painless in many of the usual sense of pains seen outside Google, but it has its own pains – some quite painful pains.
> Software engineering within Google is painless in many of the usual sense of pains seen outside Google, but it has its own pains some quite painful pains.
One simple example was that I couldn’t install dependencies from public registries such npmjs (npm) or pypi (pip). It took an approval process for an internal team to review and clone packages onto Google’s internal registry.
On the other hand, things like deployment and monitoring were so trivial and magic.
It is a pain point, but relevant for legal liability and tracking security concerns, else you quickly have wild west where it's unclear what kind of problems affect which team and how
Yeah, I kind of understand what that comment is saying but also feel like it can be interpreted in so many different actual ways that it's practically useless.
Interestingly, so many things that are quite easy everywhere else aren't so easy to do at Google. Software engineering within Google is painless in many of the usual sense of pains seen outside Google, but it has its own pains – some quite painful pains.