Notes from Software Engineering at Google Book
I started reading Software Engineering at Google: Lessons Learned from Proramming Over Time. So far it has been an insightful read of the best practices that Google has arrived at from over two decades of world-class software engineering.
Although a lot of the material applies to large organizations, the real takeaways are the why behind how they arrived at their processes. Organizations should not blindly apply what works for Google, as they are based very largely on their context. The authors encourage the readers to think about why before arriving at their own set of software engineering practices.
Ch 1: What is Software Engineering?
Software engineering is programming integrated over time
Programming is concerned with producing code. Software engineering is concerned with producing code and maintaining code over the course of its usable life span. Usuable life span can vary by many orders of maginude, such as from a few hours to several decades.
On Software Sustainability
Software is sustainable when, during its life span, its developers are capable of responding to changes in:
- dependencies (e.g. libraries, language versions, OS versions)
- product requirements
- technologies (e.g. cpu, faster hardware).
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.
This is to say: if you have some internal behavior in your software (e.g. you maintain a library that is used by another used as a dependency in some node.js app), there will always be some user that will rely upon on that behavior, even if you do not state such behavior in your API contract.
A classic example is relying on the order of elements inside a hashmap. You could write a test that expects a particular the order of elements when you iterate through the hashmap. However, it may so happen that the next version of your language or hashmap library could change the order of the keys when iterating through the hashmap. This is an example of “it works” vs “it is correct.”
Ch 2: How to Work Well on Teams
Don’t hide your code
- Getting early feedback will often save you time.
- Avoid fallacy of the Lone Genius.
- Share early. Share often.
3 pillars of working on a team
- Humility
- Respect
- Trust
Googleyness
Googleyness is a term to describe the described attributes around interactions and leadership and is enshrined in the following principles
-
Thrives in ambiguity - ability to deal with conflicting messages or directions, build consensus and make progress to solving the problem
-
Values feedback - has humility to receive and give feedback gracefully, and understands that feedback is an act of giving
-
Challenges status quo - able to set ambitious goals and persevere in the face of opposition or organizational inertia
-
Puts the user first - empathy for the user
-
Cares about the team - empathy and respect for coworkers, and actively helps without being asked
-
Does the right thing - a strong sense of ethics to do the right thin; willing to make difficult inconvenient decisions to protect the integrity of the team and product.
Ch 3 Knowledge Sharing
Setting the Environment
Pyschological saftey is a foundation for fostering knowledge sharing environment. New engineers should not be afraid to ask questions because they don’t want to look dumb in front of their peers.
Table 3.1. Group interaction patterns
Recommended Patterns (cooperative) Anitpatterns (adversarial) Basic questions or mistakes are guided in the proper direction Basic questions or mistakes are picked on, and the person asking the question is chastised Explanations are given with the intent of helping the person Explanations are given with the intent of showing off one’s own knowledge Response are kind, patient, and helpful Response are condescending, snarky, and unconstructive Interactions are shared discussions for find solutions Interactions are arguments with “winners” and “losers”
In an environment that is filled with antipatterns above, or that are dominated by billiant jerks: “novices learn to take their questions elsewhere.”
See Recurse Center’s Social Rules.
Understand Context
Learning is not just about understanding new things, but also understanding context of the decisions behind the design and architecture of a system. Before giving up and saying: “I don’t get it” try to ask “Why was it done this way?”
In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “If you don’t see the user of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.”
TL;DR: If we don’t understand how we got “here,” we run the risk of making things much worse.
Code Reviews
Code reviews are an excellent way for knowledge sharing. Google certifies certain engineers as readability reviewers:
“…have demonstrated ability to consistently write clear, idiomatic, and maintainable code that exemplifies Google’s best practices and coding style for a given language.”
Readability reviewers comprise 1-2% of Google engineers and are the only ones allowed to approve PRs (or Changelists/CLs as Google calls them). Despite the heavyweight process, internal studies at Google found it has a net positive impact on engineering velocity.
Thoughts
One thing I found interesting is that Google has a carrot and stick approach to knowledge sharing. On one hand, engineers can file documentation bugs in the code, which are treated with the same importance as a regular code bug. On the other hand, knowledge sharing is expected for higher roles in Google’s engineering ladder.
“Our software engineering ladder … encourages engineers to share knowledge by noting these expectations explicitly.”