Title: Coders Causing Conflict

Author: Martin Moene

Date: 10 March 2015 20:53:31 +00:00 or Tue, 10 March 2015 20:53:31 +00:00

Summary: Pete Goodliffe lights the blue touch paper and retires to a safe distance.

Body: 

Words kill, words give life;they’re either poison or fruit – you choose.
~ Proverbs 18:21 (MSG)

Unless you’re a recluse, you will not go through life without meeting conflict in some form or other. It’s a fact of human existence. No one is immune; conflict is inevitable.

For the programmer, conflict can be bad: non-productive and hurtful. Have you ever written some code and then feared jibes from your colleagues?

No fool would write code like that, are you stupid or something?

Sadly, statements like that are not unheard of in the workplace. But they are clearly not at all appropriate. No one should suffer aggressive criticism, be demeaned, or needlessly discouraged. That kind of conflict is dangerous – it can knock your confidence and ruin effective team work.

But (and pay attention now) conflict is not necessarily a Bad Thing.

There is a valid place for healthy discord in the construction of high quality software. ‘Conflict’ does not necessarily mean war. Conflict doesn’t have to be an out-and-out shouting match, a cat fight, a tirade of unhealthy criticism, or a form of passive-aggressive power struggle. It can simply be a disagreement that, once resolved, will lead to a better solution. We can use conflict for good.

Perhaps we can use different terms to avoid confusion, or make this sound less sensational. We’ll talk about ‘disagreement’ versus ‘conflict’. Whereas conflict is confrontational, aggressive, abrasive disharmony, ‘disagreement’ is just what it says: failure to meet consensus on a matter. Sometimes it can be a deep, strong disagreement. But it doesn’t have to be disrespectful, rude, or acrimonious.

It’s perfectly possible, even expected, to like and respect a person, but to not agree with a coding decision they’ve made.

We must learn to harness disagreement to craft better code, and to not take it as a judgement of (in)ability. Being challenged about your opinion, or about the quality of a design can lead to unexpected solutions. Other people’s thoughts and opinions can spark an idea that will lead to an ultimately better solution. Indeed, without conflict we might only make inspired boring, incorrect software. In this respect, conflict is natural, normal, even necessary.

We don’t have to turn all ‘disagreement’ into ‘conflict’. Indeed, the professional programmer actively seeks to avoid doing so.

In this article, we’ll look at how we can be good programmers, good team mates, and use conflict/disagreement for the benefit of the code, the developers, and the customer.

Reactions

What’s your natural reaction when someone disagrees with you?

Some programmers respond well: phlegmatically, with good grace, not taking offence. Other programmers take it incredibly personally, and the merest whiff of disagreement knocks their confidence.

I remember once being involved in a heated design discussion about a software system, in which a number of programmers were becoming increasingly animated about their opinions. It was a loud discussion, with much hand waving and some energetically expressed points. At no point was anyone being rude, or personally insulting. We were enjoying the design experience; we really cared about exploring to find the best result. However, there was one programmer who sat on the periphery, and couldn’t engage. Personal circumstances had led to him being more timid and reserved, and he didn’t feel able to contribute at the same level as his colleagues. He felt that the discussion was a fight; and feared the outcome. In our excitement we didn’t realise he felt intimidated by the discussion. We missed his input, and he felt unable to contribute.

This shows how different people view disagreement in different ways, and can react and engage differently.

People view and engage in disagreements in different ways. To work effectively in a team you must appreciate this, and be able to relate to team-mates appropriately.

These different reactions stem from a person’s temperament, culture, and their personal situation. It may even depend on how much sleep they had last night (parents of young, sleepless, children know what I mean). Of note: be careful about making generalisations around gender. I know some very timid, introverted male programmers who struggle with criticism and some female coders who can put their point across with force!

Reacting well

Disagreement is not undesirable or to be avoided. Handled in a constructive and appropriate way it is a very healthy thing indeed. It’s the way we choose to react that determines whether it's productive or dysfunctional. There are a few key things that help us react well.

Avoid being defensive

When someone disagrees with you, the natural human reaction is to become defensive and argue. But stop; try to avoid this as a first reaction, arguing further rarely helps resolve anything. Rather than assert your opinion, consider whether they do have a valid point. Perhaps you should revise your opinion, especially if it was a decision you made some time ago. Circumstances change over time, code never stands still, designs evolve, and the assumptions around which you made a decision may no longer be valid.

Beware of pride

It’s good to take pride in your work, to care about what you craft. But don’t be too proud of yourself, and fear a public dent in your public profile.

Pride can turn a simple disagreement into a full-on quarrel. Don’t let your fear of being shown to be wrong lead to acrimonious conflict. When you realise you’ve made a mistake be prepared to admit this, rather than continue to fight to save face.

And of course, when you are wrong, don’t be too proud to admit it. Gracefully.

Expect to be wrong

Remember that you will not always be right. Expect this.

Since there is almost always more than one way to solve a problem, a good discussion may throw up a new, better, alternative. The best software development is collaborative, drawing on the abilities of an entire team; harnessing the wisdom of their crowd.

Don’t make it personal

Jerry Weinberg, in his seminal book The Psychology of Computer Programming [1], speaks of egoless programming. This is a great illustration of an appropriate reaction when your work is criticised. Leave personal feelings at the door, don’t take offence, look at your work impartially.

Now it’s true that we can’t completely disconnect from this. Nor should we: taking as pride in what you craft leads to a better outcome. But don’t see everything as a personal attack.

Don’t avoid disagreement

One technique to avoid conflict is to actively avoid situations where it might arise. Don’t ask people’s advice. Don’t review code. Don’t have design meetings. Don’t engage in water-cooler design discussions.

That’s not a winning approach.

’Remember how Conway’s Law teaches us that a software’s design tends to follow the lines of communication in the team that built it. In order to construct cohesive, well-functioning software, we need a cohesive well-functioning team!

Otherwise form will follow dysfunction; if you avoid talking to people (say, in order to avoid confrontation) then your software will also have poorer internal communication.

Take responsibility for respect

Mature programmers take responsibility for fostering healthy communication in the team. To do this, we must learn to interact well, to handle conflict professionally, and to respect people.

If you respect the people you talk to, you will try to disagree without being disagreeable. A good lens to view this through is the Retrospective Prime Directive [2]:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

In any discussion, it is sensible to assume that the people you discuss with are working to the best of their knowledge and ability, and that they are working for the best software outcome, not to apportion blame or make you look silly.

The atmosphere of a team is not determined solely by the leader; it is defined by the members of that team. There are certain team values that make this work: everyone is valued; everyone is important; everyone has a right to be heard, and has as valid point to make.

How to disagree well

How we handle conflict determines whether it is productive or destructive. Handled well, disagreement will lead to novel solutions, to learning, and to better software. Handled badly, though, it can lead to bitterness and resentment. Badly handled conflict can even lead to violence. (Yes, it’s not stereotypical for programmers to resort to fisticuffs, but weirder things have happened.)

Learn to deal with conflict well. Meet criticism and disagreement with an open mind, not snappy reactions.

Dealing well with conflict is an important life skill. It’s something many of us have to learn; few people are naturally politically savvy. Whilst you should definitely not aim to manipulate people, knowing how to interpret people’s reactions and deal with them sympathetically and appropriately will definitely help you become a better programmer. This, too, is not stereotypically a strong point for introverted developers.

Listen

Remember that a conversation involves listening as well as talking. Make sure you actively listen to other people. It can be very tempting to presume you know what another person thinks, and to start arguing with this. But you may not yet accurately understand their opinion. Stop. Listen. Actively.

If nothing else, this is a form of giving them respect.

You don’t want to waste your time arguing with an opinion that no one has! So first listen. And try to understand their opinion. A classic technique is to repeat back their point of view, reinforcing their point in your mind, and forcing you to listen. Doing this also gives you more time to formulate a considered response.

Know when to stop

Sometimes you won’t reach an agreement. Know when conversation is no longer productive. Be able to end conversation gracefully without having reached a conclusion. Perhaps schedule another time to discuss the matter after you’ve had time to walk away and consider it for a little longer.

Don’t keep fanning the flames of a destructive conversation.

Sometimes you can start disagreeing with someone by mistake! You’re talking at cross purposes, when actually you have the same opinion. When you realise you’re ‘strongly agreeing’ stop the pointless prattle and move on!

Talk well

Whilst listening is crucial, it helps to be able to articulate your point well. How often have you been frustrated by an inability to explain a point well in the heat of discussion, when a multitude of erudite descriptions enter your mind after the conversation has finished?

Practice:

• saying things succinctly (why use 100 words when 10 will do?)
• not ‘talking over’ other people – let them finish
• explaining your idea from the other person’s perspective; they don’t have all of your tacit knowledge
• make sure they understand the point that you are making correctly (without patronising them!)
• watch the kind of words you use; words have power, you can’t take them back – there is no control-z for a conversation!

Understand your emotions

Dealing with emotions that arise during ‘heated’ discussions can be tricky. Anger, frustration, disappointment, insecurity, and pride can all begin to make you behave less rationally. Do you feel threatened or excited, empowered or emasculated? Do you tend to cave in when heated discussion picks up, or instead feel a rising need to validate yourself; to ‘win’ and become Top Dog?

Identify how you tend to react in these kinds of situation. This can help you adapt unhealthy and non-constructive behaviours, and plan out ways to improve your behaviour for the next time.

Reflect on this now.

Watch your body language

Having a passion for your opinion, and caring about the code means that you’re involved. This is a good thing. You get animated in discussions. You wave your hands, speak excitedly. You’re anxious to get your point across, to share the marvellous insight that you just had.

But don’t be overbearing.

Don’t reinforce a power struggle with your body language. Speak softly, don't raise your voice or call the other person stupid.

Avoid a closed or confrontational posture that conveys you do not respect or value the other person.

Seek another opinion

If you can’t reach a consensus, bring someone else in for a casting vote. This is a straightforward strategy to resolve a disagreement, if you all respect the third party.

But remember that sometimes adding more people can sometimes make it harder to reach a single point of agreement, as there are more voices to be heard!

What if you spot others arguing? Should you step in to help resolve conflict? Should you offer to be the third party? It may not be your battle to get involved with. But it may be worth helping resolve. Again, treat others with respect. Perhaps you should first ask if you can help in any way.

The resolution

You don’t have to agree with everyone all of the time. And you don’t have to hide from conflict; it can be a healthy part of collaborative software development. Disagreeing openly can foster conversations that lead to better software.

• However, it’s important to always treat people with respect. Healthy communication builds a team, it is never unnecessarily rude, personal, demeaning or political. Be aware that healthy disagreement can turn into bitter conflict.

Questions

1. What do you recall as the greatest moment of conflict you’ve encountered in your programming career? How did you resolve it? What were the results of that conflict (both on the software, and the team)?
2. Do you think you are currently the cause of more disagreement or resolution in your project?
3. Does conflict tend to arise more between closely working people in the same team (e.g. developers-with-developers, or developers-with-close-knit-testers), or between departments (e.g. developers-with-management)? Why?
4. What do you think are the most important skills needed to resolve conflicts effectively?
5. How do these skills fit into your daily coding regimen?
6. What measures (if any) can a team/company adopt to prevent conflict, or to help resolve conflict in a healthy way? What have you seen that actually works?
7. Do cultural differences play any part in the shape of healthy working relationships, and the way you work with team members? Why?

Reference

[1] Gerald Weinberg (1971) The Psychology of Computer Programming

[2] http://www.retrospectives.com/pages/retroPrimeDirective.html

Notes: 

More fields may be available via dynamicdata ..