Lessons from Software Engineering at Google – Book Review

DanielFebruary 12, 2024February 13, 2024

I recently read through Software Engineering At Google: Lessons Learnt over Time. While I suspected it could be a Google-centric promotional piece, it turned out to be one of the most valuable and insightful books on software engineering that I've encountered.

What I liked about it was how well the principles from this book are applicable to both teams of 5-6 people and huge teams of dozens of engineers.

The book is full of great ideas, but I found that the following echoed in my head many months after I finished reading it.

What is the difference between Programming and Software Engineering?

Titus Winters, the author of the first chapter, gives a great explanation for this: "Software engineering is programming over time".

While programming is about writing code, software engineering is about considering the long-term effects of that code. Thinking about things such as:

• How will the task evolve?
• How is the code written and what does it encourage others to do?
• How does it scale?
• What's the expected lifespan of the code?

The last question is very important to ask. You will have a different approach to coding a login or payment flow vs something like a user profile customization.

Small deploys and upgrade dependencies often

Given a dependency such as npm packages, it's much more safer to upgrade one single package from v 1.2.3 to v 1.2.4. On the other side try upgrading multiple packages from v 1.2.3 to v 9.5.8 and see how that goes 😈 ?

Run npm update as often as possible!

The same goes for production deploys. Instead of doing one giant deployment each 2-3 weeks with multiple features at once, try to ship small incremental changes each day. It will be much safer and more stable. If anything goes wrong it's one thing to debug a few lines added to one single feature instead of 30 files that affect 5 different features.

The process matters - invest time in it

For all of the above to work you need to invest time in maintaining and improving the development process and infrastructure.

Make sure it's easier for devs to deploy in production. The deployment process should be fast, well-documented, and stable.

Also, make sure it's safe to deploy. Things such as making sure the code is tested (at least the essential flows), a minimum of 2 devs are reviewing a pull request, it's easy to roll back a deployment, and so on.

Even if it's directly not visible to the end user, how fast and safe a deployment is made should be treated as a feature of the product.

If you have time, read the book. I liked it more than I thought.