I'm sharing an internal memo publicly because I think it applies to everyone. Feedback is super welcome.
When commenting on other people's code, whenever possible, we should be using terms like we and ours instead of yours and mine. Everyone owns all the code and there are important reasons for adopting this language.
Our codebase is the collection of deadlines, constraints, necessary hacks, or unforeseeable mistakes. Asking "why did you do it this way" instead of "why are we doing it this way" can promote feelings of shame or defensiveness. We need to make it easy to discuss our mistakes and accomplishment with the fewest barriers possible. A blameless culture is the way we will achieve this. The appropriate bug rate and mistake rate is not zero. An organization that does everything perfectly will never ship code. We will take pride in our work and recognize that no individual contribution exists in a vacuum.
This is a guideline, not a rule. There are plenty of reasons to stray from this spec and none of us choose our words perfectly all the time. In general, however, let's try to take collective accountability for our contributions and mistakes. Nobody should be stifled by the fear of letting the team down.
This mostly applies to code that has been already committed and/or merged. When the idea is fresh, it strikes me as okay to ask "Why did you make this choice?". When visiting existing code, the it is more appropriate to ask "Why did we make this choice?" even when talking to the person who totally wrote that code themselves. Even the code written by your past self could benefit from being viewed through this lens. It's easier to fix the warts in the codebase we actively talk about. Most of the time, the person who wrote the code is most aware its warts, but if they feel overly guilty, they may avoid bringing up the issue as often, or at all.
Likewise, there don't need to be superstars on the team. We disperse credit, like we disperse blame. We will obviously credit each other to some extent, but always remember that we are a team looking to set each other up for success, not strive for individual accolades.
It's a small thing, but it will help us ship better code.