Quotes and notes from Software Engineering at Google

Hyrum’s 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.

I really enjoyed and learned a lot from this book.  I noted that, as is the case with many O'Reilly books about best practices at Google, different people will find various chapters more/less interesting and pertinent to them.

Below are the excerpts that I found most pertinent.
 

Leadership

• Contrary to some people’s instincts, leaders who admit mistakes are more respected, not less.
• If you perform root-cause analysis on almost any social conflict, you can ultimately trace it back to a lack of humility, respect, and/or trust.
• Your organization needs a culture of learning, which requires creating psychological safety that permits people to admit to a lack of knowledge.
• If you try to achieve an impossible goal, there’s a good chance you’ll fail, but if you fail to try to achieve the impossible, you’ll most likely accomplish far more than you would have accomplished had you merely attempted something you knew you could complete.
• “Sometimes you get to be the tooth fairy, other times you have to be the dentist.”
• As a leader, your job is to inspire, but inspiration is a 24/7 job. Your visible attitude about absolutely everything — no matter how trivial — is unconsciously noticed and spreads infectiously to your team.
• Your mission is to build a “self-driving” team
• Delegation: Ask yourself: What can I do that nobody else on my team can do?
• Learn to drop balls
  
• Lead at scale:

• Always be deciding
•  Identify the blinders
•  Identify key trade-offs
•  Decide, then iterate
•  Always be leaving

Testing

 “If you liked it, you should have put a CI test on it,” which we call “The Beyoncé Rule.”
 

Scalability

Jevons Paradox: consumption of a resource may increase as a response to greater efficiency in its use.

Maintainability

• Hyrum’s 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.
• There’s an old joke within Google that there are two ways of doing things: the one that’s deprecated, and the one that’s not yet ready.
  

Productivity

•  Process inefficiencies and other software-development tasks tend to scale up slowly. Be careful about boiled-frog problems.
•  Productivity metrics
•  What result are you expecting and why?
•  If the data supports your expected result, what action will be taken?
•  If we get a negative result, will appropriate action be taken?
•  Who is going to decide to take action on the result?  When?
•  Goals, signals, and metrics
•  Goal - the desired result.
•  Signal - things you may want to know but may not be measurable.
•  Metric - a proxy for a signal that is measurable.
•  “I love deadlines. I like the whooshing sound they make as they fly by.” Douglas Adams

Culture

The “googlyness rubric” is:
    •    Thrives in ambiguity
    •    Values feedback
    •    Challenges status quo
    •    Puts the user first
    •    Cares about the team
    •    Does the right thing

Usability

    •    Design for the user who will have the most difficulty using your product.