Today, I would like to talk about a specific thing that improves the programmer’s value. This thing is the ability to be critical. I will focus on the programming perspective because, first, you are here to read about it, and second, I believe this is a space where being critical may be very beneficial. The trait is displayed at many different levels during development, which I will describe later, but let’s start with the main question to understand the subject better.
Why should you be critical?
Being critical means that you won’t put up with things you disagree with, based on your knowledge and understanding, express it clearly, and potentially lead to an argument to solve the issue that is before you.
In programming, that may be a handy thing to have because when you do not agree with the decision or a different perspective, you may enter the discussion and, thus, improve your understanding. That could result in you changing your mind or simply seeing the other view and learn why it creates such an issue. The mindful conversation is the best way to solve disagreements and improve your team and yourself.
The next thing that matters is your value as a part of the solution. When you speak out and bring a vital subject that no one would rise otherwise, you introduce a real value to the thought process and the final solution. This kind of constructive critique may prove your position as a relevant participant.
Examples of being critical in the programming world
It seems pretty evident that not agreeing on everything and constructively critiquing may benefit you and your business environment. After all, it is a valuable behavior in most workplaces, but let’s dive into some specific examples from the programming world and see what you should pay attention to with your critical mind.
Be critical of business ideas. I will start with your interaction with a business branch of your company. You should expect that a discussion between business and IT brings up issues that would never come up without the debate. That is because understanding the system and the idea of what’s optimal is very different on both ends. That’s why it is crucial to be critical about various ideas and to explain your position in detail. Critical thinking and mutual understanding may be the best way to achieve a perfect cooperation between business and IT.
Be critical of an old code. When you commence actual coding, you should remember that there is rarely a code you should never modify, especially when you find a perfect reason to do it. First of all, you need to know what it is and why does it work that way. Having that, don’t be scared to suggest improvements or even a rewrite. Usually, the old code that no one touches remains like that not because it is so superior, but quite the contrary, it is poorly written, outdated, and people are scared of it. Don’t be frightened!
Be critical of dependency libraries. The rule of thumb is that you should choose the solution for your needs and not the other way around. Don’t fall into believing that “it has to be that way,” which is usually the thing with various libraries or frameworks. They are created for a general purpose and rarely correctly address all the issues that stand before you. Think your way through this, and choose tools to assist your implementation. The relevant distinction is recognizing current standards and abiding by them because you rarely work alone on a project. However, when you may devise the whole solution by yourself, learn from others, but implement your own plan.
Be critical of code review. After the implementation, there comes this valuable time of code review, which, when appropriately done, brings a lot of value to everyone engaged in it. When you review someone’s implementation, do it with diligence, understand the reason behind the code and ask when clarification is needed. Remember that your work here is to make sure that anyone who will read that piece later will understand it easily.
On the other hand, when your code is under review by someone else, and you are about to change something, make sure that you understand what is wrong and fully agree with the suggestion. Don’t accept it indiscriminately. The reviewer may also have the wrong context and make a mistake. Be critical if needed, and fight for your idea until proven wrong. It is your code after all, you are the one responsible here.
Be critical toward others and yourself. Politely and constructively, of course. When working in a team, it is crucial to summarize your progress and learn from your mistakes regularly. Be open and try to receive as much feedback as possible. During retrospection, try to provide valuable comments to others. When something is off, speak out, and when something is wrong, describe the issue, and suggest a solution or at least your perspective. That kind of voice is very beneficial to the whole team. Unfortunately, it is not easy, and you need practice to do it well.
How to be critical?
Well, as you’ve probably noticed, I used the term “being critical” in the context of standing up for yourself, speaking out, and embracing your understanding of the matters. All of this should happen in a mindful and educated way. Critical thinking is the best method to be professional and prove your value as a programmer. Being respectful and sticking to the facts will gain you respect from others.
The main takeaway for you is contributing to the environment where good critique is welcomed, and people may gain the most knowledge. You should embrace others and be embraced by them to speak plainly and communicate better. There is nothing worse than a perfect system where no one has any doubts or preferences. Be critical and advance alongside your team!