Index

Symbols

@deprecated annotation, Preventing backsliding
@DoNotMock annotation, Prefer Realism Over Isolation

A

A/B diff tests, A/B Diff Regression Testing
- limitations of, Limitations
- running presubmit, Large Tests and the Developer Workflow
- of SUT behaviors, Verification
ABI compatibility, C++
Abseil, compatibility promises, Abseil
adversarial group interactions, Psychological Safety in Large Groups
advisory deprecations, Advisory Deprecation
AI (artificial intelligence)
- facial-recognition software, disadvantaging some populations, Building Multicultural Capacity
- seed data, biases in, Fidelity
airplane, parable of, The Parable of the Airplane
alert fatigue, Deprecation Warnings
“Always of leadership”
- Always be deciding, Always Be Deciding
  - decide, then iterate, Decide, Then Iterate
- Always be leaving, Always Be Leaving
- Always be scaling, Always Be Scaling
analysis results from code analyzers, Analysis Results
annotations, per-test, documenting ownership, Owning Large Tests
Ant, Task-Based Build Systems
- performing builds by providing tasks to command line, Task-Based Build Systems
- replacement by more modern build systems, Task-Based Build Systems
antipatterns in test suites, Test Scope
APIs
- API comments, Reference Documentation
- benefits of documentation to, Why Is Documentation Needed?
- C++, documentation for, Reference Documentation
- Code Search, exposure of, API Exposure
- conceptual documentation and, Conceptual Documentation
- declaring a type should not be mocked, Prefer Realism Over Isolation
- faking, Why Are Fakes Important?
- service UI backend providing public API, Reducing the size of your SUT at problem boundaries
- testing via public APIs, Test via Public APIs-Test via Public APIs
apologizing for mistakes, Lose the Ego
AppEngine example, exporting resources, Example: open sourcing gflags
Approval stamp from reviewers, Stage 5: Change Approvals (Scoring a Change)
approvals for code changes at Google, How Code Review Works at Google
architecting for failure, Architecting for Failure
artifact-based build systems, Artifact-Based Build Systems-Making external dependencies deterministic
- functional perspective, A functional perspective
- getting concrete with Bazel, Getting concrete with Bazel
- other nifty Bazel tricks, Other nifty Bazel tricks-Making external dependencies deterministic
- time, scale, and trade-offs, Time, Scale, Trade-Offs
asking questions, Ask Questions
- asking team members if they need anything, The Unexpected Question
- asking the community, Scaling Your Questions: Ask the Community-YAQS: Question-and-Answer Platform
- Zen management technique, Be a Zen Master
assertions
- among multiple calls to the system under test, Structure tests to emphasize behaviors
- in Java test, using Truth library, Write Clear Failure Messages
- stubbed functions having direct relationship with, When Is Stubbing Appropriate?
- test assertion in Go, Write Clear Failure Messages
- verifying behavior of SUTs, Verification
atomic changes, barriers to, Barriers to Atomic Changes-Testing
atomicity for commits in VCSs, What Is Version Control?, Centralized VCS
attention from engineers (QUANTS), Goals
audience reviews, Documentation Reviews
authoring large tests, Authoring Large Tests
authorization for large-scale changes, Authorization
automated build system, Purpose of a Build System
automated testing
- code correctness checks, Code Correctness
- limits of, The Limits of Automated Testing
automation
- automated A/B releases, Shifting Left: Making Data-Driven Decisions Earlier
- in continous integration, Automation-Continuous Delivery
- of code reviews, Automate Where Possible
automation of toil in CaaS, Automation of Toil-Automated scheduling
- automated scheduling, Automated scheduling
- simple automations, Simple automations
autonomy for team members, Intrinsic Versus Extrinsic Motivation
autoscaling, Rightsizing and autoscaling

B

backsliding, preventing in deprecation process, Preventing backsliding
backward compatibility and reactions to efficiency improvement, Why Not Just Aim for “Nothing Changes”?
batch jobs versus serving jobs, Batch Versus Serving
Bazel, Build Systems and Build Philosophy, Artifact-Based Build Systems
- dependency versions, Automatic versus manual dependency management
- extending the build system, Extending the build system
- getting concrete with, Getting concrete with Bazel
  - parallelization of build steps, Getting concrete with Bazel
  - performing builds with command line, Getting concrete with Bazel
  - rebuilding only minimum set of targets each time, Getting concrete with Bazel
- isolating the environment, Isolating the environment
- making external dependencies deterministic, Making external dependencies deterministic
- platform independence using toolchains, Tools as dependencies
- remote caching and reproducible builds, Remote caching
- speed and correctness, Purpose of a Build System
- tools as dependencies, Tools as dependencies
beginning, middle, and end sections for documents, The Beginning, Middle, and End
behaviors
- code reviews for changes in, Behavioral Changes, Improvements, and Optimizations
- testing instead of methods, Test Behaviors, Not Methods-Name tests after the behavior being tested
  - naming tests after behavior being tested, Name tests after the behavior being tested
  - structuring tests to emphasize behaviors, Structure tests to emphasize behaviors
- unanticipated, testing for, Unanticipated behaviors, inputs, and side effects
- updates to tests for changes in, Strive for Unchanging Tests
best practices, style guide rules enforcing, Enforcing best practices
Beyoncé Rule, Policies That Scale Well, The Beyoncé Rule
biases, Trade-offs and Costs
- small expressions of in interactions, Psychological Safety in Large Groups
- universal presence of, Bias Is the Default
binaries, interacting, functional testing of, Functional Testing of One or More Interacting Binaries
blameless postmortems, Blameless Post-Mortem Culture-Be open to influence, Today’s Engineering Manager
Blaze, Build Systems and Build Philosophy, Artifact-Based Build Systems
- global dependency graph, CI at Google
blinders, identifying, Identify the Blinders
- in Web Search latency case study, Decide, Then Iterate
Boost C++ library, compatibility promises, Boost
branch management, Branch Management-Release Branches
- branch names in VCSs, Why Is Version Control Important?
- dev branches, Dev Branches-How did we become addicted to dev branches?
- few long-lived branches at Google, (Nearly) No Long-Lived Branches
- release branches, Release Branches
- work in progress is akin to a branch, Work in Progress Is Akin to a Branch
“brilliant jerks”, Respect
brittle tests, The Pitfalls of a Large Test Suite
- preventing, Preventing Brittle Tests-Writing Clear Tests
  - striving for unchanging tests, Strive for Unchanging Tests
  - testing state, not interactions, Test State, Not Interactions
  - testing via public APIs, Test via Public APIs-Test via Public APIs
- record/replay systems causing, Hermetic Testing
- with overuse of stubbing, Tests become brittle
browser and device testing, Browser and Device Testing
Buck, Artifact-Based Build Systems
bug bashes, Bug bashes
bug fixes, Bug Fixes and Rollbacks, Strive for Unchanging Tests
bugs
- catching later in development, costs of, Testing Overview
- in real implementations causing cascade of test failures, Prefer Realism Over Isolation
- logic concealing a bug in a test, Don’t Put Logic in Tests
- not prevented by programmer ability alone, The Story of Google Web Server
BUILD files, reformatting, Code Formatters
build scripts
- difficulties of task-based build systems with, Difficulty maintaining and debugging scripts
- writing as tasks, Task-Based Build Systems
build systems, Build Systems and Build Philosophy-TL;DRs
- dealing with modules and dependencies, Dealing with Modules and Dependencies-Security and reliability of external dependencies
  - managing dependencies, Managing Dependencies-Security and reliability of external dependencies
  - minimizing module visibility, Minimizing Module Visibility
  - using fine-grained modules and 1:1:1 rule, Using Fine-Grained Modules and the 1:1:1 Rule
- modern, Modern Build Systems-Time, Scale, Trade-Offs
  - artifact-based, Artifact-Based Build Systems-Making external dependencies deterministic
  - dependencies and, It’s All About Dependencies
  - distributed builds, Distributed Builds-Distributed builds at Google
  - task-based, Task-Based Build Systems-Difficulty maintaining and debugging scripts
  - time, scale, and trade-offs, Time, Scale, Trade-Offs
- purpose of, Purpose of a Build System
- using other tools instead of, What Happens Without a Build System?-Shell Scripts to the Rescue?
  - compilers, But All I Need Is a Compiler!
  - shell scripts, Shell Scripts to the Rescue?
Builder pattern, Shared Values
buildfiles, Task-Based Build Systems
- build scripts and, Task-Based Build Systems
- in artifact-based build systems, Artifact-Based Build Systems
  - Bazel, Getting concrete with Bazel
building for everyone, Values Versus Outcomes
bundled distribution models, Bundled Distribution Models
bus factor, The Bus Factor, Always Be Leaving

C

C language, projects written in, changes to, Why Not Just Aim for “Nothing Changes”?
C++
- APIs, reference documentation for, Reference Documentation
- Boost library, compatibility promises, Boost
- compatibility promises, C++
- developer guide for Googlers, Documentation Reviews
- googlemock mocking framework, Mocking Frameworks
- open sourcing command-line flag libraries, Example: open sourcing gflags
- scoped_ptr to std::unique_ptr, Code Review
caching build results using external dependencies, Caching build results using external dependencies
CamelCase naming in Python, Changing the Rules
canary analysis, Probers and Canary Analysis
canarying, Fast Feedback Loops
canonical documentation, Documentation Is Like Code
careers, tracking for team members, The Unexpected Question
carrot-and-stick method of management, Manager Is a Four-Letter Word
catalyst, being, Be a Catalyst
cattle versus pets analogy
- applying to changes in a codebase, Sharding and Submitting
- applying to server management, Architecting for Failure
CD (see continuous delivery)
celebrity, The Genius Myth
centralization versus customization in compute services, Centralization Versus Customization-Need for customization
centralized version control systems (VCSs), Centralized VCS
- future of, Future of Version Control
- in-house-developed, Piper at Google, Version Control at Google
- operations scaling linearly with size of a change, Technical Limitations
- source of truth in, Source of Truth
- uncommitted local changes and committed changes on a branch, Work in Progress Is Akin to a Branch
change management for large-scale changes, Change Management
Changelist Search, Dashboard and search system
changelists (CLs), readability approval for, What Is the Readability Process?
changes to code
- change approvals or scoring a change, Stage 5: Change Approvals (Scoring a Change)
- change creation in LSC process, Change Creation
- commenting on, Commenting
- committing, Stage 6: Commiting a Change
- creating, Stage 1: Create a Change-Tight Tool Integration
- large-scale (see large-scale changes)
- tracking history of, After Commit: Tracking History
- tracking in VCSs, What Is Version Control?
- types of changes to production code, Strive for Unchanging Tests
- understanding the state of, Understanding the State of a Change-Dashboard and search system
- writing good change descriptions, Write Good Change Descriptions
- writing small changes, Write Small Changes
chaos and uncertainty, shielding your team from, Other Tips and Tricks
chaos engineering, The Beyoncé Rule, Disaster Recovery and Chaos Engineering
Chesterson’s fence, principle of, Understand Context
Churn Rule, Policies That Don’t Scale
clang-tidy, Error Checkers
- integration with Tricorder, Integrated Tools
class comments, Class comments
classes and tech talks, Tech Talks and Classes
classical testing, Real Implementations
“clean” and “maintainable” code, Example: Hash Ordering
cleanup in LSC process, Cleanup
clear tests, writing, Writing Clear Tests-Tests and Code Sharing: DAMP, Not DRY
- leaving logic out of tests, Don’t Put Logic in Tests
- making large tests understandable, Making tests understandable
- making tests complete and concise, Make Your Tests Complete and Concise
- testing behaviors, not methods, Test Behaviors, Not Methods-Name tests after the behavior being tested
  - behavior-driven test, Test Behaviors, Not Methods
  - method-driven test, Test Behaviors, Not Methods
  - naming tests after behavior being tested, Name tests after the behavior being tested
  - structuring tests to emphasize behaviors, Structure tests to emphasize behaviors
- writing clear failure messages, Write Clear Failure Messages
“clever” code, Example: Hash Ordering
Clojure package management ecosystem, Motivations
cloud providers, public versus private, Public Versus Private
coaching a low performer, Antipattern: Ignore Low Performers
code
- benefits of testing, Benefits of Testing Code-Benefits of Testing Code
- code as a liability, not an asset, Code Review Flow, Why Deprecate?
- embedding documentation in with g3doc, Documentation Is Like Code
- expressing tests as, Write, Run, React
- knowledge sharing with, Code
- quality of, Goals
code coverage, A Note on Code Coverage
code formatters, Code Formatters
code reviews, Code, Readability: Standardized Mentorship Through Code Review-Why Have This Process?, Code Review-TL;DRs
- benefits of, Code Review, Code Review Benefits-Knowledge Sharing
  - code consistency, Code Consistency
  - comprehension of code, Comprehension of Code
  - correctness of code, Code Correctness
  - knowledge sharing, Knowledge Sharing
  - psychological and cultural, Psychological and Cultural Benefits
- best practices, Code Review Best Practices-Automate Where Possible
  - automating where possible, Automate Where Possible
  - being polite and professional, Be Polite and Professional
  - keeping reviewers to a minimum, Keep Reviewers to a Minimum
  - writing good change descriptions, Write Good Change Descriptions
  - writing small changes, Write Small Changes
- code as a liability, Code Review Flow
- flow, Code Review Flow
- for large-scale changes, Code Review, Reviewing
- how they work at Google, How Code Review Works at Google-How Code Review Works at Google
- ownership of code, How Code Review Works at Google-How Code Review Works at Google
- steps in, Code Review Flow
- types of, Types of Code Reviews-Refactorings and Large-Scale Changes
  - behavioral changes, improvements, and optimizations, Behavioral Changes, Improvements, and Optimizations
  - bug fixes and rollbacks, Bug Fixes and Rollbacks
  - greenfield reviews, Greenfield Code Reviews
  - refactorings and large-scale changes, Refactorings and Large-Scale Changes
Code Search, Write Good Change Descriptions, Code Search-TL;DRs
- Google's implementation, Google’s Implementation-Result diversity
  - ranking, Ranking-Result diversity
  - search index, Search Index
- how Googlers use it, How Do Googlers Use Code Search?-Who and When?
  - answering where something is in the codebase, Where?
  - answering who and when someine introduced code, Who and When?
  - answering why code is behaving in unepected ways, Why?
  - asnwering how others have done something, How?
  - asnwering what a part of the codebase is doing, What?
- impact of scale on design, Impact of Scale on Design-Index Latency
  - index latency, Index Latency
  - search query latency, Search Query Latency
- reasons for a separate web tool, Why a Separate Web Tool?-API Exposure
  - integration with other developer tools, Integration with Other Developer Tools-API Exposure
  - scale of Google's codebase, Scale
  - specialization, Specialization
  - zero setup global code view, Zero Setup Global Code View
- trade-offs in implementing, Selected Trade-Offs-Expressiveness: Token Versus Substring Versus Regex
  - completeness, all vs. most-relevant results, Completeness: All Versus Most-Relevant Results
  - completeness, head vs. branches vs. all history vs. workspaces, Completeness: Head Versus Branches Versus All History Versus Workspaces
  - completeness, repository at head, Completeness: Repository at Head
  - expressiveness, token vs. substring vs. regex, Expressiveness: Token Versus Substring Versus Regex
- UI, The Code Search UI
code sharing, tests and, Tests and Code Sharing: DAMP, Not DRY-Defining Test Infrastructure
- defining test infrastructure, Defining Test Infrastructure
- shared helpers and validation, Shared Helpers and Validation
- shared setup, Shared Setup
- shared values, Shared Values
- test that is too DRY, Tests and Code Sharing: DAMP, Not DRY
- tests should be DAMP, Tests and Code Sharing: DAMP, Not DRY
codebase
- analysis of, large-scale changes and, Codebase Insight
- comments in, reference documentation generated from, Reference Documentation
- factors affecting flexibility of, Example: Compiler Upgrade
- scalability, Scale and Efficiency
- sustainability, Scale and Efficiency
- value of codebase-wide consistency, Why Have This Process?
codelabs, Codelabs
commenting on changes in Critique, Commenting
comments
- code, Reference Documentation
- style guide rules for, Optimize for the reader
communities
- cross-organizational, sharing knowledge in, Communities
- getting help from the community, Scaling Your Questions: Ask the Community-YAQS: Question-and-Answer Platform
compiler integration with static analysis, Compiler Integration
compiler upgrage (example), Example: Compiler Upgrade-Example: Compiler Upgrade
compilers, using instead of build systems, But All I Need Is a Compiler!
completeness and conciseness in tests, Make Your Tests Complete and Concise
completeness, accuracy, and clarity in documentation, The Parameters of Good Documentation
comprehension of code, Comprehension of Code
compulsory deprecation, Compulsory Deprecation
Compute as a Service (CaaS), Compute as a Service-TL;DRs
- choosing a compute service, Choosing a Compute Service-Public Versus Private
  - centralization versus customization, Centralization Versus Customization-Need for customization
  - level of abstraction, serverless, Level of Abstraction: Serverless-The trade-off
  - public versus private, Public Versus Private
- over time and scale, CaaS Over Time and Scale-Submitted Configuration
  - containers as an abstraction, Containers as an Abstraction-Containers and implicit dependencies
  - one service to rule them all, One Service to Rule Them All
  - submitted configuration, Submitted Configuration
- taming the compute environment, Taming the Compute Environment-Summary
  - automation of toil, Automation of Toil-Automated scheduling
  - containerization and multitenancy, Containerization and Multitenancy-Rightsizing and autoscaling
- writing software for managed compute, Writing Software for Managed Compute-One-Off Code
  - architecting for failure, Architecting for Failure
  - batch versus serving, Batch Versus Serving
  - connecting to a service, Connecting to a Service
  - managing state, Managing State
  - one-off code, One-Off Code
conceptual documentation, Conceptual Documentation
condescending and unwelcoming behaviors, Psychological Safety in Large Groups
configuration issues with unit tests, Configuration issues
consensus, building, Be a Catalyst
consistency within the codebase, Be consistent
- advantages of, Advantages of consistency
- building in consistency, rules for, Building in consistency
- ensuring with code reviews, Code Consistency
- exceptions to, conceding to practicalities, Concede to practicalities
- inefficiency of perfect consistency in very large codebase, Advantages of consistency
- One-Version Rule and, The “One-Version” Rule
- setting the standard, Setting the standard
constructive criticism, Learn to give and take criticism
consumer-driven contract tests, Record/replay proxies
containerization and multitenancy, Containerization and Multitenancy-Rightsizing and autoscaling
- rightsizing and autoscaling, Rightsizing and autoscaling
containers as an abstraction, Containers as an Abstraction-Containers and implicit dependencies
- containers and implicit dependencies, Containers and implicit dependencies
context, understanding, Understand Context
continuous build (CB), Continuous Build
continuous delivery (CD), Continuous Delivery, Continuous Delivery-TL;DRs
- breaking up deployment into manageable pieces, Velocity Is a Team Sport: How to Break Up a Deployment into Manageable Pieces
- changing team culture to build disclipline into deployment, Changing Team Culture: Building Discipline into Deployment
- evaluating changes in isolation, flag-guarding features, Evaluating Changes in Isolation: Flag-Guarding Features
- idioms of CD at Google, Idioms of Continuous Delivery at Google
- quality and user-focus, shipping only what gets used, Quality and User-Focus: Ship Only What Gets Used
- shifting left and making data-driven decisions earlier, Shifting Left: Making Data-Driven Decisions Earlier
- striving for agility, setting up a release train, Striving for Agility: Setting Up a Release Train-Meet Your Release Deadline
continuous deployment (CD), release branches and, Release Branches
continuous integration (CI), Policies That Scale Well, Continuous Integration-TL;DRs
- alerting, Production testing-Hermetic Testing
  - CI challenges, CI Challenges
  - hermetic testing, Hermetic Testing
- core concepts, CI Concepts-Production testing
  - automation, Automation-Continuous Delivery
  - continuous testing, Continuous Testing-Production testing
  - fast feedback loops, Fast Feedback Loops-Accessible and actionable feedback
- dev branches and, Dev Branches
- greenfield reviews necessitating for a project, Greenfield Code Reviews
- implementation at Google, CI at Google-But I Can’t Afford CI
  - case study, Google Takeout, CI Case Study: Google Takeout-Further challenges
  - TAP, global continuous build, CI at Google-CI at Google
- Live at Head dependency management and, Live at Head
- system at Google, Testing at Google Scale
contract fakes, Fakes Should Be Tested
cooperative group interactions, Psychological Safety in Large Groups
correctness in build systems, Purpose of a Build System
correctness of code, Code Correctness
costs
- in software engineering, Scale and Efficiency
- reducing by finding problems earlier in development, Shifting Left
- trade-offs and, Trade-offs and Costs-Revisiting Decisions, Making Mistakes
  - deciding between time and scale (example), Example: Deciding Between Time and Scale
  - distributed builds (example), Example: Distributed Builds
  - inputs to decision making, Inputs to Decision Making, Inputs to Decision Making
  - mistakes in decision making, Revisiting Decisions, Making Mistakes
  - types of costs, Trade-offs and Costs
  - whiteboard markers (example), Example: Markers
criticism, learning to give and take, Learn to give and take criticism
Critique code review tool, Code Review, The Code Search UI, Critique: Google’s Code Review Tool-TL;DRs
- change approvals, Stage 5: Change Approvals (Scoring a Change)
- code review flow, Code Review Flow
- code review tooling principles, Code Review Tooling Principles
- committing a change, Stage 6: Commiting a Change
- creating a change, Stage 1: Create a Change-Tight Tool Integration
  - analysis results, Analysis Results
  - diffing, Diffing
  - tight tool ingegration, Tight Tool Integration
- diff viewer, Tricorder warnings on, Tricorder: Google’s Static Analysis Platform
- request review, Stage 2: Request Review-Stage 2: Request Review
- understanding and commenting on a change, Stages 3 and 4: Understanding and Commenting on a Change-Dashboard and search system
- view of static analysis fix, Suggested Fixes
cryptographic hashes, Making external dependencies deterministic
culprit finding and failure isolation, CI Challenges
- using TAP, CI at Google
culture
- building discipline into deployment, Changing Team Culture: Building Discipline into Deployment
- changes in norms surrounding LSCs, Policies and Culture
- cultivating knowledge-sharing culture, Cultivating a Knowledge-Sharing Culture-Incentives and recognition
- cultural benefits of code reviews, Psychological and Cultural Benefits
- culture of learning, Knowledge Sharing
- data-driven, Example: Markers, Revisiting Decisions, Making Mistakes
- healthy automated testing culture, Write, Run, React
- testing culture today at Google, Testing Culture Today
customers, documentation for, Types of Audiences
CVS (Concurrent Versions System), What Is Version Control?, Centralized VCS

D

DAMP, Tests and Code Sharing: DAMP, Not DRY
- complementary to DRY, not a replacement, Tests and Code Sharing: DAMP, Not DRY
- test rewritten to be DAMP, Tests and Code Sharing: DAMP, Not DRY
dashboard and search system (Critique), Dashboard and search system
data structures in libraries, listings of, Guidance
data-driven culture
- about, Example: Markers
- admitting to mistakes, Revisiting Decisions, Making Mistakes
data-driven decisions, making earlier, Shifting Left: Making Data-Driven Decisions Earlier
datacenters, automating management of, Summary
debugging versus testing, The Story of Google Web Server
decisions
- admitting to making mistakes, Revisiting Decisions, Making Mistakes
- deciding, then iterating, Decide, Then Iterate
- in an engineering group, justifications for, Example: Markers
- inputs to decision making, Inputs to Decision Making
- making at higher levels of leadership, Always Be Deciding
delegation of subproblems to team leaders, Delegating subproblems to leaders
dependencies
- Bazel treating tools as dependencies to each target, Tools as dependencies
- build systems and, It’s All About Dependencies
- construction when using real implementations in tests, Dependency construction
- containers and implicit dependencies, Containers and implicit dependencies
- dependency management versus version control, Version Control Versus Dependency Management
- external, causing nondeterminism in tests, Determinism
- external, compilers and, But All I Need Is a Compiler!
- forking/reimplementing versus adding a dependency, Example: Deciding Between Time and Scale
- in task-based build systems, Task-Based Build Systems
- making external dependencies deterministic in Bazel, Making external dependencies deterministic
- managing for modules in build systems, Managing Dependencies-Security and reliability of external dependencies
  - automatic vs. manual management, Automatic versus manual dependency management
  - caching build results using external dependencies, Caching build results using external dependencies
  - external dependencies, External dependencies
  - internal dependencies, Internal dependencies
  - One-Version Rule, The One-Version Rule
  - security and reliability of external dependencies, Security and reliability of external dependencies
  - transitive external dependencies, Transitive external dependencies
- new, preventing introduction into deprecated system, Preventing backsliding
- on values in shared setup methods, Shared Setup
- replacing all in a class with test doubles, Prefer Realism Over Isolation
- test scope and, Test Scope
- unknown, discovering during deprecation, Compulsory Deprecation
dependency injection
- frameworks for, Seams
- introducing seams with, Seams
dependency management, Dependency Management-TL;DRs
- difficulty of, reasons for, Why Is Dependency Management So Difficult?-Conflicting Requirements and Diamond Dependencies
  - conflicting requirements and diamond dependencies, Conflicting Requirements and Diamond Dependencies-Conflicting Requirements and Diamond Dependencies
- importing dependencies, Importing Dependencies-How Google Handles Importing Dependendencies
  - compatibility promises, Compatibility Promises-Boost
  - considerations in, Considerations When Importing
  - Google's handling of, How Google Handles Importing Dependendencies-How Google Handles Importing Dependendencies
- in theory, Dependency Management, In Theory-Live at Head
  - bundled distribution models, Bundled Distribution Models
  - Live at Head, Live at Head
  - nothing changes (static dependency model), Nothing Changes (aka The Static Dependency Model)
  - semantic versioning, Semantic Versioning
- limitations of semantic versioning, The Limitations of SemVer-So, Does SemVer Work?
  - Minimum Version Selection, Minimum Version Selection
  - motivations, Motivations
  - overconstrains, SemVer Might Overconstrain
  - overpromising compatibility, SemVer Might Overpromise
  - questioning whether it works, So, Does SemVer Work?
- with infinite resources, Dependency Management with Infinite Resources-Example: open sourcing gflags
  - exporting dependencies, Exporting Dependencies-Example: open sourcing gflags
deployment
- breaking up into manageable pieces, Velocity Is a Team Sport: How to Break Up a Deployment into Manageable Pieces
- building discipline into, Changing Team Culture: Building Discipline into Deployment
deployment configuration testing, Deployment Configuration Testing
deprecation, Deprecation-TL;DRs
- as example of scaling problems, Policies That Don’t Scale
- difficulty of, Why Is Deprecation So Hard?-Why Is Deprecation So Hard?
- during design, Deprecation During Design
- managing the process, Managing the Deprecation Process-Preventing backsliding
  - deprecation tooling, Deprecation Tooling-Preventing backsliding
  - milestones, Milestones
  - process owners, Process Owners
- of old documentation, Deprecating Documents
- preventing new uses of deprecated object, Cleanup
- reasons for, Why Deprecate?
- static analysis in API deprecation, Static Analysis
- types of, Types of Deprecation-Deprecation Warnings
  - advisory deprecation, Advisory Deprecation
  - compulsory deprecation, Compulsory Deprecation
  - deprecation warnings, Deprecation Warnings
Descriptive And Meaningful Phrases (see DAMP)
design documents, Design Docs
design reviews for new code or projects, Greenfield Code Reviews
designing systems to eventually be deprecated, Deprecation During Design
determinism in tests, Determinism
dev branches, Dev Branches-How did we become addicted to dev branches?
- no long-lived branches and, (Nearly) No Long-Lived Branches
developer guides, Developer guides
developer happiness, focus on, with static analysis, Focus on Developer Happiness
developer tools, Code Search integration with, Integration with Other Developer Tools-API Exposure
developer workflow, large tests and, Large Tests and the Developer Workflow-Owning Large Tests
- authoring large tests, Authoring Large Tests
- running large tests, Running Large Tests-Making tests understandable
  - driving out flakiness, Driving out flakiness
  - making tests understandable, Making tests understandable
  - owning large tests, Owning Large Tests
  - speeding up tests, Speeding up tests
developer workflow, making static analysis part of, Make Static Analysis a Part of the Core Developer Workflow
DevOps
- philosophy on tech productivity, Pace of Progress
- trunk-based development popularized by, Version Control and Branch Management
DevOps Research and Assessment (DORA)
- no long-lived branches and, (Nearly) No Long-Lived Branches
- predictive relationship between trunk-based development and high-performing organizations, (Nearly) No Long-Lived Branches
- research on release branches, Release Branches
diamond dependency issue, The One-Version Rule, Conflicting Requirements and Diamond Dependencies-Conflicting Requirements and Diamond Dependencies
diffing code changes, Diffing
- change summary and diff view, Analysis Results
direction, giving to team members, People Are Like Plants
disaster recovery testing, Disaster Recovery and Chaos Engineering
discovery (in deprecation), Discovery
distributed builds, Distributed Builds-Distributed builds at Google
- at Google, Distributed builds at Google
- remote caching, Remote caching
- remote execution, Remote execution
- trade-offs and costs example, Example: Distributed Builds
distributed version control systems (DVCSs), Distributed VCS
- compression of historical data, Completeness: Head Versus Branches Versus All History Versus Workspaces
- scenario, no clear source of truth, Scenario: no clear source of truth
- source of truth, Source of Truth
diversity
- making it actionable, Making Diversity Actionable
- understanding the need for, Understanding the Need for Diversity
Docker, Containers as an Abstraction
documentation, Documentation-Promoting documentation, Documentation-TL;DRs
- about, What Qualifies as Documentation?
- benefits of, Why Is Documentation Needed?-Why Is Documentation Needed?
- code, Code
- Code Search integration in, Integration with Other Developer Tools
- creating, Creating documentation
- for code changes, Write Good Change Descriptions
- knowing your audience, Know Your Audience-Types of Audiences
  - types of audiences, Types of Audiences
- philosophy, Documentation Philosophy-Deprecating Documents
  - beginning, middle, and end sections, The Beginning, Middle, and End
  - deprecating documents, Deprecating Documents
  - parameters of good documentation, The Parameters of Good Documentation
  - who, what, why, when, where, and how, WHO, WHAT, WHEN, WHERE, and WHY
- promoting, Promoting documentation
- treating as code, Documentation Is Like Code-Documentation Is Like Code
  - Google wiki and, Documentation Is Like Code
- types of, Documentation Types-Landing Pages
  - conceptual, Conceptual Documentation
  - design documents, Design Docs
  - landing pages, Landing Pages
  - reference, Reference Documentation-Function comments
  - tutorials, Tutorials
- updating, Updating documentation
- when you need technical writers, When Do You Need Technical Writers?
documentation comments, Optimize for the reader
documentation reviews, Documentation Reviews-Documentation Reviews
documented knowledge, Philosophy
domain knowledge of documentation audiences, Types of Audiences
DRY (Don’t Repeat Yourself) principle
- tests and code sharing, DAMP, not DRY, Tests and Code Sharing: DAMP, Not DRY-Defining Test Infrastructure
  - DAMP as complement to DRY, Tests and Code Sharing: DAMP, Not DRY
  - test that is too DRY, Tests and Code Sharing: DAMP, Not DRY
- violating for clearer tests, Make Your Tests Complete and Concise
DVCSs (see distributed version control systems)

E

Edison, Thomas, Fail fast and iterate
education of software engineers, Understanding the Need for Diversity
- more inclusive education needed, Building Multicultural Capacity
efficiency improvements, changing code for, Why Not Just Aim for “Nothing Changes”?
ego, losing, Lose the ego, Lose the Ego
Eisenhower, Dwight D., Important Versus Urgent
email at Google, Mailing Lists
Emerson, Ralph Waldo, Concede to practicalities
end-to-end tests, Test Scope
engineering managers, The Engineering Manager, The Engineering Manager-Today’s Engineering Manager, Antipatterns
- (see also leading a team; managers and tech leads)
- contemporary managers, Today’s Engineering Manager
- letting the team know failure is an option, Today’s Engineering Manager
- manager as four-letter word, Manager Is a Four-Letter Word
engineering productivity
- improving with testing, Unit Testing
- readability program and, Why Have This Process?
Engineering Productivity Research (EPR) team, Why Have This Process?
engineering productivity, measuring, Measuring Engineering Productivity-TL;DRs
- assessing worth of measuring, Triage: Is It Even Worth Measuring?-Triage: Is It Even Worth Measuring?
- goals, Goals
- metrics, Metrics
- reasons for, Why Should We Measure Engineering Productivity?-Why Should We Measure Engineering Productivity?
- selecting meaningful metrics with goals and signals, Selecting Meaningful Metrics with Goals and Signals-Selecting Meaningful Metrics with Goals and Signals
- signals, Signals
- taking action and tracking results after performing research, Taking Action and Tracking Results
- validating metrics with data, Using Data to Validate Metrics-Taking Action and Tracking Results
equitable and inclusive engineering, Engineering for Equity-TL;DRs
- bias and, Bias Is the Default
- building multicultural capacity, Building Multicultural Capacity-Building Multicultural Capacity
- challenging established processes, Challenge Established Processes
- making diversity actionable, Making Diversity Actionable
- need for diversity, Understanding the Need for Diversity
- racial inclusion, Bias Is the Default
- rejecting singular approaches, Reject Singular Approaches
- staying curious, and pushing forward, Stay Curious, Push Forward
- values versus outcomes, Values Versus Outcomes
error checking tools, Error Checkers
Error Prone tool (Java), Error Checkers
- @DoNotMock annotation, Prefer Realism Over Isolation
- integration with Tricorder, Integrated Tools
error-prone and surprising constructs in code, avoiding, Avoid error-prone and surprising constructs
execution time for tests, Execution time
- speeding up tests, Speeding up tests
experience levels for documentation audiences, Types of Audiences
experiments and feature flags, Fast Feedback Loops
expertise
- all-or-nothing, Challenges to Learning
- personalized advice from an expert, Philosophy
- and shared communication forums, Policies That Scale Well
exploitation versus exploration problem, Query independent signals
exploratory testing, The Limits of Automated Testing, Exploratory Testing
extrinsic versus intrinsic motivation, Intrinsic Versus Extrinsic Motivation

F

“Fail early, fail fast, fail often”, Early Detection
failures
- addressing test failures, Write, Run, React
- architecting for failure in software for managed compute, Architecting for Failure
- bug in real implementation causing cascade of test failures, Prefer Realism Over Isolation
- clear code aiding in diagnosing test failures, Properties common to all test sizes
- culprit finding and failure isolation, CI Challenges
- fail fast and iterate, Fail fast and iterate
- failure is an option, Today’s Engineering Manager
- failure management with TAP, CI at Google
- large test that fails, Making tests understandable
- reasons for test failures, Writing Clear Tests
- testing for system failure, The Beyoncé Rule
- writing clear failure messages for tests, Write Clear Failure Messages
faking, Faking, Faking-What to Do If a Fake Is Not Available
- fake hermetic backend, Hermetic Testing
- fidelity of fakes, The Fidelity of Fakes
- importance of fakes, Why Are Fakes Important?
- testing fakes, Fakes Should Be Tested
- when fakes are not available, What to Do If a Fake Is Not Available
- when to write fakes, When Should Fakes Be Written?
false negatives in static analysis, Focus on Developer Happiness
false positives in static analysis, Focus on Developer Happiness
feature flags, Fast Feedback Loops
features, new, Strive for Unchanging Tests
federated/virtual-monorepo (VMR)–style repository, Monorepos
feedback
- accelerating pace of progress with, Pace of Progress
- fast feedback loops in CI, Fast Feedback Loops-Accessible and actionable feedback
- for documentation, Creating documentation
- giving hard feedback to team members, Be Honest
- integrated feedback channels in Tricorder, Integrated Feedback Channels
- soliciting from developers on static analysis, Focus on Developer Happiness
fidelity
- of fakes, The Fidelity of Fakes
- of SUTs, The System Under Test
- of test doubles, The Impact of Test Doubles on Software Development
- of tests, Fidelity
file comments, File comments
file locking in VCSs, What Is Version Control?, Centralized VCS
filesystem abstraction, Containers as an Abstraction
filesystems, VCS as way to extend, Why Is Version Control Important?
flag-guarding features, Evaluating Changes in Isolation: Flag-Guarding Features
flaky tests, Small tests, Determinism, CI Challenges
- driving out flakiness in large tests, Driving out flakiness
- expense of, Large tests
Forge, Distributed builds at Google, CI at Google
forking/reimplementing versus adding a dependency, Example: Deciding Between Time and Scale
function comments, Function comments
functional programming languages, A functional perspective
functional tests, Test Scope
- testing of one or more interacting binaries, Functional Testing of One or More Interacting Binaries

G

g3doc, Documentation Is Like Code
Gates, Bill, The Genius Myth
generated files, Code Search index and, Completeness: Repository at Head
Genius Myth, The Genius Myth
Gerrit code review tool, After Commit: Tracking History
Git, Distributed VCS
- improvements to, Future of Version Control
- synthesizing monorepo behavior, Monorepos
given/when/then, expressing behaviors, Test Behaviors, Not Methods
- alternating when/then blocks, Structure tests to emphasize behaviors
- well-structured test with, Structure tests to emphasize behaviors
Go programming language
- compatibility promises, Go
- gofmt tool case study, Code Formatters-Code Formatters
- standard package management ecosystem, Motivations
- test assertion in, Write Clear Failure Messages
go/ links, go/ links
- use with canonical documentation, Documentation Is Like Code, Documentation Reviews
goals
- defined, Selecting Meaningful Metrics with Goals and Signals
- team leader setting clear goals, Set Clear Goals
Goals/Signals/Metrics (GSM) framework, Selecting Meaningful Metrics with Goals and Signals-Metrics
- goals, Goals
- metrics, Metrics
- signals, Signals
- use for metrics in readability process study, Using Data to Validate Metrics
Google Assistant, Hermetic Testing
Google Search, Time and Change
- and bifurcation of Google's internal compute offering, Need for customization
- larger tests at Google, Larger Tests at Google
- manually testing functionality of, Testing at the Speed of Modern Development
- subdividing latency problem of, Example: Subdividing the “latency problem” of Google Search
Google Takeout case study, CI Case Study: Google Takeout-Further challenges
Google Web Server (GWS), The Story of Google Web Server
Google wiki (GooWiki), Documentation Is Like Code
“Googley”, being, Being Googley
Gradle, Task-Based Build Systems
- dependency versions, Automatic versus manual dependency management
- improvements on Ant, Task-Based Build Systems
greenfield code reviews, Greenfield Code Reviews
grep command, The Code Search UI
group chats, Group Chats
Grunt, Task-Based Build Systems

H

“hacky” or “clever” code, Example: Hash Ordering
Hamming, Richard, Why Do These Pillars Matter?, Lose the ego
happiness, tracking for your team, Track Happiness
- outside the office and in their careers, The Unexpected Question
hash flooding attacks, Example: Hash Ordering
hash ordering (example), Example: Hash Ordering
haunted graveyards, Challenges to Learning, No Haunted Graveyards
Heartbleed, Why Not Just Aim for “Nothing Changes”?
“Hello World” tutorials, Tutorials
helper methods
- shared helpers and validation, Shared Helpers and Validation
- shared values in, Shared Values
hermetic code, nondeterminism and, Determinism
hermetic SUTs, The System Under Test
- benefits of, The benefits of hermetic SUTs
hermetic testing, Hermetic Testing
- Google Assistant, Hermetic Testing
hero worship, The Genius Myth
hiding your work
- Genius Myth and, The Genius Myth
- harmful effects of, Hiding Considered Harmful-In Short, Don’t Hide
  - bus factor, The Bus Factor
  - engineers and offices, Pace of Progress
  - forgoing early detection of flaws or issues, Early Detection
  - pace of progress, Pace of Progress
hiring of software engineers
- compromising the hiring bar (antipattern), Antipattern: Compromise the Hiring Bar
- hiring pushovers (antipattern), Antipattern: Hire Pushovers
- making diversity actionable, Making Diversity Actionable
history, indexing in Code Search, Completeness: Head Versus Branches Versus All History Versus Workspaces
honesty, being honest with your team, Be Honest
“Hope is not a strategy”, Antipattern: Ignore Low Performers
hourglass antipattern in testing, Test Scope
human issues, ignoring in a team, Antipattern: Ignore Human Issues
human problems, solving, The Genius Myth
humility, The Three Pillars of Social Interaction
- being “Googley”, Being Googley
- practicing, Humility, Respect, and Trust in Practice-Fail fast and iterate
hybrid SUTs, The System Under Test
Hyrum's Law, Hyrum’s Law
- consideration in unit tests, Unanticipated behaviors, inputs, and side effects
- deprecation and, Why Is Deprecation So Hard?
- hash ordering (example), Example: Hash Ordering

I

ice cream cone antipattern in testing, Test Scope, Larger Tests and Time
idempotency, Connecting to a Service
IDEs (integrated development environments)
- reasons for using Code Search instead of, Why a Separate Web Tool?-API Exposure
- static analysis and, Analysis While Editing and Browsing Code
image recognition, racial inclusion and, Bias Is the Default
imperative programming languages, A functional perspective
implementation comments, Optimize for the reader, Reference Documentation
important versus urgent problems, Important Versus Urgent
improvements to existing code, code reviews for, Behavioral Changes, Improvements, and Optimizations
incentives and recognition for knowledge sharing, Incentives and recognition
incremental builds, difficulty in task-based build systems, Difficulty performing incremental builds
indexes
- Code Search versus IDEs, Scale
- dropping files from Code Search index, Completeness: Repository at Head
- indexing multiple versions of a repository, Completeness: Head Versus Branches Versus All History Versus Workspaces
- latency in Code Search, Index Latency
- search index in Code Search, Search Index
individual engineers, increasing productivity of, Why Should We Measure Engineering Productivity?
influence, being open to, Be open to influence
influencing without authority (case study), The Tech Lead Manager
information islands, Challenges to Learning
information, canonical sources of, Establishing Canonical Sources of Information-Static analysis
- codelabs, Codelabs
- developer guides, Establishing Canonical Sources of Information
- go/ links, go/ links
- static analysis, Static analysis
insecurity, Help Me Hide My Code
- criticism and, Learn to give and take criticism
- manifestation in Genius Myth, The Genius Myth
integration tests, Test Scope
intellectual complexity (QUANTS), Goals
interaction testing, Test State, Not Interactions, Interaction Testing-Conclusion
- appropriate uses of, When Is Interaction Testing Appropriate?
- best practices, Best Practices for Interaction Testing
  - avoiding overspecification, Avoid overspecification
  - performing only for state-changing functions, Prefer to perform interaction testing only for state-changing functions
- preferring state testing over, Prefer State Testing Over Interaction Testing
  - limitations of interaction testing, Prefer State Testing Over Interaction Testing
- using test doubles, Interaction Testing
interoperability of code, Concede to practicalities
intraline diffing showing character-level differences, Diffing
intrinsic versus extrinsic motivation, Intrinsic Versus Extrinsic Motivation
iteration, making your teams comfortable with, Decide, Then Iterate

J

Java
- assertion in a test using Truth library, Write Clear Failure Messages
- javac compiler, But All I Need Is a Compiler!
- Mockito mocking framework for, Mocking Frameworks
- shading in, Scenario: Multiple Available Versions
- third-party JAR files, But All I Need Is a Compiler!
Jevons Paradox, Example: Distributed Builds
Jobs, Steve, The Genius Myth, Antipattern: Compromise the Hiring Bar
Jordan, Michael, The Genius Myth
JUnit, Authoring Large Tests

K

key abstractions and data structures in libraries, listings of, Guidance
knowledge sharing, Knowledge Sharing-TL;DRs
- as benefit of code reviews, Knowledge Sharing
- asking the community, Scaling Your Questions: Ask the Community-YAQS: Question-and-Answer Platform
- challenges to learning, Challenges to Learning
- critical role of psychological safety, Setting the Stage: Psychological Safety-Psychological Safety in Large Groups
- growing your knowledge, Growing Your Knowledge, Understand Context
  - asking questions, Ask Questions
  - understanding context, Understand Context
- increasing knowledge by working with others, The Bus Factor
- philosophy of, Philosophy
- readability process and code reviews, Applying the Rules
- scaling your organization's knowledge, Scaling Your Organization’s Knowledge-Communities
  - cultivating knowledge-sharing culture, Cultivating a Knowledge-Sharing Culture-Incentives and recognition
  - establishing canonical sources of information, Establishing Canonical Sources of Information-Static analysis
  - staying in the loop, Staying in the Loop-Communities
- standardized mentorship through code reviews, Readability: Standardized Mentorship Through Code Review-Why Have This Process?
- teaching others, Scaling Your Knowledge: You Always Have Something to Teach-Code
Kondo, Marie, Learn to Drop Balls
Kubernetes clusters, One Service to Rule Them All
kudos, Incentives and recognition
Kythe, Codebase Insight
- integration with Code Search, Code Search
- navigating cross-references with, Tight Tool Integration

L

landing pages, Landing Pages
Large Scale Change tooling and processes, Advantages of consistency
large tests, Large tests
- (see also larger testing)
large-scale changes, Purpose of a Build System, Large-Scale Changes-TL;DRs
- barriers to atomic changes, Barriers to Atomic Changes-Testing
  - heterogeneity, Heterogeneity
  - merge conflicts, Merge Conflicts
  - no haunted graveyards, No Haunted Graveyards
  - technical limitations, Technical Limitations
  - testing, Testing
- code reviews for, Refactorings and Large-Scale Changes
- importance of trunk-based development and, (Nearly) No Long-Lived Branches
- infrastructure, LSC Infrastructure-LSC Infrastructure
  - change management, Change Management
  - codebase insight, Codebase Insight
  - language support, Language Support
  - Operation RoseHub, LSC Infrastructure
  - policies and culture, Policies and Culture
  - testing, Testing
- larger tests skipped during, Why Not Have Larger Tests?
- process, The LSC Process-Cleanup
  - authorization, Authorization
  - change creation, Change Creation
  - cleanup, Cleanup
  - sharding and submitting, Sharding and Submitting-Submitting
- qualities of, What Is a Large-Scale Change?
- responsibility for, Who Deals with LSCs?-Who Deals with LSCs?
- testing, Testing-Code Review
  - code reviews, Code Review
  - riding the TAP train, Testing
  - scoped_ptr to std::unique_ptr, Code Review
larger testing, Larger Testing-TL;DRs
- advantages of, What Are Larger Tests?
- challenges and limitations of, Why Not Have Larger Tests?
- characteristics of, What Are Larger Tests?
- fidelity of tests, Fidelity
- large tests and developer workflow, Large Tests and the Developer Workflow-Owning Large Tests
  - authoring large tests, Authoring Large Tests
  - running large tests, Running Large Tests-Making tests understandable
- larger tests at Google, Larger Tests at Google-Structure of a Large Test
  - Google scale and, Larger Tests at Google Scale
  - time and, Larger Tests and Time
- structure of a large test, Structure of a Large Test-Verification
  - systems under test (SUTs), The System Under Test-Record/replay proxies
  - test data, Test Data
  - verification, Verification
- types of large tests, Types of Larger Tests-User Evaluation
  - A/B diff (regression), A/B Diff Regression Testing
  - browser and device testing, Browser and Device Testing
  - deployment configuration testing, Deployment Configuration Testing
  - disaster recovery and chaos engineering, Disaster Recovery and Chaos Engineering
  - exploratory testing, Exploratory Testing
  - functional testing of interacting binaries, Functional Testing of One or More Interacting Binaries
  - performance, load, and stress testing, Performance, Load, and Stress testing
  - probers and canary analysis, Probers and Canary Analysis
  - UAT, UAT
  - user evaluation, User Evaluation
- unit tests not providing good risk mitigation coverage, Common Gaps in Unit Tests-Emergent behaviors and the “vacuum effect”
law enforcement facial recognition databases, racial bias in, Building Multicultural Capacity
leadership, brilliant jerks and, Respect
leadership, scaling into a really good leader, Leading at Scale-TL;DRs
- Addressing Web Search latency (case study), Decide, Then Iterate-Decide, Then Iterate
- Always be deciding, Always Be Deciding
- Always be leaving, Always Be Leaving
- Always be scaling, Always Be Scaling
- deciding, then iterating, Decide, Then Iterate
- identifying key trade-offs, Identify the Key Trade-Offs
- identifying the blinders, Identify the Blinders
- important vs. urgent problems, Important Versus Urgent-Important Versus Urgent
- learning to drop balls, Learn to Drop Balls
- protecting your energy, Protecting Your Energy
leading a team, How to Lead a Team-TL;DRs
- antipatterns, Antipatterns-Antipattern: Treat Your Team Like Children
  - being everyone's friend, Antipattern: Be Everyone’s Friend
  - compromising the hiring bar, Antipattern: Compromise the Hiring Bar
  - hiring pushovers, Antipattern: Hire Pushovers
  - ignoring human issues, Antipattern: Ignore Human Issues
  - ignoring low performers, Antipattern: Ignore Low Performers
  - treating your team like children, Antipattern: Treat Your Team Like Children
- asking team members if they need anything, The Unexpected Question
- engineering manager, The Engineering Manager-Today’s Engineering Manager
  - failure as an option, Today’s Engineering Manager
  - history of managers, Manager Is a Four-Letter Word
  - today's manager, Today’s Engineering Manager
- fulfilling different needs of team members, People Are Like Plants
  - motivation, Intrinsic Versus Extrinsic Motivation
- managers and tech leads, Managers and Tech Leads (and Both)-The Tech Lead Manager
  - case study, influencing without authority, The Tech Lead Manager
  - engineering manager, The Engineering Manager
  - tech lead, The Tech Lead
  - tech lead manager, The Tech Lead Manager
- moving from individual contributor to leadership role, Moving from an Individual Contributor Role to a Leadership Role-Servant Leadership
  - reasons people don't want to be managers, The Only Thing to Fear Is…Well, Everything
  - servant leadership, Servant Leadership
- other tips and tricks for, Other Tips and Tricks
- positive patterns, Positive Patterns-Track Happiness
  - being a catalyst, Be a Catalyst
  - being a teacher and mentor, Be a Teacher and a Mentor
  - being a Zen master, Be a Zen Master
  - being honest, Be Honest
  - losing the ego, Lose the Ego
  - removing roadblocks, Remove Roadblocks
  - setting clear goals, Set Clear Goals
  - tracking happiness, Track Happiness
learning, Philosophy
- (see also knolwedge sharing)
- challenges to, Challenges to Learning
LGTM (looks good to me) stamp from reviewers, Code Review Flow
- change approval with, Code Review Flow
- code owner's approval and, How Code Review Works at Google
- correctness and comprehension checks, How Code Review Works at Google
- from primary reviewer, Write Small Changes
- meaning of, Stage 5: Change Approvals (Scoring a Change)
- separation from readability approval, Code Consistency
- tech leads submitting code change after, How Code Review Works at Google
libraries, compilers and, But All I Need Is a Compiler!
linters in Tricorder, Per-Project Customization
Linux
- developers of, The Genius Myth
- kernel patches, sources of truth for, Scenario: no clear source of truth
Live at Head model, Live at Head
load, testing, Performance, Load, and Stress testing
log viewer, Code Search integration with, Integration with Other Developer Tools
logic, not putting in tests, Don’t Put Logic in Tests
LSCs (see large-scale changes)

M

mailing lists, Mailing Lists
maintainability of tests, Unit Testing
“manageritis”, Moving from an Individual Contributor Role to a Leadership Role
managers and tech leads, Managers and Tech Leads (and Both)-The Tech Lead Manager
- antipatterns, Antipatterns-Antipattern: Treat Your Team Like Children
  - being everyone's friend, Antipattern: Be Everyone’s Friend
  - compromising the hiring bar, Antipattern: Compromise the Hiring Bar
  - hiring pushovers, Antipattern: Hire Pushovers
  - ignoring human issues, Antipattern: Ignore Human Issues
  - ignoring low performers, Antipattern: Ignore Low Performers
  - treating your team like children, Antipattern: Treat Your Team Like Children
- case study, influencing without authority, The Tech Lead Manager
- engineering manager, The Engineering Manager, The Engineering Manager-Today’s Engineering Manager
  - contemporary, Today’s Engineering Manager
  - failure as an option, Today’s Engineering Manager
  - history of managers, Manager Is a Four-Letter Word
- moving from individual contributor to leadership role, Moving from an Individual Contributor Role to a Leadership Role-Servant Leadership
  - reasons people don't want to be managers, The Only Thing to Fear Is…Well, Everything
  - servant leadership, Servant Leadership
- positive patterns, Positive Patterns-Track Happiness
  - being a catalyst, Be a Catalyst
  - being a teacher and mentor, Be a Teacher and a Mentor
  - being a Zen master, Be a Zen Master
  - being honest, Be Honest
  - losing the ego, Lose the Ego
  - removing roadblocks, Remove Roadblocks
  - setting clear goals, Set Clear Goals
  - tracking happiness, Track Happiness
- tech lead, The Tech Lead
- tech lead manager (TLM), The Tech Lead Manager
manual testing, Larger Tests and Time
Markdown, Documentation Is Like Code
mastery for team members, Intrinsic Versus Extrinsic Motivation
Maven, Task-Based Build Systems
- improvements on Ant, Task-Based Build Systems
measurements, Measuring Engineering Productivity
- (see also engineering productivity, measuring)
- in hard-to-quantify areas, Inputs to Decision Making
medium tests, Medium tests
Meltdown and Spectre, Why Not Just Aim for “Nothing Changes”?
mentorship, Mentorship
- being a teacher and mentor for your team, Be a Teacher and a Mentor
- standardized, through code reviews, Readability: Standardized Mentorship Through Code Review-Why Have This Process?
merge conflicts, size of changes and, Merge Conflicts
merges
- branch-and-merge process, development as, Why Is Version Control Important?
- coordination of dev branch merging, How did we become addicted to dev branches?
- dev branches and, Dev Branches
- merge tracking in VCSs, What Is Version Control?
method-driven tests, Test Behaviors, Not Methods
- example test, Test Behaviors, Not Methods
- sample method naming patterns, Name tests after the behavior being tested
metrics
- assessing worth of measuring, Triage: Is It Even Worth Measuring?-Triage: Is It Even Worth Measuring?
- in GSM framework, Selecting Meaningful Metrics with Goals and Signals, Metrics
- meaningful, selecting with goals and signals, Selecting Meaningful Metrics with Goals and Signals-Selecting Meaningful Metrics with Goals and Signals
- using data to validate, Using Data to Validate Metrics-Taking Action and Tracking Results
migrations
- in the deprecation process, Migration
- migrating users from an obsolete system, Compulsory Deprecation
milestones of a deprecation process, Milestones
Minimum Version Selection (MVS), Minimum Version Selection
mobile devices, browser and device testing, Browser and Device Testing
mocking, Test Doubles
- (see also test doubles)
- interaction testing and, Interaction Testing
- misuse of mock objects, causing brittle tests, The Pitfalls of a Large Test Suite
- mocks becoming stale, Unfaithful doubles
mocking frameworks
- about, Mocking Frameworks
- for major programming languages, Mocking Frameworks
- interaction testing done via, Interaction Testing
- over reliance on, Test State, Not Interactions, Test Doubles at Google
- stubbing via, Stubbing
mockist testing, Real Implementations
Mockito
- example of use, Mocking Frameworks
- stubbing example, Stubbing
modules, dealing with in build systems, Dealing with Modules and Dependencies-Security and reliability of external dependencies
- managing dependencies, Managing Dependencies-Security and reliability of external dependencies
- minimizing module visibility, Minimizing Module Visibility
- using fine-grained modules and 1:1:1 rule, Using Fine-Grained Modules and the 1:1:1 Rule
monorepos, Monorepos
- arguments against, Future of Version Control
- organizations citing benefits of, Future of Version Control
motivating your team, People Are Like Plants
- intrinsic vs. extrinsic motivation, Intrinsic Versus Extrinsic Motivation
move detection for code chunks, Diffing
multicultural capacity, building, Building Multicultural Capacity-Building Multicultural Capacity
- how inequalities in society impact workplaces, Making Diversity Actionable
multimachine SUT, The System Under Test
multitenancy, containerization and, My neighbor’s dog barks in my RAM-Rightsizing and autoscaling
- multitenancy for serving jobs, Multitenancy for serving jobs
multitenant framework servers, What is serverless?

N

named resources, managing on the machine, Containers as an Abstraction
network ports, containers and, Containers as an Abstraction
newsletters, Newsletters
no binary is perfect, No Binary Is Perfect
non-state-changing functions, Prefer to perform interaction testing only for state-changing functions
nondeterministic behavior in tests, Small tests, Large tests, Determinism
notifications from Critique, Notifications

O

office hours, using for knowledge sharing, Office Hours
1:1:1 rule, Using Fine-Grained Modules and the 1:1:1 Rule
one-off code, One-Off Code
One-Version Rule, One Version, The “One-Version” Rule, The One-Version Rule
- monorepos and, Monorepos
Open Source Software (OSS)
- dependency management and, Dependency Management
- monorepos and, Future of Version Control
open sourcing gflags, Example: open sourcing gflags
Operation RoseHub, LSC Infrastructure
optimizations of existing code, code reviews for, Behavioral Changes, Improvements, and Optimizations
overspecification of interaction tests, Avoid overspecification
ownership of code, How Code Review Works at Google-How Code Review Works at Google
- deprecation process owners, Process Owners
- for greenfield reviews, Greenfield Code Reviews
- granular ownership in Google monorepo, Version Control at Google
- owning large tests, Owning Large Tests

P

Pact Contract Testing, Record/replay proxies
Pants, Artifact-Based Build Systems
parallelization of build steps
- difficulty in task-based systems, Difficulty of parallelizing build steps
- in Bazel, Getting concrete with Bazel
parallelization of tests, Execution time
parroting, Challenges to Learning
Pascal, Blaise, Types of Audiences
patience and kindness in answering questions, Ask Questions
patience, learning, Learn patience
peer bonuses, Incentives and recognition
Perforce, revision mumbers for a change, Work in Progress Is Akin to a Branch
performance
- accommodating optimizations in the codebase, Concede to practicalities
- testing, Performance, Load, and Stress testing
performance of software engineers
- flaws in performance ratings, Challenge Established Processes
- ignoring low performers, Antipattern: Ignore Low Performers
personnel costs, Trade-offs and Costs
“Peter Principle”, The Only Thing to Fear Is…Well, Everything
Piper, Version Control at Google
- Code Search integration with, The Code Search UI
- tools built on top of, Tight Tool Integration
policies for large-scale changes, Policies and Culture
politeness and professionalism in code reviews, Be Polite and Professional
postmortems, blameless, Blameless Post-Mortem Culture-Be open to influence, Today’s Engineering Manager
precommit reviews, Code Review Flow
presubmits, Automate Where Possible
- checks in Tricorder, Presubmits
- continuous testing and, Why presubmit isn’t enough
- infrastructure for large tests, Running Large Tests
- optimization of, CI Challenges, CI at Google
- testing on merges in dev branch, Dev Branches
- versus postsubmit, Presubmit versus post-submit
probers, Probers and Canary Analysis
problems
- dividing the problem space, Dividing the Problem Space-Take care in anchoring a team’s identity
- important vs. urgent, Important Versus Urgent
product stability, dev branches and, Dev Branches
production
- risks of testing in, The benefits of hermetic SUTs
- testing in, Production testing
professionalism in code reviews, Be Polite and Professional
programming
- clever code and, Example: Hash Ordering
- software engineering versus, What Is Software Engineering?, Software Engineering Versus Programming
programming guidance, Guidance
programming languages
- advice for areas more difficult to get correct, Guidance
- avoiding use of error-prone and surprising constructs, Avoid error-prone and surprising constructs
- breakdowns of new feature and advice on using them, Guidance
- documenting, The Parameters of Good Documentation
- imperative and functional, A functional perspective
- limitations on new and not-yet-well-understood features, Enforcing best practices
- logic in, Don’t Put Logic in Tests
- reference documentation, Reference Documentation
- style guides for each language, Style Guides and Rules
- support for large-scale changes, Language Support
Project Health (pH) tool, Testing Culture Today
project-level customization in Tricorder, Per-Project Customization
Proto Best Practices analyzer, Per-Project Customization
protocol buffers static analysis of, Per-Project Customization
providers, documentation for, Types of Audiences
psychological benefits of code reviews, Psychological and Cultural Benefits
psychological safety, Setting the Stage: Psychological Safety-Psychological Safety in Large Groups
- building through mentorship, Mentorship
- catalyzing your team by building, Today’s Engineering Manager
- in large groups, Psychological Safety in Large Groups
- lack of, Challenges to Learning
pubic versus private compute services, Public Versus Private
public APIs, Test via Public APIs
purpose for team members, Intrinsic Versus Extrinsic Motivation
purpose of documentation users, Types of Audiences
Python, The Genius Myth
- unittest.mock framework for, Mocking Frameworks
Python style guides
- avoidance of power features such as reflection, Avoid error-prone and surprising constructs
- CamelCase vs. snake_case naming, Changing the Rules
- indentation of the code, Setting the standard

Q

qualitative metrics, Using Data to Validate Metrics
quality and user-focus in CD, Quality and User-Focus: Ship Only What Gets Used
quality of code, Goals
QUANTS in engineering productivity metrics, Goals
- in readability process study, Using Data to Validate Metrics
query dependent signals, Query dependent signals
query independent signals, Query independent signals
question-and-answer system (YAQS), YAQS: Question-and-Answer Platform
questions, asking (see asking questions)

R

racial bias in facial recognition databases, Building Multicultural Capacity
racial inclusion, Bias Is the Default
Rake, Task-Based Build Systems
ranking in Code Search, Ranking-Result diversity
- query dependent signals, Query dependent signals
- query independent signals, Query independent signals
- result diversity, Result diversity
- retrieval, Retrieval
RCS (Revision Control System), What Is Version Control?, Centralized VCS
readability, Code, Readability: Standardized Mentorship Through Code Review-Why Have This Process?
- approval for code changes at Google, How Code Review Works at Google
- ensuring with code reviews, Code Consistency
- readability process, Code
  - about, What Is the Readability Process?
  - advantages of, Why Have This Process?
real implementations, using instead of test doubles, Real Implementations-Dependency construction
- deciding when to use real implementations, How to Decide When to Use a Real Implementation-Dependency construction
  - dependency construction, Dependency construction
  - determinism in tests, Determinism
  - execution time, Execution time
- preferring realism over isolation, Prefer Realism Over Isolation
recall bias, Using Data to Validate Metrics
recency bias, Using Data to Validate Metrics
recognition for knowledge sharing, Incentives and recognition
recommendations on research findings, Taking Action and Tracking Results
record/replay systems, Record/replay proxies, Hermetic Testing
redundancy in documentation, The Beginning, Middle, and End
refactorings, Strive for Unchanging Tests
- code reviews for, Refactorings and Large-Scale Changes
- large-scale, and use of references for ranking, Query independent signals
- search-and-replace–based, Index Latency
- uncommitted work as akin to a branch, Work in Progress Is Akin to a Branch
reference documentation, Reference Documentation-Function comments
- class comments, Class comments
- file comments, File comments
- function comments, Function comments
references, using for ranking, Query independent signals
regression tests, A/B Diff Regression Testing
- (see also A/B diff tests)
regular expressions (regex) search, Expressiveness: Token Versus Substring Versus Regex
reimplementing/forking versus adding a dependency, Example: Deciding Between Time and Scale
release branches, Release Branches
- Google and, What About Release Branches?
release candidate testing, Release candidate testing
releases
- striving for agility, setting up a release train, Striving for Agility: Setting Up a Release Train
  - meeting your release deadline, Meet Your Release Deadline
  - no binary is perfect, No Binary Is Perfect
reliability of external dependencies, Security and reliability of external dependencies
remote caching in distributed builds, Remote caching
- Google's remote cache, Distributed builds at Google
remote execution of distributed builds, Remote execution
- Google remote execution system, Forge, Distributed builds at Google
repositories, What Is Version Control?
- central repository for a project in DVCSs, Distributed VCS
- finer-grained vs. monorepos, Monorepos
repository branching, not used at Google, Testing at Google Scale
representative testing, Shifting Left: Making Data-Driven Decisions Earlier
resource constraints, CI and, CI Challenges
respect, The Three Pillars of Social Interaction
- being “Googley”, Being Googley
- practicing, Humility, Respect, and Trust in Practice-Fail fast and iterate, Respect
result diversity in search, Result diversity
retrieval, Retrieval
reviewers of code, keeping to a minimum, Keep Reviewers to a Minimum
rightsizing and autoscaling, Rightsizing and autoscaling
risks
- making failure an option, Today’s Engineering Manager
- of working alone, Hiding Considered Harmful
roadblocks, removing, Remove Roadblocks
rollbacks, Bug Fixes and Rollbacks
Rosie tool, Change Management
- sharding and submitting in LSC process, Sharding and Submitting-Submitting
rules governing code, Style Guides and Rules
- categories of rules in style guides
  - rules building in consistency, Building in consistency
  - rules enforcing best practices, Enforcing best practices
  - rules to avoid danger, Avoiding danger
  - topics not covered, And for everything else...
- changing, Changing the Rules-Exceptions
- enforcing, Applying the Rules-Conclusion
  - gofmt case study, Code Formatters-Code Formatters
  - using code formatters, Code Formatters
  - using error checkers, Error Checkers
- guiding principles for, Creating the Rules-Concede to practicalities
  - avoiding error-prone and surprising constructs, Avoid error-prone and surprising constructs
  - being consistent, Be consistent
  - conceding to practicalities, Concede to practicalities
  - optimizing for code reader, not the author, Optimize for the reader
  - rules must pull their weight, Rules must pull their weight
- reasons for having, Why Have Rules?
rules, defining in Bazel, Extending the build system

S

sampling bias, Using Data to Validate Metrics
sandboxing
- hermetic testing and, Hermetic Testing
- use by Bazel, Isolating the environment
satisfaction (QUANTS), Goals
scalability
- forking and, Example: Deciding Between Time and Scale
- of static analysis tools, Scalability
scale
- deciding between time and, Example: Deciding Between Time and Scale
- in software engineering, What Is Software Engineering?
- issues in software engineering, What Is Software Engineering?
scale and efficiency, Scale and Efficiency-Shifting Left
- compiler upgrade (example), Example: Compiler Upgrade-Example: Compiler Upgrade
- finding problems earlier in developer workflow, Shifting Left
- policies that don't scale, Policies That Don’t Scale
- policies that scale well, Policies That Scale Well
scaling
- enabled by consistency in the codebase, Advantages of consistency
- impact of scale on Code Search design, Impact of Scale on Design-Index Latency
scheduling, automated, Automated scheduling, Architecting for Failure
scope of tests, Test Scope-Test Scope, What Are Larger Tests?
- defining scope for a unit, Test via Public APIs
- smallest possible test, Larger Tests at Google Scale
scoped_ptr in C++, Code Review
scoring a change, Stage 5: Change Approvals (Scoring a Change)
seams, Seams
search index in Code Search, Search Index
search query latency, Code Search and, Search Query Latency
security
- of external dependencies, Security and reliability of external dependencies
- reacting to threats and vulnerabilities, Why Not Just Aim for “Nothing Changes”?
- risks introduced by external dependencies, Making external dependencies deterministic
seeded data, Test Data
seekers (of documentation), Types of Audiences
self-confidence, Lose the ego
self-driving team, building, Your Mission: Build a “Self-Driving” Team-Take care in anchoring a team’s identity
semantic version strings, Automatic versus manual dependency management
semantic versioning, Semantic Versioning
- limitations of, The Limitations of SemVer-So, Does SemVer Work?
  - Minimum Version Selection, Minimum Version Selection
  - motivations, Motivations
  - overconstrains, SemVer Might Overconstrain
  - overpromising compatibility, SemVer Might Overpromise
  - questioning if it works, So, Does SemVer Work?
SemVer (see semantic versioning)
servant leadership, Servant Leadership
serverless, Level of Abstraction: Serverless-The trade-off
- about, What is serverless?
- pros and cons of, Pros and cons
- serverless frameworks, Pros and cons
- trade-off, The trade-off
services, connecting to in software for managed compute, Connecting to a Service
serving jobs, Batch Versus Serving
- multitenancy for, Multitenancy for serving jobs
shading (in Java), Scenario: Multiple Available Versions
sharding and submitting in LSC process, Sharding and Submitting-Submitting
shared environment SUT, The System Under Test
shell scripts, using for builds, Shell Scripts to the Rescue?
shifting left, Shifting Left, Pace of Progress
- making data-driven decisions earlier, Shifting Left: Making Data-Driven Decisions Earlier
shipping only what gets used, Quality and User-Focus: Ship Only What Gets Used
signals
- defined, Selecting Meaningful Metrics with Goals and Signals
- Goals/Signals/Metrics (GSM) framework, Selecting Meaningful Metrics with Goals and Signals
single point of failure (SPOF), Challenges to Learning
- leader as, Always Be Leaving
single-machine SUT, The System Under Test
single-process SUT, The System Under Test
small fixes across the codebase with LSCs, Who Deals with LSCs?
small tests, Small tests, Unit Testing, What Are Larger Tests?
social interaction
- being “Googley”, Being Googley
- coaching a low performer, Antipattern: Ignore Low Performers
- group interaction patterns, Psychological Safety in Large Groups
- humility, respect, and trust in practice, Humility, Respect, and Trust in Practice-Fail fast and iterate
- pillars of, The Three Pillars of Social Interaction
- why the pillars matter, Why Do These Pillars Matter?
social skills, The Genius Myth
societal costs, Trade-offs and Costs
software engineering
- clever code and, Example: Hash Ordering
- concluding thoughts, Afterword-Afterword
- deprecation and, Deprecation
- programming versus, What Is Software Engineering?, Software Engineering Versus Programming
  - version control systems and, Why Is Version Control Important?
- scale and efficiency, Scale and Efficiency-Shifting Left
- time and change, Time and Change-Why Not Just Aim for “Nothing Changes”?
- trade-offs and costs, Trade-offs and Costs-Revisiting Decisions, Making Mistakes
software engineers
- code reviews and, Code Review Benefits
- offices for, Pace of Progress
source control
- dependency management and, Dependency Management
- Git as dominant system, Distributed VCS
- moving documentation to, Documentation Is Like Code
source of truth, Source of Truth-Scenario: no clear source of truth
- One Version as single source of truth, One Version
- scenario, no clear source of truth, Scenario: no clear source of truth
- work in progress and branches, Work in Progress Is Akin to a Branch
sparse n-gram solution, search index in Code Search, Search Index
speed in build systems, Purpose of a Build System
speeding up tests, Speeding up tests
Spring Cloud Contracts, Record/replay proxies
stack frames, Code Search integration in, Integration with Other Developer Tools
staged rollouts, Shifting Left: Making Data-Driven Decisions Earlier
standardization, lack of, in larger tests, Why Not Have Larger Tests?
state testing, Test State, Not Interactions
- preferring over interaction testing, Prefer State Testing Over Interaction Testing
state, managing, Managing State
state-changing functions, Prefer to perform interaction testing only for state-changing functions
static analysis, Static Analysis-TL;DRs
- effective, characteristics of, Characteristics of Effective Static Analysis-Usability
  - scalability, Scalability
  - usability, Usability
- examples of, Static Analysis
- making it work, key lessons in, Key Lessons in Making Static Analysis Work-Empower Users to Contribute
  - empowering users to contribute, Empower Users to Contribute
  - focus on developer happiness, Focus on Developer Happiness
  - making static analysis part of core developer workflow, Make Static Analysis a Part of the Core Developer Workflow
- Tricorder platform, Tricorder: Google’s Static Analysis Platform-Analysis While Editing and Browsing Code
  - analysis while editing and browsing code, Analysis While Editing and Browsing Code
  - compiler integration, Compiler Integration
  - integrated feedback channels, Integrated Feedback Channels
  - integrated tools, Integrated Tools
  - per-project customization, Per-Project Customization
  - presubmits, Presubmits
  - suggested fixes, Suggested Fixes
static analysis tools, Static analysis
- for code correctness, Code Correctness
static dependency model, Nothing Changes (aka The Static Dependency Model)
std::unique_ptr in C++, Enforcing best practices, Code Review
streetlight effect, Selecting Meaningful Metrics with Goals and Signals
stress testing, Performance, Load, and Stress testing
stubbing, Stubbing, Stubbing-When Is Stubbing Appropriate?
- appropriate use of, When Is Stubbing Appropriate?
- dangers of overusing, The Dangers of Overusing Stubbing
stumblers, documentation for, Types of Audiences
style arbiters, The Style Arbiters
style guides for code, Developer guides, Style Guides and Rules
- advantages of having rules, Why Have Rules?
- applying the rules, Applying the Rules-Conclusion
- categories of rules in, The Style Guide
  - rules building in consistency, Building in consistency
  - rules enforcing best practices, Enforcing best practices
  - rules to avoid danger, Avoiding danger
  - topics not covered, And for everything else...
- changing the rules, Changing the Rules-Exceptions
  - making exceptions to the rules, Exceptions
  - process for, The Process
  - style arbiters, The Style Arbiters
- creating the rules, Creating the Rules-Concede to practicalities
  - guiding principles, Guiding Principles-Concede to practicalities
- for each programming language, Style Guides and Rules
- programming guidance, Guidance
substring search, Expressiveness: Token Versus Substring Versus Regex
Subversion, Centralized VCS
success, cycle of, The Cycle of Success
suffix array-based solution, search index in Code Search, Search Index
supplemental retrieval, Retrieval
sustainability
- codebase, Scale and Efficiency
- forking and, Example: Deciding Between Time and Scale
- for software, What Is Software Engineering?
system tests, Test Scope
systems under test (SUTs), The System Under Test-Record/replay proxies
- dealing with dependent but subsidiary services, Record/replay proxies
- examples of, The System Under Test
- fidelity of tests to behavior of, Fidelity
- in functional test of interacting binaries, Functional Testing of One or More Interacting Binaries
- larger tests for, Larger Tests at Google Scale
- production vs. isolated hermetic SUTs, Authoring Large Tests
- reducing size at problem testing boundaries, Reducing the size of your SUT at problem boundaries
- risks of testing in production and Webdriver Torso, The benefits of hermetic SUTs
- scope of, test scope and, Larger Tests at Google Scale
- seeding the SUT state, Test Data
- verification of behavior, Verification

T

TAP (see Test Automation Platform)
task-based build systems, Task-Based Build Systems-Difficulty maintaining and debugging scripts
- dark side of, The dark side of task-based build systems
- difficulty maintaining and debugging build scripts, Difficulty maintaining and debugging scripts
- difficulty of parallelizing build steps, Difficulty of parallelizing build steps
- difficulty of performing incremental builds, Difficulty performing incremental builds
- time, scale, and trade-offs, Time, Scale, Trade-Offs
teacher and mentor, being, Be a Teacher and a Mentor
teams
- anchoring a team's identity, Take care in anchoring a team’s identity
- engineers and offices, opinions on, Pace of Progress
- Genius Myth and, The Genius Myth
- leading, How to Lead a Team
  - (see also leading a team)
- software engineering as team endeavor, It’s All About the Team-Conclusion
  - being “Googley”, Being Googley
  - blameless postmortem culture, Blameless Post-Mortem Culture-Be open to influence
  - humility, respect, and trust in practice, Humility, Respect, and Trust in Practice-Fail fast and iterate
  - pillars of social interaction, The Three Pillars of Social Interaction
  - why social interaction pillars matter, Why Do These Pillars Matter?
tech lead (TL), The Tech Lead
tech lead manager (TLM), The Tech Lead Manager
tech talks and classes, Tech Talks and Classes
techie-celebrity phenomenon, The Genius Myth
technical reviews, Documentation Reviews
technical writers, writing documentation, When Do You Need Technical Writers?
tempo and velocity (QUANTS), Goals
Test Automation Platform (TAP), Testing at Google Scale, CI at Google-CI at Google
- culprit finding, CI at Google
- failure management, CI at Google
- presubmit optimization, CI at Google
- resource constraints and, CI at Google
- testing LSC shards, Testing
- train model and testing of LSCs, Testing
test data for larger tests, Test Data
test doubles, Test Scope, Test Doubles-TL;DRs
- at Google, Test Doubles at Google
- example, Basic Concepts
- faking, Faking-What to Do If a Fake Is Not Available
- impact on software development, The Impact of Test Doubles on Software Development
- interaction testing, Interaction Testing-Conclusion
- mocking frameworks, Mocking Frameworks
- seams, Seams
- stubbing, Stubbing-When Is Stubbing Appropriate?
- techniques for using, Techniques for Using Test Doubles-Interaction Testing
  - faking, Faking
  - interaction testing, Interaction Testing
  - stubbing, Stubbing
- unfaithful, Unfaithful doubles
- using in brittle interaction test, Test State, Not Interactions
- using real implementations instead of, Real Implementations-Dependency construction
  - deciding when to use real implementation, How to Decide When to Use a Real Implementation-Dependency construction
  - preferring realism over isolation, Prefer Realism Over Isolation
test infrastructure, Defining Test Infrastructure
test instability, CI Challenges
test scope (see scope of tests)
test sizes, Test Size
- in practice, Test sizes in practice
- large tests, Large tests, What Are Larger Tests?
- medium tests, Medium tests
- properties common to all sizes, Properties common to all test sizes
- small tests, Small tests
- test scope and, Test Scope
- unit tests, Unit Testing
test suite, Why Do We Write Tests?
- large, pitfalls of, The Pitfalls of a Large Test Suite
test traffic, Test Data
testability
- testable code, Seams
- writing testable code early, Seams
testing, Testing Overview-TL;DRs
- as barrier to atomic changes, Testing
- at Google scale, Testing at Google Scale-The Pitfalls of a Large Test Suite
- automated, limits of, The Limits of Automated Testing
- automating to keep up with modern development, Testing at the Speed of Modern Development
- benefits of testing code, Benefits of Testing Code-Benefits of Testing Code
- continuous integration and, Continuous Integration
- continuous testing in CI, Continuous Testing-Production testing
- designing a test suite, Designing a Test Suite-A Note on Code Coverage
  - Beyoncé Rule, The Beyoncé Rule
  - code coverage, A Note on Code Coverage
  - test scope, Test Scope-Test Scope
  - test size, Test Size
- hermetic, Hermetic Testing
- history at Google, History of Testing at Google-Testing Culture Today
  - contemporary testing culture, Testing Culture Today
  - orientation classes, Orientation Classes
  - Test Certified program, Test Certified
  - Testing on the Toilet (TotT), Testing on the Toilet
- in large-scale change infrastructure, Testing
- larger (see larger testing)
- of large-scale changes, Testing-Code Review
- reasons for writing tests, Why Do We Write Tests?-Benefits of Testing Code
  - Google Web Server, story of, The Story of Google Web Server
- tests for fakes, Fakes Should Be Tested
- write, run, react in automating testing, Write, Run, React-Write, Run, React
Testing on the Toilet (TotT), Testing on the Toilet
tests
- becoming brittle with overuse of stubbing, Tests become brittle
- becoming less effective with overuse of stubbing, Tests become less effective
- becoming unclear with overuse of stubbing, Tests become unclear
- making understandable, Making tests understandable
- overusing stubbing, example of, An example of overusing stubbing
- refactoring to avoid stubbing, An example of overusing stubbing
- speeding up, Speeding up tests
third_party directory, How Google Handles Importing Dependendencies
time
- deciding between time and scale, Example: Deciding Between Time and Scale
- in version control systems, Why Is Version Control Important?
- larger tests and passage of time, Larger Tests and Time
time and change in software projects, Time and Change-Why Not Just Aim for “Nothing Changes”?
- aiming for nothing changes, Why Not Just Aim for “Nothing Changes”?
- hash ordering (example), Example: Hash Ordering
- Hyrum's Law, Hyrum’s Law
- life span of programs and, What Is Software Engineering?
TL (see tech lead)
TLM (see tech lead manager)
token-based searches, Expressiveness: Token Versus Substring Versus Regex
toolchains, use by Bazel, Tools as dependencies
Torvalds, Linus, The Genius Myth
traceability, maintaining for metrics, Selecting Meaningful Metrics with Goals and Signals
tracking history of code changes in Critique, After Commit: Tracking History
tracking systems for work, Important Versus Urgent
trade-offs
- cost/benefit, Trade-offs and Costs-Revisiting Decisions, Making Mistakes
  - deciding between time and scale (example), Example: Deciding Between Time and Scale
  - distributed builds (example), Example: Distributed Builds
  - mistakes in decision making, Revisiting Decisions, Making Mistakes
  - whiteboard markers (example), Example: Markers
- for leaders, The Parable of the Airplane
- in engineering productivity, Goals
- in Web Search latency case study, Decide, Then Iterate
- key, identifying, Identify the Key Trade-Offs
transitive dependencies, Internal dependencies
- external, Transitive external dependencies
- strict, enforcing, Internal dependencies
tribal knowledge, Philosophy
Tricorder static analysis platform, Preventing backsliding, Tricorder: Google’s Static Analysis Platform-Analysis While Editing and Browsing Code
- analysis while editing and browsing code, Analysis While Editing and Browsing Code
- compiler integration, Compiler Integration
- criteria for new checks, Tricorder: Google’s Static Analysis Platform
- integrated feedback channels, Integrated Feedback Channels
- integrated tools, Integrated Tools
- per-project customization, Per-Project Customization
- presubmit checks, Presubmits
- suggested fixes, Suggested Fixes
trigram-based approach, search index in Code Search, Search Index
trunk-based development, Version Control and Branch Management, How did we become addicted to dev branches?
- correlation with good technical outcomes, Release Branches
- Live at Head model and, Live at Head
- predictive relationship between high-performing organizations and, (Nearly) No Long-Lived Branches
- source control questions and, Dependency Management
trust, The Three Pillars of Social Interaction
- being “Googley”, Being Googley
- code reviews and, Code Review Tooling Principles
- practicing, Humility, Respect, and Trust in Practice-Fail fast and iterate
- treating your team like children (antipattern), Antipattern: Treat Your Team Like Children
- trusting your team and losing the ego, Lose the Ego
- vulnerability and, Be open to influence
Truth assertion library, Write Clear Failure Messages
tutorials, Tutorials
- example of a bad tutorial, Tutorials
- example, bad tutorial made better, Example: A bad tutorial made better

U

UAT (user acceptance testing), UAT
UIs
- end-to-end tests of service UI to its backend, Reducing the size of your SUT at problem boundaries
- in example of fairly small SUT, Larger Tests at Google Scale
- tests for, unreliable and costly, Reducing the size of your SUT at problem boundaries
unchanging tests, Strive for Unchanging Tests
unit testing, Unit Testing-TL;DRs
- common gaps in unit tests, Common Gaps in Unit Tests-Emergent behaviors and the “vacuum effect”
  - configuration issues, Configuration issues
  - emergent behaviors and the vacuum effect, Emergent behaviors and the “vacuum effect”
  - issues arising under load, Issues that arise under load
  - unanticipated behaviors, inputs, and side effects, Unanticipated behaviors, inputs, and side effects
  - unfaithful test doubles, Unfaithful doubles
- execution time for tests, Execution time
- lifespan of software tested, Larger Tests and Time
- limitations of unit tests, What Are Larger Tests?
- maintainability of tests, importance of, The Importance of Maintainability
- narrow-scoped tests (or unit tests), Test Scope
- preventing brittle tests, Preventing Brittle Tests-Writing Clear Tests
- properties of good unit tests, Why Not Have Larger Tests?
- tests and code sharing, DAMP, not DRY, Tests and Code Sharing: DAMP, Not DRY-Defining Test Infrastructure
  - DAMP test, Tests and Code Sharing: DAMP, Not DRY
  - defining test infrastructure, Defining Test Infrastructure
  - shared helpers and validation, Shared Helpers and Validation
  - shared setup, Shared Setup
  - shared values, Shared Values
- writing clear tests, Writing Clear Tests-Tests and Code Sharing: DAMP, Not DRY
  - leaving logic out of tests, Don’t Put Logic in Tests
  - making tests complete and concise, Make Your Tests Complete and Concise
  - testing behaviors, not methods, Test Behaviors, Not Methods-Name tests after the behavior being tested
  - writing clear failure messages, Write Clear Failure Messages
units (in unit testing), Test via Public APIs
Unix, developers of, The Genius Myth
unreproducable builds, Making external dependencies deterministic
upgrades, What Is Software Engineering?
- compiler upgrade example, Example: Compiler Upgrade-Example: Compiler Upgrade
- life span of software projects and importance of, Time and Change
usability of static analyses, Usability
user evaluation tests, User Evaluation
user focus in CD, shipping only what gets used, Quality and User-Focus: Ship Only What Gets Used
users
- engineers building software for all users, Understanding the Need for Diversity
- focusing first on users most impacted by bias and discrimination, Stay Curious, Push Forward
- relegating consideration of user groups to late in development, Reject Singular Approaches

V

vacuum effect, unit tests and, Emergent behaviors and the “vacuum effect”
validation, shared helpers and, Shared Helpers and Validation
values versus outcomes in equitable engineering, Values Versus Outcomes
Van Rossum, Guido, The Genius Myth
VCSs (version control systems), Version Control and Branch Management
- (see also version control)
- blending between fine-grained repositories and monorepos, Monorepos
- early, Why Is Version Control Important?
velocity is a team sport, Velocity Is a Team Sport: How to Break Up a Deployment into Manageable Pieces
vendoring your project's dependencies, Security and reliability of external dependencies
version control, Version Control and Branch Management-Version Control Versus Dependency Management
- about, What Is Version Control?
- at Google, Version Control at Google-What About Release Branches?
  - few long-lived branches, (Nearly) No Long-Lived Branches
  - One-Version Rule, One Version, The “One-Version” Rule
  - release branches, What About Release Branches?
  - scenario, multiple available versions, Scenario: Multiple Available Versions
- branch management, Branch Management-Release Branches
- centralized vs. distributed VCSs, Centralized VCS Versus Distributed VCS-Distributed VCS
- versus dependency management, Version Control Versus Dependency Management
- future of, Future of Version Control
- importance of, Why Is Version Control Important?-Why Is Version Control Important?
- monorepos, Monorepos
- source of truth, Source of Truth-Scenario: no clear source of truth
virtual machines (VMs), Architecting for Failure
- for isolation in multitenant compute services, My neighbor’s dog barks in my RAM
virtual monorepos (VMRs), Monorepos, Future of Version Control
visibility, minimizing for modules in build systems, Minimizing Module Visibility
vulnerability, showing, Be open to influence

W

Web Search latency case study, Decide, Then Iterate-Decide, Then Iterate
Webdriver Torso incident, The benefits of hermetic SUTs
well-specified interaction tests, Avoid overspecification
who, what, when, where, and why questions, answering in documentation, WHO, WHAT, WHEN, WHERE, and WHY
workspaces
- differences from the global repository, Completeness: Head Versus Branches Versus All History Versus Workspaces
- local, Code Search support for, Search Index
- tight integration between Critique and, Tight Tool Integration
writing reviews (for technical documents), Documentation Reviews

Y

YAQS (“Yet Another Question System”), YAQS: Question-and-Answer Platform

Z

Zen master, being, Be a Zen Master