Titus Winters > 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

“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

“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

“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

“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

“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

“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

“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

“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

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

“If you have a hundred engineers writing Java, a single friendly and helpful Java expert willing to answer questions will soon produce a hundred engineers writing better Java code.”
― Titus Winters, Software Engineering at Google: Lessons Learned from Programming Over Time

“Google and Stack Overflow are great sources of opinions and information, but they’re no substitute for actual human experience.”
― Titus Winters, Software Engineering at Google: Lessons Learned from Programming Over Time

“What will make or break your career, especially at a company like Google, is how well you collaborate with others.”
― Titus Winters, Software Engineering at Google: Lessons Learned from Programming Over Time

“what “hiding” boils down to is this: working alone is inherently riskier than working with others. Even though you might be afraid of someone stealing your idea or thinking you’re not intelligent, you should be much more concerned about wasting huge swaths of your time toiling away on the wrong thing.”
― Titus Winters, Software Engineering at Google: Lessons Learned from Programming Over Time

“In a professional software engineering environment, criticism is almost never personal - it’s usually just part of the process of making a better project. The trick is to make sure you (and those around you) understand the difference between a constructive criticism of someone’s creative output and a flat-out assault against someone’s character.

The latter is useless - it’s petty and nearly impossible to act on. The former can (and should!) be helpful and give guidance on how to improve. And, most important, it’s imbued with respect: the person giving the constructive criticism genuinely cares about the other person and wants them to improve themselves or their work. Learn to respect your peers and give constructive criticism politely. If you truly respect someone, you’ll be motivated to choose tactful, helpful phrasing—a skill acquired with much practice.”
― 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

“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

“Consistency is vital; adaptation is key.”
― Titus Winters, Software Engineering at Google: Lessons Learned from Programming Over Time

“Our chapters on Culture (Part II) emphasize the collective nature of a software development enterprise, that the development of software is a team effort, and that proper cultural principles are essential for an organization to grow and remain healthy.”
― Titus Winters, Software Engineering at Google: Lessons Learned from Programming Over Time

“In short, performance ratings are indicative only of how a person is performing in their given role at the time they are being evaluated. Ratings, although an important way to measure performance during a specific period, are not predictive of future performance and should not be used to gauge readiness for a future role or qualify an internal candidate for a different team. (They can, however, be used to evaluate whether an employee is properly or improperly slotted on their current team; therefore, they can provide an opportunity to evaluate how to better support an internal candidate moving forward.)”
― 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

“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

“People are inherently imperfect - we like to say that humans are mostly a collection of intermittent bugs. But before you can understand the bugs in your coworkers, you need to understand the bugs in yourself. We’re going to ask you to think about your own reactions, behaviors, and attitudes - and in return, we hope you gain some real insight into how to become a more efficient and successful software engineer who spends less energy dealing with people-related problems and more time writing great code.”
― Titus Winters, Software Engineering at Google: Lessons Learned from Programming Over Time

“In addition to developing the proper culture, invest in your testing infrastructure by developing linters, documentation, or other assistance that makes it more difficult to write bad tests.”
― 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

“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

“Fakes Should Be Tested A fake must have its own tests to ensure that it conforms to the API of its corresponding real implementation. A fake without tests might initially provide realistic behavior, but without tests, this behavior can diverge over time as the real implementation evolves.”
― Titus Winters, Software Engineering at Google: Lessons Learned from Programming Over Time

“When an engineer refactors the internals of a system without modifying its interface, whether for performance, clarity, or any other reason, the system’s tests shouldn’t need to change. The role of tests in this case is to ensure that the refactoring didn’t change the system’s behavior. Tests that need to be changed during a refactoring indicate that either the change is affecting the system’s behavior and isn’t a pure refactoring, or that the tests were not written at an appropriate level of abstraction.”
― Titus Winters, Software Engineering at Google: Lessons Learned from Programming Over Time

“As an engineer, you might wield more power than you realize: the power to literally change society. It’s critical that on your journey to becoming an exceptional engineer, you understand the innate responsibility needed to exercise power without causing harm. The first step is to recognize the default state of your bias caused by many societal and educational factors. After you recognize this, you’ll be able to consider the often-forgotten use cases or users who can benefit or be harmed by the products you build.”
― Titus Winters, Software Engineering at Google: Lessons Learned from Programming Over Time