There are a lot of soft skills a software developer needs to have a successful career, but if I were to pick my top three, it would be: Persuasion, Negotiation, and Assertiveness.
1. Persuasion
Persuasion is your primary soft skill for every technical discussion, most notably code reviews. When giving feedback on someone's code, unless you are very senior and they are very junior, there will be some disagreement as to if and how their code should be changed. These discussions can often become heated, especially under the pressure of an impending deadline when code standards are not well established - which is to say the conditions under which most code reviews take place. Rather than trying to force someone to change their code, focus on persuading them instead.
Persuasion is your ability to change another person's opinion. Most people think this is impossible - especially during a heated argument - so they don't even try. During a code review, when someone tells you that their code is perfect and doesn't need to be changed, rather than fight with them, try to see things from their perspective. Most sane software developers know there is no such thing as perfect code, so if they are maintaining that their code cannot be improved, there is usually a deeper reason why they are obstinate. Your first step is not to tell them that their code is terrible, but to get them to talk about why they like what they wrote. The process of getting someone to talk about why they hold a particular opinion and listening carefully to their reasoning is a critical first step to persuasion.
The process of getting someone to talk about why they hold a particular opinion and listening carefully to their reasoning is a critical first step to persuasion.
Once you have gained an understanding of why someone thinks their code is perfect, you can ask questions specifically related to the aspect of their code that could be improved. Though it might seem counter-intuitive when you review someone else's code, your most effective tool is to ask questions that help them conclude that their code should be changed. You demonstrate your skill as a software developer not by the number of items you identify for them to change, but by the nature of the questions you ask that persuade them to improve their code themselves.
For example, if you have a code review where someone has created a pull request with a single function that takes a dozen boolean arguments and is 1000 lines long with nested if-statements that are impossible for the average software developer to understand, instead of giving this feedback:
"Functions should not take this many arguments, and any arguments they do take should not be booleans or the caller won't know what the arguments do."
"This function is too long and needs to be decomposed into several smaller functions."
"These if-statements need to be extracted into equivalent functions whose names can be easily understood."
Note that this feedback is appropriate and what most people would consider justified, but it is in no way persuasive. Instead of reciting a laundry list of flaws that will most likely cause someone to become defensive, ask questions:
"Is there a way to help future developers better understand what arguments this function takes without having to study its implementation?"
"Is there a way for us to make this function shorter so that it's easier for future developers to maintain?"
"Is there any way we can simplify the logic of this function to make it easier for us to fix bugs if any are found?"
By asking these questions, you have started the process of persuading them to change their code. The more questions you ask, the more they will think about what they wrote, and the higher the probability that they will want suggestions on how to improve it. If you skip the process of persuasion and jump straight to giving edicts, they will most likely become defensive and start an argument that progresses into a fight if neither party gives ground - a situation where knowing how to negotiate comes in handy.
2. Negotiation
Negotiation is finding an acceptable middle ground between two parties in disagreement. Software developers will find they need to negotiate whenever faced with unreasonable deadlines. There is usually a group of product owners, project managers, and stakeholders that all believe that a timeframe is perfectly reasonable. As a software developer, you will likely be a part of the group that finds the mandated delivery schedule unreasonable. Typically, software developers will huddle together and form a unified front of resistance, which the managers will ignore. Instead of resisting, it is often far more effective to negotiate for a more reasonable date.
Software developers can often feel powerless and resentful when told they have to get work done by a date they know is impossible. They become angry, then depressed, then start looking for a new job. All of this is unnecessary once you accept that people who are not software developers have no information related to what is or is not reasonable because they don't know how to develop software. It is your responsibility to give them the information they need to make an informed decision. To get the opportunity to share information that you know, and that they do not, a process of negotiation needs to start even if you think the date is not up for negotiation.
There is never a time where a software developer is told, "You need to deliver by Friday, but I'm open to negotiation." The nature of a mandate is that there is no invitation to hold a discussion. Instead, the people in charge are ready for a fight and are willing to use their authority to get what they want. Being an effective negotiator requires that you assume that everything is up for negotiation, and show that you are never so emotionally invested that you care about the outcome. The more emotions are involved, the more likely people will fight. When you are aloof and seemingly uncaring, you can assume the role of a neutral 3rd party who only wants the best outcome for everyone.
Let's say that you are told you have one week to build a feature that you know will take a minimum of a month to complete. Rather than saying, "No way - that's ridiculous!" instead try something like, "One a week might be possible with fewer requirements and maybe a few more people." Responding in this way starts the negotiating process as it acknowledges what they want, and starts the process of finding an acceptable middle ground. As strange as it may seem, the more disengaged you are from the outcome, the more effective you will be at getting what you want.
As strange as it may seem, the more disengaged you are from the outcome, the more effective you will be at getting what you want.
Both persuasion and negotiation require passive forms of communication where you are helping the other party to change their opinion. However, there are many situations where being passive won't be sufficient to get your point across, as you have to be precise about your meaning. When these occasions arise, it is necessary to communicate assertively so that you are unambiguous and easy to understand.
3. Assertiveness
Software developers should be assertive in their answers whenever asked for their opinion. A professional software developer should either be sure or not sure about their opinion. If they are not sure, it is usually fine to say so, as even the most experienced people have doubts as to the right thing to do. If they are sure, they should state their opinion directly, honestly, and respectfully:
Being direct is getting straight to the point.
Being honest is speaking the truth as you currently understand it.
Being respectful is making every effort not to offend while still being direct and honest.
Assertive communication always runs the risk of offending someone, as people are often intimidated by confident people, and confident people speak assertively. Whenever you speak assertively, people will see you as being confident and sure of yourself, which inevitably some people will interpret as being arrogant and full of yourself. This phenomenon is why so few people speak assertively, and instead are either passive or aggressive. Aggressive communication is often confused with assertiveness, but the key difference is being aggressive is not respectful.
Consider a situation where you are asked to give your opinion on which programming language is better, and how you might respond:
Passive: "Well, both languages have their pros and cons, so I guess it's up to whatever the situation is."
Aggressive: "People would have to be stupid to still use Java as Kotlin is obviously the better language.
Assertive: "I am not sure as I have not made a detailed comparison," or "If given a choice, I would choose Kotlin."
Takeaways
When you master the soft skills of persuasion, negotiation, and communicating assertively, you will be able to tackle the most intimidating yet critical tasks you will face in the advancement of your career: convincing someone to pay you more money. If we were honest with ourselves, getting better compensation is the main driver for just about everything we do, from learning new technologies to seeking recognition for our accomplishments.
However, often being a great software developer is often not enough to earn more money. As the saying goes, "If a company could pay you less, they would." When the time comes to decide on your compensation, you will need to persuade someone you're worth the money, negotiate your compensation package, and be assertive if the offer is unacceptable. As a result, there may be a literal pay-off for mastering these skills in the near future.
...
Neil writes a lot more about the softer side of software development over at neilonsoftware.com. Check it out!
