Programming is in many ways a creative process suggesting that the same problem can be solved in different ways. But the developer needs not only to choose the optimal solution but also to justify it to the team or the client, and this can be difficult. In the process of discussion, you can hear a lot of demotivating criticism, but you still can’t find the necessary arguments to convince your opponent. How to learn to defend your point of view at work without experiencing unnecessary stress?
We asked one backend-developer.
The fear of expressing and defending your opinion is one of the main problems that many novice (and not only) developers face.
At the very beginning of my career, even before taking over my current position, I was very afraid that my colleagues or the customer would beat all decisions to pieces. It was scary that my implementation option would not be accepted, they make a “cuckoo” sign or start a conversation about frameworks and libraries that I know nothing about. It was especially difficult in verbal communication: if I could substantiate my decision in writing, then in a live conversation I quickly got lost, especially if there were many participants. Therefore, for a long time, I purposefully avoided any verbal discussions – phone calls, meetups, retrospectives. Why was it bad?
First, it blocked additional expertise. I could offer new “features”, more convenient tools, optimal architecture, but I did not do this because I did not want to cross words with anyone once again. Therefore, the quality of my projects grew very slowly for a long time.
Secondly, because of the inability to defend my point of view, I often agreed with other people’s decisions, which I did not consider to be truly successful. I had to implement the project without much pleasure, and this had a bad effect on motivation.
Thirdly, the fear of discussion greatly slowed down my professional growth. I was afraid that if I ask professionals a piece of advice, they, even if it was a joke, would label me “joon” and laugh at me in the smoking room. Therefore, I had to go the slow evolutionary path of self-learning from my mistakes.
Reason for my phobia
Fear of criticism first appeared back in university, in subjects not related to programming. For some teachers, there were only two types of answers: correct and incorrect. Any one with the slightest inaccuracy in the wording was considered incorrect – then the teacher analyzed these inaccuracies in detail in front of everyone.
Those who answered incorrectly were often subject to harsh criticism. Moreover, sometimes they were criticized behind their backs and in a rather barbed way, so to become the object of such discussions was not my fondest wish.
Another reason for the phobia was poor face-to-face communication skills. I was happy to delve into the technical details of the project and was always ready to provide my arguments or reporting on the project in writing or in face-to-face communication, but development is a team job, and collective discussions are often required here. In order to attract attention to yourself and defend your opinion in this format, you need to speak a lot and speak confidently, and I was not ready for this for a long time.
One incident put an end to this. Before the start of one sprint, I knew for sure that the architecture that I want to propose would be easier to maintain and debug than the one that the customer proposed. I expressed my vision, but I was overwhelmed with arguments on the topic “we have thought of everything, everything is fine with us.” As a result, the architecture proposed by the client quickly turned the product into an unsupported “quid”.
After that, I realized that if I did not defend my point of view on the tasks that I would later implement, then I would get bogged down in contradictory and unsuccessful decisions. Therefore, I started to practice a little bit in working discussions and noticed positive changes pretty quickly:
- I no longer focused on criticism and primarily collected constructive comments and helpful advice. With this approach, criticism was quickly forgotten with good decisions remained. This allowed us to improve the quality of projects and feel more confident.
- I was motivated to go deeper into the technologies I was working with at that time. Structuring existing knowledge created a basis for learning new technologies, languages and frameworks. As a result, in the first six months after the transition to a new behavior model, I managed to leave and breathe in three new languages and a bunch of new frameworks and tools.
What can help in the fight against the fear of communication?
Tip #1 – Discuss first using text
Verbal arguments are truly such a complicated process. Arguments that look so harmonious in the head, when translated into speech often begin to seem complex and confusing, and therefore unconvincing. Interlocutors may not agree with you just because they do not understand half of what is proposed. The text format will help to avoid this: describe your proposal in detail and let your opponent read it before calling. Verbal conversation after that will be much easier, and maybe not even needed.
Tip #2 – Discuss with one person
If you find it difficult to communicate with several opponents at once, train with one interlocutor. The fewer participants, the more productive the conversation. Take an open and benevolent position – then the opponent will unconsciously do the same.
Tip #3 – Keep your sanity
When you first learn to express your opinion at work, there is always a risk of going over the top and starting to impose your position regardless of the circumstances. You always need to understand who you are going to enter into a discussion with: if your opponent is much more experienced, most likely he has already encountered a similar problem, and it is better to listen. It is also worth remembering that the style of communication affects your reputation in the team. They try to bypass those who like to argue and prove to everyone that they are right.
Tip #4 – Train it outside the work environment
Team games help to overcome fear of collective discussions – no matter if they are sports or intellectual, offline or online.
When I joined my current job place, which at that time had a little less than a hundred developers, my communication skills began to develop faster. In a large company, it is more likely to find people with similar interests, and I joined a group of fans to play FIFA in the evenings. In addition to playing the console itself, we often discussed the teams’ squads, and during the matches we had to adapt to the style of the opponent and decide which of our team members to pass the joystick to. Since this is not a job, it was easier for me to speak my mind, and as the game progressed, this skill grew faster.
Later, I met a team during an intellectual game that was in the format of the quiz. It is designed in such a way that it is beneficial for the team to collect as many answers as possible, including the strangest and most unexpected ones, because the more opinions, the higher the chances of winning. It is always very disappointing if, after announcing the correct answer, you find that you knew it, but were too shy to suggest it. There is a direct parallel here with working calls, meetups and retrospectives: if you are afraid to speak up, you will harm yourself and the project.
Coping with the fear of phone calls and learning to stand up for your opinion turned out to be much easier than I imagined. Of course, the initial period was difficult: the palms were sweaty, the voice was trembling, but it quickly became clear that collective discussions are not so scary, but very useful.
The most important thing is not to be ashamed of your ignorance. If you don’t know something, say so! Ask for time to dig in the incomprehensible stack and figure it out. This will show that you are responsible and inform colleagues or the higher superiors in advance that the task will take more time. And the willingness to accept advice and other people’s opinions is one of the signs of professional maturity because the more opinions, the higher the likelihood of taking into account all the nuances and not bugger up during development.