- There is a trade-off between short-term efficiency (“It’s faster for me to do it”) and long-term efficiency (teach others how to do it)
- Parroting / mimicry: Mindlessly copying code without really understanding the purpose
- Documentation scales better than personal advice. Both are necessary and sometimes also something in-between (i.e. someone recommends a certain piece of documentation)
- Psychological safety is important. People need to be comfortable in saying they do not understand things, otherwise it is hard for them to learn and get help
- Avoid (similar to the recurse rules)
- Feigned surprise (“I can’t believe you didn’t know that)
- “Well, actually"
- Expressions of bias
- Interrupting a conversation to give an opinion and then leaving it again. Commit to conversations if you think it's important enough to interrupt
- Context
- Can really help to make you understand something, e.g. in style guides
- Chesterton's fence: Before removing or changing something, understand why it’s there (imagine a fence)
-
People react to incentives over platitudes
- Readability: Special approval in code reviews for writing readable code in a given language
- This is a way to improve code reviews but also a way to share knowledge
- Furthermore, it ensures that all of Google’s code is held to the same standard and style, which avoids tech islands appearing inside of Google
- It’s quite costly as such a program does not scale well. Google considers it to be worth the cost though and internal research showed that it has a big impact on code quality