Read on Twitter
Finally received my pre-order. Looking forward to read it (if the kids give me some time :)). The SRE book was pretty good, hope to get some valuable information from the SWE side of things at Google.
I& #39;ve finally finished this book. I have to say that it exceeded my expectations. Not all chapters were great, but there was some eye opening chapters, such as the Chapter 21 about dependency management. There are many other points worth talking in this book. Highly recommended 
https://abs.twimg.com/emoji/v2/... draggable="false" alt="đź‘Ś" title="Ok hand" aria-label="Emoji: Ok hand">
Couple of notes from some of my favorite chapters:
Ch 10, Documentation: Do it like how #golang is doing it, keep it next to your source code, so it& #39;s maintainble **over time**. Make it easy for devs to contribute. We still have a long way until docs are treated important.
Ch 10, Documentation: Do it like how #golang is doing it, keep it next to your source code, so it& #39;s maintainble **over time**. Make it easy for devs to contribute. We still have a long way until docs are treated important.
Ch 11, Testing: Hyrum& #39;s Law effects everything ( https://www.hyrumslaw.com"> https://www.hyrumslaw.com ). Make sure you add tests for thinks you care. "If you liked it, you should have put a test on it" (see Beyonce& #39;s song). Grouping tests into small/ medium /large sizes is the key for efficient scalability.
Ch 12, Unit Testing: Test state, not interactions. Behaviors, not methods. Don& #39;t put logic in tests. Follow DAMP over DRY. This makes tests more readable over time. Tests are barely read, write them highly verbose. Optimize for the future reader.
Ch 15, Deprecation: Code is a liability, not an asset. Code has costs. Hyrum& #39;s Law is always in play, which affects the maintenance costs of systems over time. Removing is therefore difficult because users rely on feature beyond the systems original design.
Ch 16, Version Control: Trunk based (master branch) development is a large factor in high-performing organizations. Using long lived dev branches come with their own issues and are not a good plan.
Ch 17 Build systems: Taking power from users and giving them fewer options in their build system configuration makes it actually easier for developers to build their projects. Build systems around artifacts (blaze/bazel) tend to scale better than task based build system.
Ch 20 Static Analysis: Focus on developer happiness. Prioritize reducing false positives over anything. Empower users to contribute and create them their own linter. (shameless plug: in #golang you can do it via go/analysis https://arslan.io/2019/06/13/using-go-analysis-to-write-a-custom-linter/)">https://arslan.io/2019/06/1...
Ch 21 Dependency Management: Prefer source control problems over dep management problems. Owning the code gives you more stability and control over time. Dependency is a contract. Nothing is free. There is a give and take. Risk is not visible now, but will be in the future.
Ch 21 Dependency Management (cont.): SemVer + MSV (see #golang). It& #39;s the best thing we& #39;ve got if you don& #39;t have a monorepo. Providing a dependency isn& #39;t free either. Becomes a challenge for compatibility, i.e: keeping upstream up-to-date with internal version
Ch 25 Compute: Every company requires a compute platform. People have now more options compared to previous decades. Google internally prefers single/big clusters over many medium/small clusters. (comparable to monorepo vs polyrepo).
Ch 25 Compute(cont.): Batch jobs are essentially free due smart scheduling and intelligent resource usage. Kubernetes improves based from years of experience from Google, but it& #39;s still not perfect.
Recap: The book ( #flamingobook) is really good on exploring and explaining the lessons Google learnt over time. The whole notion about Software Engineering being "Programming over time" makes sense in Google scale. It might be not applicable for everyday user or OSS developer.
