Books for software engineers and managers

The DevOps Handbook

The DevOps Handbook

How to Create World-Class Agility, Reliability, & Security in Technology  Organizations

by Gene Kim, Jez Humble, Patrick Debois, and John Willis

Engineering Manager,
Tech Lead,
Star Engineer

How strongly do I recommend The DevOps Handbook?
10 / 10

The DevOps Handbook is an excellent choice for engineering leaders and engineering team book clubs. Read this book together with your team and you’re likely to find several areas for improvement and meaningful conversation.

Quality engineering is about creating and tightening feedback  loops

As an engineering manager or leader, your job is to improve feedback loops and primarily through speed:

  • Faster feedback from code reviews
  • Faster feedback from automated test suites
  • Faster feedback from monitoring
  • Faster feedback from customers and users

Engineers instinctively know that faster feedback is better. Waiting 2 minutes for a test suite is much better than 30 minutes. But how many organizations invest energy toward tightening feedback loops?

To my mind, quality of the feedback is a secondary consideration. I’d rather have a fast code review of okay quality than a slow code review of great quality. I can work with the first to extract more information, but I can’t improve the speed of the second.

Embrace the monorepo

Google has all their code in a single repo with billions of files. Randy Shoup, current VP of Engineering and Chief Architect at Ebay, formerly of Google, called Google’s monorepo “the most powerful mechanism for preventing failures.”

At my company, we still have multiple repos but after reading The DevOps Handbook, we’re starting to see the pain points that could be alleviated by consolidating our code into a single repository.

For instance, when fixing a bug ticket that spans both our API and mobile app, we currently need to touch multiple repos, creating multiple pull requests, and perform fragmented code reviews across multiple repos. Consolidating would improve our  ability to view code changes as a single body of work.

Improving at the daily work will improve the  work

When I interview engineers and ask about automated testing at their current job, the most frequent response is that they don’t have time to do automated testing. They are too busy shipping features! That customers demand! Yesterday!

It’s an understandable, but penny-wise and pound-foolish mistake that everyone is complicit in.

More important than improving the work itself is improving at the daily work. Constantly improve your ability to develop software using the four metrics for software delivery performance as a guide. Results will follow.

Great cultural transformations are  possible

The DevOps Handbook is filled with stories and interviews of software engineering leaders at Etsy, Target, Macy’s, Google, Facebook, and other companies all pursuing devops transformations.

The takeaway for me was that cultural transformations are possible. If Target can improve their software development environment and culture, so can your company.

But you need transformational leaders. Reformers. People who know how to navigate your own company culture, blowing up bureaucracy with an inviting and inclusive mentality, not threatening.

Develop generalists with  cross-training

The devops movement is largely about cross-training your software engineers to grow operational skills in delivery, reliability, and system administration.

You are developing generalists, capable of solving business problems across a broader range of engineering disciplines. This minimizes the handoffs and transitions between teams, which slows down delivery. Likewise, you minimize the likelihood of someone having ownership over reliability of a feature or solution that somebody else developed.

On my team, every engineer works full stack for both pragmatic and growth reasons. Pragmatically, we have a small team and everyone needs to be capable of solving many types of problems. This also provides growth areas for my engineers to learn new skills, try new technologies, and take ownership over business and engineering outcomes.

Telemetry everywhere

About a third of The DevOps Handbook is dedicated to telemetry and monitoring.

Too few teams can successfully answer the question, “Is it working?” at both systems and usage levels.

At the system level, we of course want to know that our servers, databases, and clients are operating as expected. We want insight into system performance and issues.

At the usage level, we need to know whether the features and solutions we’re building are delivering business value. Are users actually using the things we build and how?

Where we fault to instrument our systems with telemetry, we fail to engage in learning and improvement. In other words, we’re just building stuff and passively hoping for the best.

The DevOps Handbook