This book is written by a couple Google engineers, describing their understanding of what software engineering is and how do they manage a living codebase that evolves and responds to changing requirements and demands over the length of its life.
Chapter 1: What is Software Engineering?
A couple things to differentiate "Programming" and "Software Engineering":
- What is the expected life span of your code?
- How many people are involved?
- Complexity of decisions that need to be make and their stakes
Software sustainability question: "how much will it cost to do the things that we need to do repeatedly?".
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.
The right attitude should be that we can mitigate it but we know it can never be eradicated, similar to what we treat entropy. Just because entropy never decreases doesn't mean we shouldn't try to be efficient. Given enough time and enough users, even the most innocuous change will break something.
Churn Rule
Infrastructure teams must do the work to move their internal users to new versions themselves or do the update in place, in backward-compatible fashion.
Result: Dependdent projects are no longer spending progressively greater effort just to keep up. Also having a dedicated group of experts execute the change scales better than asking for more maintenance effort from every user: experts spend some time learning the whole problem in depth and then apply that expertise to every subproblem.
Beyonce Rule
“If you liked it, you should have put a CI test on it”
i.e., if an untested change caused an incident, it is not the change's fault.
Chapter 2: How to Work Well on Teams
Software engineers are insecure. People tend to worship genuis. Deep down, many engineers secretly wish to be seen as geniuses, but hold on, you're probably not a genuis.
What will make or break your career, is how well you collaborate with others.
Usually you don't need to be a genuis, but you need to know how to work with others, - don't be a jerk.
Then this chapter is mainly about not working alone, as you will have more risk of the things you are working and usually the progress will be slower. Also working alone adds the chance that no other people can take the project (bus factors) and help you look over your shoulder.
Fail fast and iterate
Sometimes, the best thign you can do is just say, "I don't know."
Basically, this chapter is about being "Googley", a term used inside google, but generally it is about being able to work well with others.
Chapter 3: Knowledge Sharing
It is important to have such psychological safety: to learn, you must first acknowledge that there are things you don't understand. Such honesty should be welcome than punished.
An enormous part of learning is being able to try things and feeling safe to fail.
Some social rules to be helpful
- No feigned surprise ("What?! I can't believe you don't know what the stack is")
- No "Well-actuallys" (Me: I used it quite often, got to stop using it)
- No back-seat driving
- Interrunpting an existing discussion to offer opinions without committing to the conversation
Growing your knowledge
Knowledge sharing starts with yourself. The take awya is "always be learning, always be asking questions".
Understand Context
Use "Chesterson's fence" here: before removing or changing something, first understand why it's there.
Tech talks
The topic should be relatively stable, as upadting the class materials is a lot of work.
As for engineer ladders (good for promo or perf :P)
At more senior levels, the ladder explicitly calls out the importance of wider influence, and this expectation increases as seniority increases.
Example of leadership includes:
- Growing future leaders by serving as mentors to junior staff
- Sustaining and developing the software community at Google via code and design reviews, engineering education and development.
Chapter 4: Engineering for Equity
Chapter 5: How to Lead a Team
Worth a revisit when doing manager roles.