Index
Symbols
-
“Always of leadership”
-
“brilliant jerks”, Respect
A
-
A/B diff tests, A/B Diff Regression Testing
-
ABI compatibility, C++
-
Abseil, compatibility promises, Abseil
-
adversarial group interactions, Psychological Safety in Large Groups
-
advisory deprecations, Advisory Deprecation
-
AI (artificial intelligence)
-
airplane, parable of, The Parable of the Airplane
-
alert fatigue, Deprecation Warnings
-
analysis results from code analyzers, Analysis Results
-
annotations, per-test, documenting ownership, Owning Large Tests
-
Ant, 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
-
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
-
asking questions, Ask Questions
-
assertions
-
atomic changes, barriers to, Barriers to Atomic Changes
-
atomicity for commits in VCSs, Centralized VCS, What Is Version Control?
-
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
-
automation
-
automation of toil in CaaS, Automation of Toil
-
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, Artifact-Based Build Systems, Build Systems and Build Philosophy
-
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
-
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
-
binaries, interacting, functional testing of, Functional Testing of One or More Interacting Binaries
-
blameless postmortems, Blameless Post-Mortem Culture, Today’s Engineering Manager
-
Blaze, Artifact-Based Build Systems, Build Systems and Build Philosophy
-
blinders, identifying, Identify the Blinders
-
Boost C++ library, compatibility promises, Boost
-
branch management, Branch Management
-
brittle tests, The Pitfalls of a Large Test Suite
-
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
-
BUILD files, reformatting, Code Formatters
-
build scripts
-
build systems, Build Systems and Build Philosophy
-
Builder pattern, Shared Values
-
buildfiles, Task-Based Build Systems
-
building for everyone, Values Versus Outcomes
-
bundled distribution models, Bundled Distribution Models
-
bus factor, Always Be Leaving, The Bus Factor
C
-
C language, projects written in, changes to, Why Not Just Aim for “Nothing Changes”?
-
C++
-
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
-
CD, Continuous Delivery
-
celebrity, The Genius Myth
-
centralization versus customization in compute services, Centralization Versus Customization
-
centralized version control systems (VCSs), Centralized VCS
-
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
-
large-scale, What Is a Large-Scale Change?
-
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
-
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, Disaster Recovery and Chaos Engineering, The Beyoncé Rule
-
Chesterton’s fence, principle of, Understand Context
-
Churn Rule, Policies That Don’t Scale
-
clang-tidy, Error Checkers
-
class comments, Class comments
-
classes and tech talks, Tech Talks and Classes
-
classical testing, Real Implementations
-
cleanup in LSC process, Cleanup
-
clear tests, writing, Writing Clear Tests
-
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
-
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, Code Review, Readability: Standardized Mentorship Through Code Review
-
benefits of, Code Review, Code Review Benefits
-
best practices, Code Review Best Practices
-
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
-
ownership of code, How Code Review Works at Google
-
steps in, Code Review Flow
-
types of, Types of Code Reviews
-
Code Search, Code Search, Write Good Change Descriptions
-
Google's implementation, Google’s Implementation
-
how Googlers use it, How Do Googlers Use Code Search?
-
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
-
reasons for a separate web tool, Why a Separate Web Tool?
-
trade-offs in implementing, Selected Trade-Offs
-
UI, The Code Search UI
-
code sharing, tests and, Tests and Code Sharing: DAMP, Not DRY
-
codebase
-
codelabs, Codelabs
-
commenting on changes in Critique, Commenting
-
comments
-
communities
-
compiler integration with static analysis, Compiler Integration
-
compiler upgrage (example), 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
-
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
-
constructive criticism, Learn to give and take criticism
-
consumer-driven contract tests, Record/replay proxies
-
containerization and multitenancy, Containerization and Multitenancy
-
containers as an abstraction, Containers as an Abstraction
-
context, understanding, Understand Context
-
continuous build (CB), Continuous Build
-
continuous delivery (CD), Continuous Delivery, Continuous Delivery
-
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
-
continuous deployment (CD), release branches and, Release Branches
-
continuous integration (CI), Continuous Integration, Policies That Scale Well
-
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
-
criticism, learning to give and take, Learn to give and take criticism
-
Critique code review tool, Code Review, Critique: Google’s Code Review Tool, The Code Search UI
-
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
-
diff viewer, Tricorder warnings on, Tricorder: Google’s Static Analysis Platform
-
request review, Stage 2: Request Review
-
understanding and commenting on a change, Stages 3 and 4: Understanding and Commenting on a Change
-
view of static analysis fix, Suggested Fixes
-
cryptographic hashes, Making external dependencies deterministic
-
culprit finding and failure isolation, CI Challenges
-
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
-
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), Centralized VCS, What Is Version Control?
D
-
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
-
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
-
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
-
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
-
deployment
-
deployment configuration testing, Deployment Configuration Testing
-
deprecation, Deprecation
-
Descriptive And Meaningful Phrases, Tests and Code Sharing: DAMP, Not DRY
-
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
-
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
-
developer workflow, large tests and, Large Tests and the Developer Workflow
-
developer workflow, making static analysis part of, Make Static Analysis a Part of the Core Developer Workflow
-
DevOps
-
DevOps Research and Assessment (DORA)
-
diamond dependency issue, Conflicting Requirements and Diamond Dependencies, The One-Version Rule
-
diffing code changes, Diffing
-
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 version control systems (DVCSs), Distributed VCS
-
diversity
-
Docker, Containers as an Abstraction
-
documentation, Documentation, Documentation
-
about, What Qualifies as Documentation?
-
benefits of, 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
-
philosophy, Documentation Philosophy
-
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
-
types of, Documentation Types
-
updating, Updating documentation
-
when you need technical writers, When Do You Need Technical Writers?
-
documentation comments, Optimize for the reader
-
documentation reviews, Documentation Reviews
-
documented knowledge, Philosophy
-
domain knowledge of documentation audiences, Types of Audiences
-
DRY (Don’t Repeat Yourself) principle
-
DVCSs, Distributed VCS
E
-
Edison, Thomas, Fail fast and iterate
-
education of software engineers, Understanding the Need for Diversity
-
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, Antipatterns, The Engineering Manager, The Engineering Manager
-
engineering productivity
-
Engineering Productivity Research (EPR) team, Why Have This Process?
-
engineering productivity, measuring, Measuring Engineering Productivity
-
equitable and inclusive engineering, Engineering for Equity
-
bias and, Bias Is the Default
-
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
-
error-prone and surprising constructs in code, avoiding, Avoid error-prone and surprising constructs
-
execution time for tests, Execution time
-
experience levels for documentation audiences, Types of Audiences
-
experiments and feature flags, Fast Feedback Loops
-
expertise
-
exploitation versus exploration problem, Query independent signals
-
exploratory testing, Exploratory Testing, The Limits of Automated Testing
-
extrinsic versus intrinsic motivation, Intrinsic Versus Extrinsic Motivation
F
-
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
-
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
-
fidelity
-
file comments, File comments
-
file locking in VCSs, Centralized VCS, What Is Version Control?
-
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, CI Challenges, Determinism, Small tests
-
Forge, CI at Google, Distributed builds 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
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
-
given/when/then, expressing behaviors, Test Behaviors, Not Methods
-
Go programming language
-
go/ links, go/ links
-
goals
-
Goals/Signals/Metrics (GSM) framework, Selecting Meaningful Metrics with Goals and Signals
-
Google Assistant, Hermetic Testing
-
Google Search, Time and Change
-
Google Takeout case study, CI Case Study: Google Takeout
-
Google Web Server (GWS), The Story of Google Web Server
-
Google wiki (GooWiki), Documentation Is Like Code
-
Gradle, 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
-
Hamming, Richard, Lose the ego, Why Do These Pillars Matter?
-
happiness, tracking for your team, Track Happiness
-
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”?
-
helper methods
-
hermetic code, nondeterminism and, Determinism
-
hermetic SUTs, The System Under Test
-
hermetic testing, Hermetic Testing
-
hero worship, The Genius Myth
-
hiding your work
-
hiring of software engineers
-
history, indexing in Code Search, Completeness: Head Versus Branches Versus All History Versus Workspaces
-
honesty, being honest with your team, Be Honest
-
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
-
hybrid SUTs, The System Under Test
-
Hyrum's Law, Hyrum’s Law
I
-
ice cream cone antipattern in testing, Larger Tests and Time, Test Scope
-
idempotency, Connecting to a Service
-
IDEs (integrated development environments)
-
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
-
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
-
insecurity, Help Me Hide My Code
-
integration tests, Test Scope
-
intellectual complexity (QUANTS), Goals
-
interaction testing, Interaction Testing, Test State, Not Interactions
-
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
K
-
key abstractions and data structures in libraries, listings of, Guidance
-
knowledge sharing, Knowledge Sharing
-
as benefit of code reviews, Knowledge Sharing
-
asking the community, Scaling Your Questions: Ask the Community
-
challenges to learning, Challenges to Learning
-
critical role of psychological safety, Setting the Stage: Psychological Safety
-
growing your knowledge, Growing Your Knowledge, 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
-
standardized mentorship through code reviews, Readability: Standardized Mentorship Through Code Review
-
teaching others, Scaling Your Knowledge: You Always Have Something to Teach
-
Kondo, Marie, Learn to Drop Balls
-
Kubernetes clusters, One Service to Rule Them All
-
kudos, Incentives and recognition
-
Kythe, Codebase Insight
L
-
landing pages, Landing Pages
-
Large Scale Change tooling and processes, Advantages of consistency
-
large tests, Large tests
-
large-scale changes, Large-Scale Changes, Purpose of a Build System
-
larger testing, Larger Testing
-
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
-
larger tests at Google, Larger Tests at Google
-
structure of a large test, Structure of a Large Test
-
types of large tests, Types of Larger Tests
-
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
-
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
-
Addressing Web Search latency (case study), 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
-
learning to drop balls, Learn to Drop Balls
-
protecting your energy, Protecting Your Energy
-
leading a team, How to Lead a Team
-
learning, Philosophy
-
LGTM (looks good to me) stamp from reviewers, Code Review Flow
-
libraries, compilers and, But All I Need Is a Compiler!
-
linters in Tricorder, Per-Project Customization
-
Linux
-
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, What Is a Large-Scale Change?
M
-
mailing lists, Mailing Lists
-
maintainability of tests, Unit Testing
-
managers and tech leads, Managers and Tech Leads (and Both)
-
manual testing, Larger Tests and Time
-
Markdown, Documentation Is Like Code
-
mastery for team members, Intrinsic Versus Extrinsic Motivation
-
Maven, Task-Based Build Systems
-
measurements, Measuring Engineering Productivity
-
medium tests, Medium tests
-
Meltdown and Spectre, Why Not Just Aim for “Nothing Changes”?
-
mentorship, Mentorship
-
merge conflicts, size of changes and, Merge Conflicts
-
merges
-
method-driven tests, Test Behaviors, Not Methods
-
metrics
-
migrations
-
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
-
mocking frameworks
-
mockist testing, Real Implementations
-
Mockito
-
modules, dealing with in build systems, Dealing with Modules and Dependencies
-
monorepos, Monorepos
-
motivating your team, People Are Like Plants
-
move detection for code chunks, Diffing
-
multicultural capacity, building, Building Multicultural Capacity
-
multimachine SUT, The System Under Test
-
multitenancy, containerization and, My neighbor’s dog barks in my RAM
-
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, Large tests, Small tests
-
nondeterministic behavior in tests, Determinism
-
notifications from Critique, Notifications
O
-
office hours, using for knowledge sharing, Office Hours
-
one-off code, One-Off Code
-
One-Version Rule, One Version, The One-Version Rule, The “One-Version” Rule
-
Open Source Software (OSS)
-
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
P
-
Pact Contract Testing, Record/replay proxies
-
Pants, Artifact-Based Build Systems
-
parallelization of build steps
-
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
-
performance of software engineers
-
personnel costs, Trade-offs and Costs
-
Piper, Version Control at Google
-
policies for large-scale changes, Policies and Culture
-
politeness and professionalism in code reviews, Be Polite and Professional
-
postmortems, blameless, Blameless Post-Mortem Culture, Today’s Engineering Manager
-
precommit reviews, Code Review Flow
-
presubmits, Automate Where Possible
-
probers, Probers and Canary Analysis
-
problems
-
product stability, dev branches and, Dev Branches
-
production
-
professionalism in code reviews, Be Polite and Professional
-
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
-
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
-
Python style guides
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
-
RCS (Revision Control System), Centralized VCS, What Is Version Control?
-
readability, Code, Readability: Standardized Mentorship Through Code Review
-
real implementations, using instead of test doubles, Real Implementations
-
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, Hermetic Testing, Record/replay proxies
-
redundancy in documentation, The Beginning, Middle, and End
-
refactorings, Strive for Unchanging Tests
-
reference documentation, Reference Documentation
-
references, using for ranking, Query independent signals
-
regression tests, A/B Diff Regression Testing
-
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
-
release candidate testing, Release candidate testing
-
releases
-
reliability of external dependencies, Security and reliability of external dependencies
-
remote caching in distributed builds, Remote caching
-
remote execution of distributed builds, Remote execution
-
repositories, What Is Version Control?
-
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
-
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
-
roadblocks, removing, Remove Roadblocks
-
rollbacks, Bug Fixes and Rollbacks
-
Rosie tool, Change Management
-
rules governing code, Style Guides and Rules
-
rules, defining in Bazel, Extending the build system
S
-
sampling bias, Using Data to Validate Metrics
-
sandboxing
-
satisfaction (QUANTS), Goals
-
scalability
-
scale
-
scale and efficiency, Scale and Efficiency
-
scaling
-
scheduling, automated, Architecting for Failure, Automated scheduling
-
scope of tests, Test Scope, What Are Larger Tests?
-
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
-
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
-
semantic version strings, Automatic versus manual dependency management
-
semantic versioning, Semantic Versioning
-
SemVer, The Limitations of SemVer
-
servant leadership, Servant Leadership
-
serverless, Level of Abstraction: Serverless
-
services, connecting to in software for managed compute, Connecting to a Service
-
serving jobs, Batch Versus Serving
-
shading (in Java), Scenario: Multiple Available Versions
-
sharding and submitting in LSC process, Sharding and Submitting
-
shared environment SUT, The System Under Test
-
shell scripts, using for builds, Shell Scripts to the Rescue?
-
shifting left, Pace of Progress, Shifting Left
-
shipping only what gets used, Quality and User-Focus: Ship Only What Gets Used
-
signals
-
single point of failure (SPOF), Challenges to Learning
-
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
-
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
-
software engineers
-
source control
-
source of truth, Source of Truth
-
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
-
state, managing, Compute as a Service
-
state-changing functions, Prefer to perform interaction testing only for state-changing functions
-
static analysis, Static Analysis
-
static analysis tools, Static analysis
-
static dependency model, Nothing Changes (aka The Static Dependency Model)
-
std::unique_ptr in C++, Code Review, Enforcing best practices
-
streetlight effect, Selecting Meaningful Metrics with Goals and Signals
-
stress testing, Performance, Load, and Stress testing
-
stubbing, Stubbing, Stubbing
-
stumblers, documentation for, Types of Audiences
-
style arbiters, The Style Arbiters
-
style guides for code, Developer guides, Style Guides and Rules
-
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
-
system tests, Test Scope
-
systems under test (SUTs), The System Under Test
-
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, Testing at Google Scale
-
task-based build systems, Task-Based Build Systems
-
teacher and mentor, being, Be a Teacher and a Mentor
-
teams
-
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), CI at Google, Testing at Google Scale
-
test data for larger tests, Test Data
-
test doubles, Test Doubles, Test Scope
-
at Google, Test Doubles at Google
-
example, Basic Concepts
-
faking, Faking
-
impact on software development, The Impact of Test Doubles on Software Development
-
interaction testing, Interaction Testing
-
mocking frameworks, Mocking Frameworks
-
seams, Seams
-
stubbing, Stubbing
-
techniques for using, Techniques for Using Test Doubles
-
unfaithful, Unfaithful doubles
-
using in brittle interaction test, Test State, Not Interactions
-
using real implementations instead of, Real Implementations
-
test infrastructure, Defining Test Infrastructure
-
test instability, CI Challenges
-
test scope, What Are Larger Tests?
-
test sizes, Test Size
-
test suite, Why Do We Write Tests?
-
test traffic, Test Data
-
testability
-
testable code, Seams
-
writing testable code early, Seams
-
testing, Testing Overview
-
as barrier to atomic changes, Testing
-
at Google scale, Testing at Google Scale
-
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
-
continuous integration and, Continuous Integration
-
continuous testing in CI, Continuous Testing
-
designing a test suite, Designing a Test Suite
-
hermetic, Hermetic Testing
-
history at Google, History of Testing at Google
-
in large-scale change infrastructure, Testing
-
larger, Larger Testing
-
of large-scale changes, Testing
-
reasons for writing tests, Why Do We Write Tests?
-
tests for fakes, Fakes Should Be Tested
-
write, run, react in automating testing, Write, Run, React
-
Testing on the Toilet (TotT), Testing on the Toilet
-
tests
-
third_party directory, How Google Handles Importing Dependencies
-
time
-
time and change in software projects, Time and Change
-
TL, The Tech Lead
-
TLM, The 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
-
transitive dependencies, Internal dependencies
-
tribal knowledge, Philosophy
-
Tricorder static analysis platform, Preventing backsliding, Tricorder: Google’s Static Analysis Platform
-
trigram-based approach, search index in Code Search, Search Index
-
trunk-based development, How did we become addicted to dev branches?, Version Control and Branch Management
-
trust, The Three Pillars of Social Interaction
-
Truth assertion library, Write Clear Failure Messages
-
tutorials, Tutorials
U
-
UAT (user acceptance testing), UAT
-
UIs
-
unchanging tests, Strive for Unchanging Tests
-
unit testing, Unit Testing
-
common gaps in unit tests, Common Gaps in Unit Tests
-
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
-
properties of good unit tests, Why Not Have Larger Tests?
-
tests and code sharing, DAMP, not DRY, Tests and Code Sharing: DAMP, Not DRY
-
writing clear tests, Writing Clear Tests
-
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?
-
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
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
-
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
-
virtual machines (VMs), Architecting for Failure
-
virtual monorepos (VMRs), Future of Version Control, Monorepos
-
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
-
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
-
writing reviews (for technical documents), Documentation Reviews
“
-
“Always of leadership”
-
“clean” and “maintainable” code, Example: Hash Ordering
-
“clever” code, Example: Hash Ordering
-
“Fail early, fail fast, fail often”, Early Detection
-
“Googley”, being, Being Googley
-
“hacky” or “clever” code, Example: Hash Ordering
-
“Hello World” tutorials, Tutorials
-
“Hope is not a strategy”, Antipattern: Ignore Low Performers
-
“manageritis”, Moving from an Individual Contributor Role to a Leadership Role
-
“Peter Principle”, The Only Thing to Fear Is…Well, Everything