Merged code belongs to the team, not the individual. Our language should reflect that.

Ben Halpern on May 12, 2017

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, w... [Read Full]
markdown guide

I'm unpersuaded. 'Blameless' means getting rid of blame altogether, not shifting blame from individuals onto the group. If I ship a bug, and I would not be comfortable with how the team is about "our" mistakes if they were instead talking about "my" mistakes, then either my attitude is wrong (I am not willing to come to terms with my own fallibility) or the team's attitude is wrong (they are treating mistakes as crimes to prosecute, rather than problems to solve and opportunities to learn).

If my team observes a teammate coming to me with "Hey Richard, I think there's a problem with the code you just shipped" and then us discussing it in a non-defensive and non-blameful way -- that is what will make them less afraid and more comfortable to discuss mistakes of their own. If we rhetorically sidestep this and talk about "we" shipped a bug, then individuals making mistakes becomes a taboo, and a taboo is something to be feared.


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. :)


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.


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.


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.


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 do not entirely agree with your exposition :) I think when someone programs a large part of the code of an application or feature they must take responsibility for it, and you can ask with a "Why did you do it like this?" Perfectly without having to be aggressive in the exhibition.

I like to be direct in my questions, but that's not why I'm going to be aggressive in any way, neither try nor desire it. I like people to be responsible for their code, just as I do mine and the team work team. I ask "Why did you do it like this?" Just as I say "I did it for this reason".

Writing code is different from the focus or analysis, where it may be more of a "Why did we do it like this?" Since it is very likely to come to that point after a debate on various bands.

I do not like rodeos: P

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 :)


Our codebase is the collection of deadlines, constraints, necessary hacks, or unforeseeable mistakes...

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 a guideline, not a rule.


When the idea is fresh, it strikes me as okay to ask "Why did you make this choice?".

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.


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?


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'.


I'm not sure I buy this argument. It is a delicate balance between having a coherent vision and collective ownership of a code base. Ideally we'd all be egoless programmers and not take things personally when our architectural decisions are called out. What I've observed in the field is that without an architect driving decisions and keeping things consistent the codebase invariably falls into disarray. Treating it as a collective asset encourages and sometimes accelerates how quickly things fall into disarray.

In my opinion you need a clear owner. The buck must stop somewhere. Ideally it should stop somewhere egoless and not necessarily blameless.

code of conduct - report abuse