For years, I kept notes on patterns I saw in software projects, architecture, planning, estimation, testing, scaling, and team design.
I pulled those notes into a browsable site with 56 laws, grouped into categories, with short explanations and separate pages for each one.
The goal was simple: put these ideas in one place, so when you want a quick refresher on Conway’s Law, Brooks’s Law, Gall’s Law, Hyrum’s Law, or Goodhart’s Law, you can find it fast.
I’m more interested in criticism than praise. Which laws are missing, which ones feel overstated, and which ones get misused most often in real work?
When I first picked up Software Engineering at Google, I expected another Big Tech flex, with practices that only make sense if you have a billion users and 30,000 engineers. But I was wrong. The lessons in this book are universal and apply whether you’re on a team of 5 or 5,000. It draws on 2 decades of experience from an organization that runs 2+ billion lines of code and changes 25 million lines per week.
The book isn’t about programming, per se. It’s about the good engineering practices that Google has used over the years and decades to keep a healthy codebase.
In particular, it is about what happens after you write the code: how you evolve it, share it, test it, and eventually delete it.
Have you ever noticed how certain people manage to navigate obstacles with ease while others get stuck at the first sign of resistance? Some people seem to always find a way forward, even in challenging conditions.
This fundamental difference often boils down to a single trait: High Agency.
I love books. When I look at the 5000 books on my bookshelf, I see more than paper and ink; I see a personal board of mentors I never had. Over the years, as an avid reader, these books have quietly reshaped how I approach coding, leadership, and even thinking itself.
Early in my career, I assumed improving my skills was all about writing more code or learning the latest framework, like everyone else. But the most significant improvements in my growth came from hours spent flipping pages in some of the best books out there.
There’s something tactile and deliberate about reading, scribbling notes in the margins, dog-earing pages, that forces me to slow down and reflect.
Here, I want to share five books that influenced my journey from engineer to CTO the most. Each of these books contributed beyond just technical knowledge; they challenged my assumptions, introduced new mental models, and ultimately changed how I work and lead teams.
Technical debt has haunted development teams for decades, yet remains surprisingly difficult to explain. Everyone has their definition of Technical Debt. You will probably get three different answers if you ask three people what it is.
Google recently faced this challenge at scale – a substantial percentage of its engineers reported being blocked by “unnecessary complexity and technical debt” in internal surveys. In a paper titled “Defining, Measuring, and Managing Technical Debt,” Google Engineers Ciera Jaspan and Collin Green systematically understood this concept that slows down even the most talented engineering teams.
They tried to answer the following questions: How do you measure something so intangible? And once you identify it, how do you manage it without halting new development?
This research matters because technical debt is often blamed for productivity issues, but rarely defined or measured with precision. Google's work offers concrete strategies that any engineering organization can adopt.
