Software Engineering at Google: Lessons Learned from Programming Over Time

by Titus Winters

software engineering can be thought of as “programming integrated over time.” What practices can we introduce to our code to make it sustainable — able to react to necessary change — over its life cycle, from conception to introduction to maintenance to deprecation?

we’d like to take time to recognize those who contributed to each chapter by providing thoughtful input, discussion, and review.

Your project is sustainable if, for the expected life span of your software, you are capable of reacting to whatever valuable change comes along, for either technical or business reasons.

the difference between software engineering and programming is one of both time and people. Team collaboration presents new problems, but also provides more potential to produce valuable systems than any single programmer could.

The job of a software engineer, or a software engineering leader, is to aim for sustainability and management of the scaling costs for the organization, the product, and the development workflow.

If you are maintaining a project that is used by other engineers, the most important lesson about “it works” versus “it is maintainable” is what we’ve come to call 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.

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.

“It’s programming if ‘clever’ is a compliment, but it’s software engineering if ‘clever’ is an accusation.”

The more frequently you change your infrastructure, the easier it becomes to do so.

One of the broad truths we’ve seen to be true is the idea that finding problems earlier in the developer workflow usually reduces costs.

Jevons Paradox: consumption of a resource may increase as a response to greater efficiency in its use.

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.

humans are mostly a collection of intermittent bugs.

The point we’ve been hammering away at is that, in the realm of programming, lone craftspeople are extremely rare — and even when they do exist, they don’t perform superhuman achievements in a vacuum; their world-changing accomplishment is almost always the result of a spark of inspiration followed by a heroic team effort.

software engineering is a team endeavor.

before removing or changing something, first understand why it’s there.

Start small: ask questions and write things down.

Another big reason for not becoming a manager is often unspoken but rooted in the famous “Peter Principle,” which states that “In a hierarchy every employee tends to rise to his level of incompetence.”

becoming a TL or manager. First, it’s a way to scale yourself.

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).

Most management texts advise that you use the “compliment sandwich” to soften the blow when delivering hard feedback. A compliment sandwich looks something like this: You’re a solid member of the team and one of our smartest engineers. That being said, your code is convoluted and almost impossible for anyone else on the team to understand. But you’ve got great potential and a wicked cool T-shirt collection. Sure, this softens the blow, but with this sort of beating around the bush, most people will walk out of this meeting thinking only, “Sweet! I’ve got cool T-shirts!” We strongly advise against using the compliment sandwich, not because we think you should be unnecessarily cruel or harsh, but because most people won’t hear the critical message, which is that something needs to change.

A good simple way to track your team’s happiness8 is to ask the team member at the end of each one-on-one meeting, “What do you need?”

“the three Always of leadership”: Always Be Deciding, Always Be Leaving, Always Be Scaling.

A common mistake is to put a team in charge of a specific product rather than a general problem. A product is a solution to a problem. The life expectancy of solutions can be short, and products can be replaced by better solutions. However, a problem — if chosen well — can be evergreen.

DAMP — that is, to promote “Descriptive And Meaningful Phrases.”

Much of the initial work of deprecation is determining who is using the old system — and in which unanticipated ways.