On Trust

At a recent retrospective, the team was asked to reflect on the Agile values: Trust, Focus, etc. I was interested to see that trust had come up. In particular, it made me think about the Code Review process and how we, as developers, are often extremely quick to jump to conclusions about a technical decisions that to us seems ‘silly’, ‘stupid’, ‘idiotic’, ‘why would you do that’ and how this manifests itself in the comments we give to each other during code reviews.

For some reason, we rarely give the benefit of the doubt. We find code that is structured horribly, functions with local variable names that make it hard to follow what goes on and we think ‘who on earth could have written this’. This mentality is reinforced by the common trope of ‘write your code as though the next person working on it is a murderous psychopath’.

It’s important to think about the future programmers who will come and read, modify and perhaps delete your codebase. It’s equally important for these future programmers to understand that code is never written in a vacuum. There is usually a process around development, which may be function to help developers deliver or completely dysfunctional (process for process’ sake aka ticking boxes or in this case, Jira tickets). There are deadlines. Customer requirements and complaints. Support tickets. Urgent bugfixes and massive production fires.

So here’s where trust comes in. Instead of immediately branding the previous developer as a complete incompetent, who for some reason decided to leave in some code duplication, trust them. Trust them to have done the best job under the prevailing circumstances - whatever those may have been.

Another aspect of this same problem (not trusting our fellow devs to be giving their best effort) frequently comes up in code reviews. Someone sees something that “looks wrong” - for example, it doesn’t conform to the style guide on the dot or it has a bit too much code duplication and leaves a request for change in a code review instead of discussing the reasons and trade offs that were made in this choice. Sometimes, a piece of code that looks like it is poorly implemented is poorly implemented, because a dev is inexperienced in making applications like this, but other times, there may be hidden complexities that need to be accounted for.