The simple act that changes the future of your team
On my previous article, I talked about how bad clever code is and how to avoid it. And at the end, I said I would write about “talking people into not writing clever code” in my next article.
Keeping my promise, I started writing an article about how to convince people to think or do something – persuasion techniques. But then I realised that in most situations, if there’s a need to resort to persuasion, it’s because some problem already happened, caused by some previous mistake of ours.
So in this article I will write about this mistake and how to avoid it – and I’ll keep my promise of dealing with the clever code issue.
It’s Friday and you’re excited for the upcoming weekend. This week the team delivered some new features and paid some tech debt that was bothering you for a while. It was an awesome week work wise and you and the team are proud of the job well done.
It’s after lunch, you’re relaxed, your job is done for the week and you’re just chilling and waiting for the time to take off to the weekend, when your colleague comes to you and show some code he just wrote. You look at it and make one of those faces… you can’t make any sense of it. It’s freaking clever code!
At some point in the past, the time continuum has been disrupted, creating a new temporal event sequence resulting in this alternative reality. And now you’re at the critical moment when you’re going to find out in which timeline you’re in!
Alternative reality #1:
You explain to your colleague that that is clever code and you remind him about how the team should not write that kind of code. He understands, agrees, and refactors the code into a beautiful clean piece of software. Problem solved. Moving on with the weekend!
Alternative reality #2:
You explain what clever code is but your colleague has trouble understanding. At some point he understands but he strongly disagrees with you and says that code should be clever and that the people that will read it later have to deal with it. He says that if you know an advanced language feature you have the obligation to use it and so on and on..
You get angry because a team member did something you consider harmful and goes totally against your way of thinking and writing software.
Your colleague gets angry because he spent a lot of time working on that code and when he showed it to you he was treated like he committed a crime against humanity.
At this point, you both are emotionally involved in the conflict, you spent a long time arguing and nobody changed their mind. You both get out of it tired, hurt.
The perfect day just turned into shit.
The conflict
All because of a conflict that could have been avoided.
You believe code should be readable; your colleague believes it should be succinct.
You believe code should be easily changeable, even if performance takes a hit; your colleague believes that performance trumps everything else.
You believe code should be written with other people in mind; your colleague believes code should be written with the computer in mind.
You believe programmers have certain responsibilities; your colleague believes not.
You believe X; your colleague believes Y.
The conflict exists because there’s no agreement on values and expectations.
The mistake
We human beings have the habit of thinking we’re always right, that everyone else should think like us and if they don’t, they’re stupid or insane.
We forget that people have different information, different experiences and that because of that, have different opinions and ideas – which makes conflict inevitable.
The mistake is forgetting that those differences exist – it’s underestimating the conflict.
The solution
If the problem is that there are conflicts and we usually never acknowledge or ignore them, the solution couldn’t be anything else than: talk and agree on values and expectations.
The team can and should talk and agree on stuff such as:
- Coding standards
- How the team communicates
- How the team makes decisions
- Roles and expectations for each role
- Work hours
- Meeting schedule
- Anything else the team finds relevant
The goal is getting together and coming up with team rules. And those rules will be based on values that will have to be shared by everyone. It’s important that the result of this conversation is recorded and made visible to everyone.
This agreement is fundamental for us to be able to hold each other accountable. It also provides the team an identity and helps us remember our values: “this is the way we work because we value this and that”.
This agreement alone will avoid a lot of trouble working as a team.
At this moment you’re probably thinking: What a shit article! This is the most obvious thing in the world! If there’s a disagreement, talk and agree – duh!
And I’d say: that’s right! It’s pretty obvious, but you’d be surprised by how many times people forget to do the most basic things.
If you want to know about other team stuff that can change your future, drop your email below and don’t miss my next post!