Context

I heard a very interesting thing when being in the middle of yearly review call.

During a code review some unknown time ago I unfortunately asked someone (don’t know who) to not implement something in a specific way. What’s worse I did something similar in a code. Regrettably I don’t remember that, but probably I forgot explain my point. How dare I? What a hypocrite!

My mistake

I think my only mistake was not making 100% sure that the other person understand my point of view. I should state it very clearly, why they should not do a given thing with our codebase even though I did something similar in the past. My only excuse is I have always a lot in my plate (but I still try to help my colleagues), so probably I did not explain my point because I simply did not have enough time to do it properly.

The other side of the table

Why AFFECTED person did not ask me for details?

I truly try to understand that. Through my whole career, I have constantly asked questions to people who are more experienced than me because I want to understand things as deeply as possible.

This situation could have been resolved with one additional question.

Comments in the code review should not be perceived as orders

I am working at a company that has very flat structure. I feel like everybody in the team is equal.

Also, based on my experience with code review. My comments are only tips or advice to the person who wrote the code. When I am telling someone that they will shoot in their knee, they still can do it and I am ok with it.

But there is one exception

If you are changing the code that the other team maintains, you should follow instructions. Because maintainers always have more experience with it and knows what and when could be done or not. In addition, I think this is the case I wrote in the context section.

In other words, I won’t let you shoot in your knee if I will be asked to fix that later on…

Maintainers could do more than people that are clients of the code

Of course this is my opinion. If you are creator/maintainer of given code, then you could do with it some things that are restricted to the other teams.

Why?

Because (again) you know all internals of the code, know all edge cases, how this code performs etc.

Example

Let’s consider a feature flag module (it’s a very common module in SaaS applications, I think). It’s created by one team and exposed to the other teams inside a company. From my perspective feature flags should be used for technical things only - like things that our customers couldn’t see or manage. E.g.:

• switching on or off given module in the app
• changing internal configuration of given module
• etc.

So if you spot a case, where someone is using this module as normal config of the given module (that could be changed by end users). What would you do? For sure, you will ask this person to not do that, but do in other way - I mean implement normal config managed by customer in this case.

Summary

I know I should explain my point of view more, but as I told sometimes you don’t have time for it. When you are maintaining code that is used by other teams.

Things that I should improve

• Always write documentation that will describe all use cases in a clear way
• Be more precise during code reviews
• Ask more often if everything is understood

Please let me know if you have any other observations!