Software Engineering at Google Quotes

“Knowledge is in some ways the most important (though intangible) capital of a software engineering organization, and sharing of that knowledge is crucial for making an organization resilient and redundant in the face of change. A culture that promotes open and honest knowledge sharing distributes that knowledge efficiently across the organization and allows that organization to scale over time. In most cases, investments into easier knowledge sharing reap manyfold dividends over the life of a company.”
― Titus Winters, Software Engineering at Google: Lessons Learned from Programming Over Time

“Programming is the immediate act of producing code. Software engineering is the set of policies, practices, and tools that are necessary to make that code useful for as long as it needs to be used and allowing collaboration across a team.”
― Titus Winters, Software Engineering at Google: Lessons Learned from Programming Over Time

“This is what good management is about: 95% observation and listening, and 5% making critical adjustments in just the right place.”
― Titus Winters, Software Engineering at Google: Lessons Learned from Programming Over Time

“Traditional managers worry about how to get things done, whereas great managers worry about what things get done (and trust their team to figure out how to do it).”
― Titus Winters, Software Engineering at Google: Lessons Learned from Programming Over Time

“The moral is this: do not underestimate the power of playing the social game. It’s not about tricking or manipulating people; it’s about creating relationships to get things done. Relationships always outlast projects. When you’ve got richer relationships with your coworkers, they’ll be more willing to go the extra mile when you need them.”
― Titus Winters, Software Engineering at Google: Lessons Learned from Programming Over Time

“Stagnation is an option, but often not a wise one.”
― Titus Winters, Software Engineering at Google: Lessons Learned from Programming Over Time

“Nothing is built on stone; all is built on sand, but we must build as if the sand were stone. Jorge Luis Borges”
― Titus Winters, Software Engineering at Google: Lessons Learned from Programming Over Time

“Still other teams give out noise-canceling headphones to engineers to make it easier to deal with background noise — in fact, in many companies, the very act of wearing headphones is a common signal that means “don’t disturb me unless it’s really important.”
― Titus Winters, Software Engineering at Google: Lessons Learned from Programming Over Time

“We think the middle ground is really the best solution. Group teams of four to eight people together in small rooms (or large offices) to make it easy (and non-embarrassing) for spontaneous conversation to happen.”
― Titus Winters, Software Engineering at Google: Lessons Learned from Programming Over Time

“Programming is hard. Software engineering is even harder. You need that second pair of eyes.”
― Titus Winters, Software Engineering at Google: Lessons Learned from Programming Over Time

“Remember the tried-and-true mantra of “Fail early, fail fast, fail often.”
― Titus Winters, Software Engineering at Google: Lessons Learned from Programming Over Time

“Even though software development is deeply intellectual work that can require deep concentration and alone time, you must play that off against the value (and need!) for collaboration and review.”
― Titus Winters, Software Engineering at Google: Lessons Learned from Programming Over Time

“The vast majority of the work at Google (and at most companies!) doesn’t require genius-level intellect, but 100% of the work requires a minimal level of social skills.”
― Titus Winters, Software Engineering at Google: Lessons Learned from Programming Over Time

“core principles of humility, respect, and trust.”
― Titus Winters, Software Engineering at Google: Lessons Learned from Programming Over Time

“Software engineering” differs from “programming” in dimensionality: programming is about producing code. Software engineering extends that to include the maintenance of that code for its useful life span.”
― Titus Winters, Software Engineering at Google: Lessons Learned from Programming Over Time

“Contrary to some people’s instincts, leaders who admit mistakes are more respected, not less.”
― Titus Winters, Software Engineering at Google: Lessons Learned from Programming Over Time

“Even a relatively simple trade-off of the form “We’ll spend $$$s for compute resources to recoup engineer time” had unforeseen downstream effects.”
― Titus Winters, Software Engineering at Google: Lessons Learned from Programming Over Time

“Solving these problems in a scalable way means changing the way we do deprecation: instead of pushing migration work to customers, teams can internalize it themselves, with all the economies of scale that provides. In 2012, we tried to put a stop to this with rules mitigating churn: infrastructure teams must do the work to move their internal users to new versions themselves or do the update in place, in backward-compatible fashion. This policy, which we’ve called the “Churn Rule,” scales better: dependent projects are no longer spending progressively greater effort just to keep up. We’ve also learned that having a dedicated group of experts execute the change scales better than asking for more maintenance effort from every user: experts spend some time learning the whole problem in depth and then apply that expertise to every subproblem. Forcing users to respond to churn means that every affected team does a worse job ramping up, solves their immediate problem, and then throws away that now-useless knowledge. Expertise scales better.”
― Titus Winters, Software Engineering at Google: Lessons Learned from Programming Over Time

“The traditional use of development branches is another example of policy that has built-in scaling problems. An organization might identify that merging large features into trunk has destabilized the product and conclude, “We need tighter controls on when things merge. We should merge less frequently.” This leads quickly to every team or every feature having separate dev branches. Whenever any branch is decided to be “complete,” it is tested and merged into trunk, triggering some potentially expensive work for other engineers still working on their dev branch, in the form of resyncing and testing. Such branch management can be made to work for a small organization juggling 5 to 10 such branches. As the size of an organization (and the number of branches) increases, it quickly becomes apparent that we’re paying an ever-increasing amount of overhead to do the same task.”
― Titus Winters, Software Engineering at Google: Lessons Learned from Programming Over Time

“Hyrum’s Law represents the practical knowledge that — even with the best of intentions, the best engineers, and solid practices for code review — we cannot assume perfect adherence to published contracts or best practices.”
― Titus Winters, Software Engineering at Google: Lessons Learned from Programming Over Time

“If the fork in question is provably limited in scope, that helps, as well — avoid forks for interfaces that could operate across time or project-time boundaries (data structures, serialization formats, networking protocols).”
― Titus Winters, Software Engineering at Google: Lessons Learned from Programming Over Time

“On the other hand, if every developer forks everything used in their software project instead of reusing what exists, scalability suffers alongside sustainability. Reacting to a security issue in an underlying library is no longer a matter of updating a single dependency and its users: it is now a matter of identifying every vulnerable fork of that dependency and the users of those forks.”
― Titus Winters, Software Engineering at Google: Lessons Learned from Programming Over Time

“If I spend two weeks changing this linked-list into a higher-performance structure, I’m going to use five gibibytes more production RAM but save two thousand CPUs. Should I do it?” Not only does this question depend upon the relative cost of RAM and CPUs, but also on personnel costs (two weeks of support for a software engineer) and opportunity costs (what else could that engineer produce in two weeks?).”
― Titus Winters, Software Engineering at Google: Lessons Learned from Programming Over Time

“just because,” “because I said so,” or “because everyone else does it this way” are places where bad decisions lurk.”
― Titus Winters, Software Engineering at Google: Lessons Learned from Programming Over Time

“consensus, not unanimity.”
― Titus Winters, Software Engineering at Google: Lessons Learned from Programming Over Time

“in software engineering, as in life, good choices lead to good outcomes.”
― Titus Winters, Software Engineering at Google: Lessons Learned from Programming Over Time

“As every system administrator knows, it’s one thing to know in theory that you can recover from tape, and another to know in practice exactly how to do it and how much it will cost when it becomes necessary. Practice and expertise are great drivers of efficiency and reliability.”
― Titus Winters, Software Engineering at Google: Lessons Learned from Programming Over Time

“Every piece of technology upon which your project depends has some (hopefully small) risk of containing critical bugs and security vulnerabilities that might come to light only after you’ve started relying on it. If you are incapable of deploying a patch for Heartbleed or mitigating speculative execution problems like Meltdown and Spectre because you’ve assumed (or promised) that nothing will ever change, that is a significant gamble.”
― Titus Winters, Software Engineering at Google: Lessons Learned from Programming Over Time

“Hyrum’s Law: With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.”
― Titus Winters, Software Engineering at Google: Lessons Learned from Programming Over Time

“We have tried to make the discussions in this book more about engineering and less about programming.”
― Titus Winters, Software Engineering at Google: Lessons Learned from Programming Over Time