Book Notes: Software Engineering at Google

I just finished reading Software Engineering at Google which was a fantastic read. For anyone in the space, I'd highly recommend it. Here are some of my notes I took down:

• “A programming task is often an act of individual creation, but a software engineering task is a team effort.l
• Hyrums Law: “With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.”
• “If you spend all of your time working alone, you’re increasing the risk of unnecessary failure and cheating your potential for growth”
• The Bus Factor: if you got hit by a bus today, would your project die with you? Share the knowledge
• “Relationships always outlast projects”
• Three pillars of social interactions: humility, respect, trust. Almost every social problem arises from a lack of one of these three things
• “You are not your code”
• When doing code reviews, ask questions about decisions instead of saying something is wrong. Ask for their thoughts on your feedback to instill reflection
• Ask questions! Don’t get stuck in a rut
• “Traditional managers worry about how to get things done, whereas great managers worry about what things get done (and trust their team to figure out how to do it).”
• It’s ok to fail. Failing at an impossible goal can still be good. The learnings along the way could be advantageous
• Ask questions when giving advice as a leader. Typically people don’t want you to solve their problems but instead help them solve it themselves
• In 1:1s, ask team members what they need. Doing so over a period of time will often prompt them to bring their laundry lists to you
• Don’t put high performing engineers in leadership roles if they don’t want it. You’ll lose a great engineer and gain a subpar manager
• Problems rarely work themselves out. Take action now
• Motivate people with autonomy, mastery, and purpose
• If something isn’t critical or time sensitive, delegate it so others can level up
• “A common mistake is to put a team in charge of a specific product rather than a general problem.”
• “As a leader, your most precious resource is your limi‐ ted pool of time, attention, and energy.”
• Your job as a leader is to do things only you can do. Delegate the rest
• “Always be deciding, always be leaving, always be scaling”
• “We should only measure a software process when a concrete decision will be made based on the outcome.”
• Style guide rules must:
  • Pull their own weight
  • Optimize for the reader (simple to read over simple to write)
  • Be consistent
  • Avoid error-prone and surprising constructs
• Always address reviewers remarks. Don’t just resolve the comment.
• All Pull Request summaries should have a concise one-liner describing the entire PR as the first thing in the summary
• Always describe the why. Engineers a year from now will not have the context like you do
• “If you have to explain something to someone more than once, it usually makes sense to document that process.”
• Tests should be as small and isolated as possible
• “Code is read far more than it is written”
• DAMP: Descriptive and meaningful phrases
• Tests should avoid helper functions and instead be completely self-contained. The extra verbosity helps readability and the user doesn’t have to leave the function to see what’s happening
• Unit tests should be unchanging and act as the source of truth for production code
• If you can’t test a function you’re adding, you need to refactor it. Code should be testable
• Use the real implementation over mocks when possible. You’ll catch more bugs this way, keep tests realistic and mirroring production, and won’t have to maintain the mocks
• “Code is a liability, not an asset”. It has costs.
• Deprecation warnings alone aren’t enough as these typically accumulate and lead to alert fatigue
• Users must have complete trust in your tools, otherwise they won’t use them
• Use pre-submit git hooks to speed up CI feedback loop (linting/formatting?)
• “The biggest risk to any software effort is that you end up building something that isn’t useful. The earlier and more frequently you get working software in front of real users, the quicker you get feedback to find out how valuable it really is.” - Martin Fowler
• smaller batches of changes result in higher quality; in other words, faster is safer.
• One release responsibility is to protect the product from the developers. When making trade-offs, the passion and urgency a developer feels about launching a new feature can never trump the user experience with an existing product.
• Disk swap latency is terrible. Kill processes that use too much swap
• You need to rightsize your applications and hardware automatically. Keeping that a manual process is very error prone when you get a spike of traffic or outgrow the hard-coded constraints you put in place