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.
Top comments (11)
I think this practice applies better to discussions of style or technique rather than actual mistakes. I agree with you that mistakes should be blameless, talked about frankly and without shame. Style disagreements, however, can be tricker because they're based on matters of personal preference and are tied more closely to our identities as developers.
For example, if I'm looking at the existing codebase and one of my teammates disagrees with the way I extracted a method, if she says "why did you do it this way?" this frames the question as an interrogation of my personal style choices. Asking "why do we do it this way?" acknowledges that this is a design decision we've adopted as a team (since my code has made it into production) but could perhaps be done better. That means that the question is coming from a shared responsibility to make the codebase better for everyone, rather than a personal distaste for someone else's style.
Of course, ideally, we all keep our ego out of our code and our judgment out of our questions, but as we live in an imperfect world, this seems like a good workaround to me. :)
Compassion will lead to better code.
We all should be aware that we are all noobs. We are all proceses. We fail, we grow. This is something we encourage.
If shame is something that an individual feels, then calling it 'our code' won't change the fact that the individual knows it is his/her attribution that is subject of the current conversation. Feeling shameless can only happen when people aren't shaming or bashing co-workers.
Using 'we' or 'your' does not change the fact that something happened that needs attention. I think that we should always try to be friendly and show compassion, knowing that nobody is perfect.
In my experience, arguments based on vocabulary use go absolutely nowhere with the vast majority of people. Few people analyze their vocabulary, and even fewer care. To try to force a vocabulary change to instill a new perspective is putting the cart in front of a horse and expecting it to follow. Would it not be better to point out a new perspective and see if the vocabulary follows?
No estoy totalmente de acuerdo con tu exposición :) Creo que cuando alguien programa una gran parte del código de una aplicación o feature debe asumir la responsabilidad del mismo, y se puede preguntar con un "Por qué lo has hecho así?" perfectamente sin necesidad de ser agresivo en la exposición.
Me gusta ser directo en mis preguntas, pero no por eso voy a ser agresivo de ningún modo, ni lo intento ni lo deseo. Me gusta que la gente se haga responsable de su código, al igual que yo lo hago del mío y el equipo del trabajo en equipo. Yo pregunto "Por qué lo has hecho así?" del mismo modo que respondo "Lo hicé así por este motivo".
Escribir código es diferente al enfoque o análisis, donde sí puede ser más un "Por qué lo hemos hecho así?" puesto que muy probablemente a ese punto se llegara después de un debate a varias bandas.
No me gustan los rodeos :P
Thanks for share your view :)
Via Google translate for me:
I see your point, but still think this is a good guideline for us. I think production code quickly gets swallowed up into the codebase and the longer it's there, the less the writer of it has a relationship with the current context. As the app and the users evolve around the block of code an individual wrote, the context in which they wrote the code begins to apply less and less, to the point where the answer is "because things were different back then". As context is muddied, so is ownership.
As I said, it's a small thing, and I think it will help us. I think it's generalizable, but is mostly just food for thought.
I understand you perfectly.
I do not want on any way to confront or blame anyone, only to understand and correct what is happening. We are a team, and we work as a team, but code is written by persons. If I need help with the code that I'm writting, I don't say: "Please, can you help me with this piece of our code?"
Anyway, in case of doubt, on minimal doubt, about who written the code, the code is our :)
I think that Richard explained my view best as me.
Best regards and sorry my "alien" english :)
I believe in blameless programming, yet at the same time I believe people can be responsible for pieces of code. For example, I'm working on a charting feature, I'm the only person involved in this component at the moment. It seems silly that soembody wouldn't directly ask me about the design decisions involved since clearly I made them.
Similarily, if I spot a questionable code change, or something that has caused a defect, I might use
git blame(terrible command name) to determine who made the change. I don't want to blame the person, but I want to figure out why they made the change. There's no point in questioning the ehtereal "we" when we can question a concrete individual.Yes, so much this! As code evolves, mutates, or just ages it's so easy to forget that there were developers that sat under different constraints, beliefs and goals doing their very best. I personally find this extremely challenging, fun and also rewarding when finally connecting the dots.
Embracing shared code-ownership is something I value, and have found to be of great value in our teams. Avoiding a culture of blame, but rather of responsibility by owning our mistakes. Celebrating and sharing them with others and growing, together.
👍🏽
This is natural, and really important to be able to do in a mutually respectful way. Respect the developer, be critical to the code ❤️.
At the end of the day, the sum of every developers effort is what builds a product that hopefully enriches a little bit of somebody's day. Built together, Owned together.
It should be a case of criticising the code, rather than the person - 'you' feels like a finger in the chest - 'what was the thinking behind this code here' compared to 'what were you thinking when you wrote this code here'.
Also 'we' sounds passive aggressive - 'could we change this colour here?' - well 'we' could, but I will make the change.
I'd go with the passive voice, and let the work do the talking - it leaves it open for people to take ownership. 'What's going on with this code here' - 'ah, that's me, I thought we could xyz at this point' - 'ok, maybe it could abc instead'.
What are your thoughts on speaking to only the code itself, uninformed by who wrote it and reviewing code without involving the "you" or "we"?
e.g. "This code" vs. "your / our code".
I think this leads to a team mindset on focusing on achieving most logical code because at the end of the day the code does not concern itself with who had written it.