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.

Comments

  1. Feedback sent to me privately: There's one thing I disagree strongly with him about: the idea that root-causes of social conflicts always reduces to {insert personal characteristics}. Usually it's the opposite: incentives. It's not about the person, it's about the role they're put in. Conflicting incentive structures explains almost all of the conflict you see in companies. And it's much more productive to work on that, on aligning incentives, rather than telling people to change who they are. Plus since it's structural, that kind of change survives personnel changes.

    ReplyDelete

Post a Comment

Popular posts from this blog

Mentoring Club

How GitLab hires Engineers