Imagine a situation where someone new joins a company and, in their first few weeks, starts criticizing the code with their colleagues or even publicly. I've seen this numerous times and what I can say is that almost everyone (including you and me) has probably done this at some point.

This isn't exclusive to product companies but also applies to software developers working at consulting companies. I've observed numerous consultants, from my previous experience as one, doing the same with their client's code.

This is completely normal, and you don't need to feel embarrassed about it, but we should shift from a mindset of criticism to one of inquiry: "Why was this built like this?"

Criticizing someone else's code not only gives the impression that you are an naive but also could decrease the morale of the team and affect individual growth.

What Makes Good Code?

If the first thing that comes to your mind is good naming, good separation of domains/concerns, code that is easy to read, and so on... you are not wrong, and yes, those items can indicate good code, but they are abstract. Good code can mean different things to different people, but there are some indicators that I have observed in the last companies I've worked for:

• Presence of strong style guides: Companies tend to enforce style guides to maintain a more cohesive codebase.
• Presence of strong architecture: There's no perfect architecture, but always an evolving one. One thing I've seen multiple times is companies where the architecture is always improving based on developer feedback and the growth of the company/product.
• Strong presence of testing: This is not optional. Testing guides our code design, although I've seen companies with a huge amount of code coverage but with code that is very difficult to read. That's not the norm; on the contrary, I've seen multiple companies with a strong testing culture and the result was robust code design.

The key to good code, in my opinion, is simplicity, even the most complex algorithms can sometimes be broken down into multiple small and simple parts.

There are also some other abstract indicators of good code:

• Efficiency
• Readability
• Easy to understand
• Maintainable and easy to extend

Why We Criticize

This isn't scientific, but I have some assumptions about it. As we gain more experience and become more senior, we start to see some repetitive patterns across companies, and due to our experience, we sometimes just look at some code and say: "Oh crap, this code is so hard to understand that if I change anything here, I don't even know what can happen."

Sometimes it's not our experience, but our bias from previous companies. When we have worked for a long time at a company with a defined style guide and we get adjusted to it, changing to another one can make us critical because we were accustomed to an old way of coding.

We also tend to compare things, and sometimes comparing someone else's way of doing things with our own, while there's no right way to do some things, e.g., naming variables is hard, and if you put 10 developers in a room to discuss a name, almost all of them will come up with different approaches.

Let's Change This Mindset

So instead of just criticizing code, ask yourself:

Why was this built like this?

And here are some factors:

• Lack of knowledge of the domain: Even the most experienced developers fall into this, and it is more common in the startup world where they are trying multiple things to fit into the market. Developers tend to follow this trend by building software with the knowledge they had at the moment. Since startups are always evolving, it's hard to justify a huge refactor.
• Pressure to deliver: I've seen this a lot. There's a hard deadline to deliver a project, and something needs to be cut off; sometimes it's easier to justify tech debt that might be paid in the future than to delay the project.
• Lack of experience: This is also common. Technology evolves a lot, and if we look at the code we wrote five years ago, you will probably say: "I can't believe I wrote this code." Technology evolves and so does the way of writing software.

So the next time you find yourself wanting to criticize someone else's code, just be empathetic and try to understand why it was written the way it was, and by doing so, ask in a kinder and more genuine way and propose ways to improve.

You can always learn and make new friends in the process.

Happy coding ;)