Originally published on September 27, 2018, in Help Scout Engineering & Product on Medium. Republished here in 2026 as part of my writing archive.
We are code creators, and we become personally attached to the code we write. We may even think of a pull request as adding “my code” to a project. I believe that with a fundamental shift toward thinking and communicating about it as “our code,” we can create a more open and constructive working environment.
Shifting from me to we
In the context of chat, it can be easy to slip into using the first person “I.” This can reinforce the personal ownership of code. Consider the difference between these two Slack messages:
This simple shift in tone moves the class from being owned by the original author to being owned by the entire team. Small shifts in tone can promote shared ownership and make other developers more comfortable refactoring, improving, and extending code.
Here is another pair:
By rephrasing the question, we can immediately change how our team members engage with the code by framing it in terms of shared ownership.
A friendlier tone in code review
We can make a similar change to the language we use in pull requests and other discussions about code. We can minimize the use of “I,” “me,” and “my” and instead promote ownership and shared responsibility with “we,” “us,” and “our.” Let’s look at two ways to write the same feedback on a line of code.
In the first example, there is underlying blame. The meta-message is that the author has done something wrong. In the second, I’m asking whether there is a better option for us as a team. The tone shifts from “You’re wrong” to “We could be better.”
There is an exception for the use of “I.” It is acceptable and lovely when used to share praise and positive comments. Because we pour so much into the code that we write, receiving a positive comment from an individual can be personally validating and enormously rewarding.
Writing pull requests for shared ownership
In many projects, a pull request may represent the work of a single developer. In this case, it’s extremely easy to think of the code as “mine.” Instead, I urge you to consider it your contribution to the codebase as a whole. With this in mind, we can look at a final example.
The same content is delivered by both messages, but the underlying tone is quite different. The first example shows clear personal ownership. The second builds team ownership and promotes shared responsibility.
The benefits of shared ownership
If a coworker had written a particularly complex class and continued to refer to that code as “their code,” I might be less inclined to work on it. If there were a bug in it, I might even tend to blame them for the bug. If I were to work on that particular class, I might try to fix the bug with as little code change as possible—perhaps with a dodgy if statement instead of a proper refactoring. The complexity of the class would get even worse, and any subsequent fixes would only continue to degrade it.
However, with our change in tone, this particular class belongs to us. Now we have a particularly complex class, and I would certainly be willing to wade into improving it for the good of us all. I’d consult with the original author about how we can make it better for us. In the end, we’ll have code that is easier to maintain, and each developer can gain broader experience in the codebase.
Shared ownership is about building common goals, improving development velocity, and helping to prevent developers from getting siloed. Some developers may even be hesitant to comment on code if they think it will be heard as criticism of the author instead of a recommendation for “our code.” If the author immediately introduces the code as “ours,” it can elicit more open and productive discussion.
By removing blame from the tone of our communication, we promote a positive work atmosphere where developers can collaborate without hesitation. We can have higher-quality code, happier developers, and faster development velocity.
An experiment for you
You can experiment to see how this change in tone affects the way you relate to your coworkers. In your next code review or your next day of chat messages, try censoring your use of the following words: I, me, my, mine, you, and yours.
You can even go a little overboard with the experiment and remove those words completely from your language for the day. More importantly, read messages from other developers, then reread them as if they had been written with this new rule. See whether the messages affect you differently.
We’re all in these projects together, so let’s start communicating like it!