Talking in Plural at Work

Note: in this post I refer to programming and code, but I think it can be applied to any work environment.

After 6 years programming, I realized I’ve sometimes felt like I was in charge of some specific code and other parts of code were not under my control and I shouldn’t touch them. This might feel natural, some code was written by me and other wasn’t, but this way of looking at the code sometimes turned out to be counterproductive.

In some cases, I felt a bit scared of touching code that I wasn’t familiar with because I was prone to break it due to lack of knowledge about the big picture. In other cases, I was being lazy and I didn’t want to spend the time on something I wasn’t familiar with and specially “fix someone else’s problem”.

I didn’t like that kind of thinking and I wanted to get rid of it. I started to think in plural, instead of thinking on “my code”, “your code” or “other teams code”, I just thought it’s “our code”. At the end of the day all the code ends up in the same shared repository, anyone can (and will) modify it. You won’t care about that code in 5 years, if you change workplaces you won’t take your code with you, you won’t think about it as “yours”. Why wait so much to divorce the code we write? I decided to do it right the way.

Thinking in Plural

Instead of thinking about “my feature”, “my bug” or “my system” I just started thinking on “our feature”, “our bug” and “our system”, even though I was the one working on that specific feature/bug/system till that moment, at any point someone could step in and start making changes.

Thinking in this way helped me become more proactive in several aspects:

* Proactive to write better code in first place: If I’m working on something, I try to make it as easy to understand and try to avoid obfuscated approaches. This is something we should always do, but sometimes (at least for me) the thought “when I come back to this code I’ll know what’s going on” allows me to be lazy and I don’t write proper code. By thinking that the next person touching this code won’t be me it becomes an obligation to make the next persons life easier and write good code in first place. Because is not “my feature”, is “our feature”.

* Proactive to improve code: when I find some code that looks obfuscated or a bit hacky, instead of complaining about it (in my head, of course) because is making my current task harder, I just remember is not “someone elses” code, now is also my code and it’s my job to fix/improve it. I usually don’t feel happy about it, but I also know that I’m the one doing those kind of hacks, in some cases, and other person might have to un-hack it (yes, I know, this means breaking the previous point, I sometimes still go the easy way, but over all I’ve managed to do the correct ones more often. No one is perfect and we know there is always room for exceptions : ).

* Proactive to take and work on any topic: fixing bugs can be exhausting, specially if the bug comes from someone else’s code. Again, the bug is in the codebase and that means the problem involves everyone. This also means taking some extra time and trying to fix the bug even if the fix is not in “your” code, you can always learn something new by trying to fix it. If the fix is not the proper one, in the code review someone will let you know and you will learn something new about that code.

Just changing the way I thought about the code allowed me to improve as a programmer, so I decided to take this one step further and not just Think in plural but start putting those thoughts I had aloud by Talking in plural.

Talking in Plural

The part I like the most about thinking in plural is when I say those thoughts aloud, here’s what I like about it:

* Give credit to everyone: By talking in plural you are not removing credit from anyone. You might have worked on 99% percent of something, but for sure more people contributed to it: other programmers giving ideas on how to approach the problem; the people that wrote the code you relied in; or the final user that came up with the idea/necessity to have the feature (the reason you are able to work on something is because someone needs it).

* Communicate better: In many conversations I was constantly trying to figure out if I should refer to some feature as “mine”, as “some else’s” or as “ours/theirs” (as a team). By referring always in the plural way (“my teams feature” or “this teams work”) I can focus on explaining the main topic. On the other hand, if I start saying specific names I might make a mistake, someone else might correct me and at that point we already drifted away from the main conversation. By keeping the talk in plural I focus in sending the main message and others are not distracted with details, if someone needs/wants to know specific names, she will ask.

And now you might be thinking:

But giving credit to everyone means occluding the credit of the main person that worked on something…

Is not about removing credit from individual people. I think everyone loves when someone receives kudos for her work (and we should do it because keeps people motivated). I love when someone tells me I did a good job. In those cases, I express my gratitude for the compliment and then I mention that my work was only possible thanks to a lot of features and code that was already there; thanks to the original idea and all the people that helped develop it into its final form.

But not mentioning who worked on specific topics when talking to others means that people won’t know what I worked on and how smart and good worker I am and how much I deserve to be promoted (and I could keep going with a list of things)…

Everyone likes to receive credit, we like it so much that we usually crave for it, our ego is always hungry. By talking in plural I make sure  I keep my ego shut up and focus in what is important, sharing the information about the feature. If someone is latter interested in who developed something it will ask. And it’ll mean double gratification, it’s so good that people got interest about who was the mastermind behind it!

---

Before trying this actively I was already using the plural form sometimes at work, but when I tried actively to use it in all cases I realized about most of its benefits. Now, thinking and talking in plural is natural to me and I like it, I’m more open to handle work that before I sometimes didn’t feel like doing and I find it easier to communicate. Giving credit to all the people is just an extra of talking in plural and it makes it feel much better.

P.S. Talking in plural sometimes is costly (fun fact)

Here is one conversation I had some time ago with my producer:

Producer: Could you take care of this bug?
Me: Is not for us but I could take care of it.
P: Come on, is not a matter of being for us or for others, it needs to be fixed and this other team right now is overloaded.
M: Sure, I agree with you, what I wanted to say is that I’m not familiar with this code and I’ll need to learn first, the other team will probably know better what’s wrong and will take less time for them to fix it.
P: Oh, okay, then take care of it please 🙂

Since that point on we understand each other better, when I say “Is not for us but I could take care of it.” he knows what I mean and reacts accordingly.