3 x Yes for “No”. A crucial skill every professional programmer should have

Are you a hero that knows a couple of programming languages, yet not a superhero, since you lack your superpower? How is it possible that someone has the same knowledge, but looks more professional? Maybe you just don’t know how to say “No.”

How do we constantly try to avoid saying “No”?

Do you know situations where your workmate tries to force you to do something faster? In order to justify their request, such a person would probably say something along these lines: “Well, it is crucial to the project and we have to expedite it.” It’s always the same old song and dance, each project is the most important and has to be done yesterday. It’s a normal situation. 

Your Project manager is responsible for the timely delivery of the project and these are their obligations. It would seem that this responsibility lies only with that person, right?

When you want to be a professional programmer, you should also be responsible for the project, sometimes even more than the rest of the team. So isn’t it a perfect situation for both sides? What is wrong with someone trying to rush you?

In fact, in such cases, we tend to forget about our opportunities, perspective, and our knowledge of how technologies and systems work in a given project. You know best what is possible to do and how much effort is needed to do your tasks. Instead of being assertive and expressing our doubts that finishing the project is impossible, we agree with our Project Manager. 

What happens at a moment like this? We abandon our rules. We do not care about clean code principles. We promise that we will go back to this code and we will fix it later. But, in fact, we will not have time to go back to it because new obligations, issues, and errors are already waiting to fulfill our time. This code will not be our proudest brainchild.

What is the first thing that comes to your mind when your workmate comes to you and tries to force you to end a particular project as soon as possible, e.g. ‘this week,’ but you are fully aware that, in the most optimistic version, you still need one more week? Do you like them and you don’t want to let them down? Do you want to say “We can try” or “I will see what we can do”? And here is a problem. For your Project manager, it is such an optimistic message. You can be sure that the client will be informed that the project will be ready this week. You made a promise that you are not able to fulfill.

You should be more precise and assertive. You can try saying something like “Sorry, but it is not possible to end this project this week, we do not have enough resources to resolve so many tasks.”And it is precise information that you cannot promise something impossible. You gave specific information without any hidden hopes. 

On the other hand, you can think about what it in fact means that you can try to do it. Does it mean that you will work more effectively or faster now? So to this moment, you have not been working hard enough, or maybe you have not been fully engaged in your work? What you are saying is that you will need to have a supervisor to stay consistent with your pace from now on. This is not professional behavior. As a professional, you do whatever it takes to get your work done as perfectly and as quickly as possible. Before we give a promise, we should consider how we can achieve the goal and where we want to find superpowers to make impossible things possible.

Do not go there!

Who hasn’t screamed at least once while watching a horror movie when they knew that their favorite character was on his or her way to meet a psychopathic killer? When you are not able to meet obligations, you are on the same road. How can we stop our character from going there? 

The base is simple. You should always be transparent with your environment, be it your client, project manager, your team. Everybody should be informed about the status of your work and about impediments with which you are struggling. It is so relevant because then everybody is aware of what is possible and what is not. Nobody will understand why you spend a lot of time on this project if you always inform the team that everything is going well. 

It is crucial to say “No” at the right time and in the right context because this is part of being transparent. You cannot make promises which will not be fulfilled. Of course, saying “No” and being firm in your decisions may prove challenging since we do not want to be rude to somebody. But it is only simple information without emotional or personal connotations. It is only the cold result of your professional expertise.

We are professionals and we need to be responsible for our words and decisions. Our responsibility is to inform everyone who is involved in the project as soon as we know that we have an issue that can impact our deadline or the scope of the project. Start with small steps. Inform about your doubts; when you see that the deadline might be overly optimistic, let others know immediately that a safety buffer should be added. 

Don’t wait until you find that you have a week until the deadline, but you see that you have too much work. You probably knew this earlier but didn’t communicate it in time. And now it may be too late to make some good decisions and make good moves. We should be transparent each day, even if some news is not so good and we should not avoid saying “No” instead of “I will try.” This may be our missing piece to becoming a professional programmer. 

Small steps to big changes

If you think now that you need to work on your assertiveness, it is the perfect time to take a few  small steps to reach your new superpower. 

1. Inform about your doubts immediately
   If, during a discussion, doubts arise in your mind or you think of obstacles that might occur during the project—don’t wait! Bring it up as soon as you can stop the discussion and make your point. If you think about it for too long, you may start to consider your idea stupid and pointless.
2. Your opinion matters
   You can imagine that anything you feel you should talk about could be important to your teammates or clients. Everything created by your brain can be valuable to others. Do you want to keep the work of your brain to yourself? This can be selfish. Therefore, don’t worry if someone thinks your idea is wrong. You have a good chance that it will be of value to your audience.
3. Expertise is in your hands
   You are closest to all systems, a lot of the time tangling in spaghetti code. You know about structure limits and about malicious trolls in obscure functions just waiting to destroy all environments. You know a lot of weird secrets like nobody else. If you don’t talk about it, no one will know how simple things can be complicated to implement in this project.
4. It can hurt, but only for a second
   Someone presents an idea or a new feature. But you can clearly see that this is not the right way. I know that interrupting and criticizing others’ ideas may prove difficult. But there are two things that are likely to happen if you don’t present your criticism. When you accept something that, for instance, should have been done in a different way, you are likely to struggle with it later. The other thing is that maybe for a while someone might feel uncomfortable when you go against those carefully laid plans. But really, when you combine your ideas together, they will only have more value, and in the end everyone will benefit from it.
      

“No” is not rude

You are a perfect programmer. All the issues are only simple challenges for you. But you are still afraid when you need to express your objections and inform your bosses or colleagues about your doubts. That may be the reason why you are not perceived by others as a professional. Remember that you are an expert in your field and your expertise and opinions—even if unpopular—can be crucial to success and client satisfaction.

Why does the world need superheroes? 

Good, but I am a programmer and I know how to write the best code. Why do I need to know about these different things which are not even related to writing code? Does it make any sense? 

I think it does. There are a lot of people who are really good at writing good applications. They are able to do a lot of proper things. But even if we believe that programming is only about writing code, it is simply wrong. In my opinion, the success of a good software implementation does not just focus on the code. So what are the additional components? 

To put it succinctly, these include a lot of discussions, ideas, sometimes conflicts, negotiations, and tons of daily communication with people. I’ve heard a couple of times the excuse: “I am a programmer because I do not want to talk with people.” But, unfortunately for these people, we are constantly forced to work with different people and cooperate with different teams. And we should know how to demonstrate our point of view, present our differing opinions, and be assertive.