# Hyrum Wright et al. - Software Engineering at Google (Highlights) ![rw-book-cover|256](https://learning.oreilly.com/library/view/software-engineering-at/9781492082781/ibis_generated_cover_thumbnail.jpg) ## Metadata **Cover**:: https://learning.oreilly.com/library/view/software-engineering-at/9781492082781/ibis_generated_cover_thumbnail.jpg **Source**:: #from/readwise **Zettel**:: #zettel/fleeting **Status**:: #x **Authors**:: [[Hyrum Wright]], [[Titus Winters]], [[Tom Manshreck]] **Full Title**:: Software Engineering at Google **Category**:: #books #readwise/books **Category Icon**:: 📚 **Highlighted**:: [[2021-02-02]] **Created**:: [[2022-09-26]] ## Highlights ### Preface - it’s OK for someone else to change your mind. - What practices can we introduce to our code to make it sustainable—able to react to necessary change—over its life cycle - BE OPEN TO INFLUENCE ### 1. What Is Software Engineering? - Choose your battles carefully: to be heard properly, you first need to listen to others. - Software engineering is programming integrated over time. - The more open you are to influence, the more you are able to influence; the more vulnerable you are, the stronger you appear. - The addition of time adds an important new dimension to programming. - Admitting that you’ve made a mistake or you’re simply out of your league can increase your status over the long run. - a software engineering task is a team effort - Googleyness - Your project is sustainable if, for the expected life span of your software, you are capable of reacting to whatever valuable change comes along, for either technical or business reasons. - Thrives in ambiguity - 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. - Can deal with conflicting messages or directions, build consensus, and make progress against a problem - For most projects, over a long enough time period, everything underneath them might need to be changed. - Values feedback - We shouldn’t change just for the sake of change. But we do need to be capable of change. - Challenges status quo - Site Reliability Engineering (SRE) book - Puts the user first - Your organization’s codebase is sustainable when you are able to change all of the things that you ought to change, safely, and can do so for the life of your codebase. ### 2. How to Work Well on Teams - Cares about the team - Does the right thing - before you can understand the bugs in your coworkers, you need to understand the bugs in yourself. - Be aware of the trade-offs of working in isolation. - insecurity is actually a symptom of a larger problem. - A small investment in understanding personalities and working styles of yourself and others can go a long way toward improving productivity. - Linus’ real achievement was to lead these people and coordinate their work - If you want to work effectively with a team or a large organization, be aware of your preferred working style and that of others. - The vast majority of the work at Google (and at most companies!) doesn’t require genius-level intellect, but 100% of the work requires a minimal level of social skills. #favorite - Chapter 2. How to Work Well on Teams - If you spend all of your time working alone, you’re increasing the risk of unnecessary failure and cheating your potential for growth. ### 3. Knowledge Sharing - Bus factor (noun): the number of people that need to get hit by a bus before your project is completely doomed. - Chapter 3. Knowledge Sharing - Hiding Considered Harmful - The Bus Factor - Lack of psychological safety - Early Detection - An environment in which people are afraid to take risks or make mistakes in front of others because they fear being punished for it. - Pace of Progress - Information islands - The Three Pillars of Social Interaction - Single point of failure (SPOF) - Pillar 1: Humility - All-or-nothing expertise - You are not the center of the universe (nor is your code!). - Parroting - Pillar 2: Respect - Mimicry without understanding. - Pillar 3: Trust - Haunted graveyards - LOSE THE EGO - Places, often in code, that people avoid touching or changing because they are afraid that something might go wrong. - LEARN TO GIVE AND TAKE CRITICISM - Setting the Stage: Psychological Safety - criticism is almost never personal - An enormous part of learning is being able to try things and feeling safe to fail. - You are not what you make. - a mentor—someone who is not their team member, manager, or tech lead - FAIL FAST AND ITERATE - Growing Your Knowledge - Failure is an option. - Knowledge sharing starts with yourself. - if you’re not failing now and then, you’re not being innovative enough or taking enough risks. - One of the biggest mistakes that beginners make is not to ask for help when they’re stuck. - Blameless Post-Mortem Culture - Understand Context - A good postmortem should include the following: - A brief summary of the event - A timeline of the event, from discovery through investigation to resolution - The primary cause of the event - Impact and damage assessment - A set of action items (with owners) to fix the problem immediately - A set of action items to prevent the event from happening again - Lessons learned. #favorite - the principle of “Chesterson’s fence”: before removing or changing something, first understand why it’s there. - Scaling Your Questions: Ask the Community - Scaling Your Knowledge: You Always Have Something to Teach - See the book Work Rules!10 for a more in-depth examination of Google’s culture. - Scaling Your Organization’s Knowledge - Establishing Canonical Sources of Information - Readability covers a wide breadth of expertise, including but not limited to language idioms, code structure, API design, appropriate use of common libraries, documentation, and test coverage. - Around 1 to 2% of Google engineers are readability reviewers. All reviewers are volunteers, and anyone with readability is welcome to self-nominate to become a readability reviewer.