Who the hell wrote this rubbish? They’re a bloody idiot! How could this ever have worked? Why did they do it like that? What’s the point of this bit of crap?
I’m guilty of harbouring the above feelings when reading/reviewing code. If you reframe those questions more positively, it can be beneficial:
- What is the aim of this code?
- This is an unusual pattern – what caused it?
- If this works, despite my believe that it should not, then am I missing something?
- Is this a case of problem solving, or misunderstanding?
The best programmers take little for granted, question everything, and push themselves forward on a quest to reduce their code to the lowest form of complexity and mess, to achieve the most amount of required functionality.
We could almost stop this article here, but there’s an extra point to make. Development is most often a team endeavour. Even if you’re working solo after someone else has given you a codebase, you’re still working on knowledge passing between people.
If you assume the worst in others while working with them or their code, you will ultimately fail.
I’ve periodically been guilty of this, harshly critiquing things from other people that didn’t read well to me. My usual go-to bad assumptions are that someone’s:
- Been ill-informed
- Not taken the time to review and complete their own work
- Has just pasted something in as a ritual, without understanding it
- Hasn’t put enough time in overall
If you’re in a team where these are your core assumptions, there’s a problem. It can be hard to spot, though, since the first of these – being ill-informed, can also be a genuine concern about your junior team members having training needs.
The chief lesson here is to consider the team culture. If it’s one where everyone assumes the worst in each other, then you’ll waste time on that.
If you assume everyone is doing their best and acting in good faith, you get a lot more achieved.
In one team I worked in, they had the catchphrase “respect what’s gone before”. A way of reminding everyone that previous decisions were made for the best reasons of the time using the best data and tools available.
As well as respecting the code, though, you also need to respect the people.