Beyond Blame

In 2013 I joined Monitise. It was my first job in London. It was also the first time working on a codebase with dozens of engineers touching it. I was looking at PRs from people I had no idea who they were. I was also witnessing some of the worst code I ever had seen. My gut reaction was: these people have no idea what they are doing. Fast forward 3 years and I am now managing a team of 8 engineers. The codebase is also in shambles. It was easy to follow the same train of thought and reach the same conclusion. Way too easy.

Problematic codebases are so because of many factors. Poor coding skills is just one among many. At Babylon, the codebase was in disarray because the teams were doing everything they could to get the product out there. And guess what, they did. Customers were happy with the app and Babylon got to Series A. Now that we had a new lifeline, we could spend time thinking long term and fix the problems we had created.

It’s comfortable to believe that complex situations have simple explanations and solutions. A codebase that is bad? It’s obvious: the engineers are bad. Blaming comes cheap. But reality is more nuanced and such conclusions need to be tempered. Perhaps there was no one to shield the team from aggressive stakeholders. Or perhaps the team decided that speed trumped quality. Maybe some elements were out of their depth and it was the first time doing that kind of work. Maybe there was no one to mentor them. Or they had to release something as soon as possible to meet a deadline. Maybe some elements were burned out and couldn’t deliver their best work. In your mind there should be only one thing: what can I do to improve the situation.

Everything else is noise.