Software Engineering At Google Part I

As one of the authors said in preface: “I have always been endlessly fascinated with the details of how Google does things. I have grilled my Googler friends for information about the way things really work inside of the company. How do they manage such a massive, monolithic code repository without falling over? How do tens of thousands of engineers successfully collaborate on thousands of projects? How do they maintain the quality of their systems?”
These and many other questions are my questions, and I guess yours too. If you want to get answer to these questions, I strongly recommend you this book.

Does these technics work for us?

It depends! You might find some of these technics useful for your team or your comapny. Eventually you have to find “your way” of doing complex things. But this books in my opinion, can be very helpful. I want to share some highlights of this book with you here.

Chapter 1: What Is Software Engineering?

• Programming is the immediate act of producing code.
• Software engineering isn’t programming. It is programming integrated over time.
• 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.
• 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.
• We’ll readily commit to “For most projects, over a long enough time period, everything underneath them might need to be changed.”
• If costs [of changing something] grow superlinearly over time, the operation clearly is not scalable.
• The more frequently you change your infrastructure, the easier it becomes to do so.
• Finding problems earlier in the developer workflow usually reduces costs.

(This post will be updated)