Understanding The Implications Of The Code You Write

05 March 2019

Photo: Unsplash

There is something I have noticed in developers recently. They do not always appreciate the implications of the code they write.

This may be the grumpy old git in me but I would actually suggest that the internet has made us lazy. Combine this with the typical pressure of delivering quickly and you have a lot of room for mistakes. Coding, after all, is a human, creative, process.

Sites like StackOverflow can be a source of solution and inspiration. But before they existed developers learnt from books. If you were taught how to achieve something it was by someone else who’d read the book. The books covered only very high-level topics. You couldn’t ctrl-c and ctrl-p from a site and have something working. You’d have to experiment and develop problem solutions yourself. There have been way too many occasions where I have looked at a problem with an odd solution. When I have then Googled the problem I’ve found the top answer is the code I am reviewing. Package managers have made this slightly worse. People grab packages that do what they think solve’s their need and then just work a solution using them.

Over the last couple of years, I have seen a few examples of code where the solution clearly didn’t fit the problem. My favourite was when I tasked one of my developers to add page caching to an application. We had been left with a part implemented solution which didn’t work. Instead of overhauling the code they turned off caching on the site totally. Their argument was that it fixed the problem. They didn’t appreciate the performance issue. I had another who decided to update the mechanism for sending alert emails from automated tasks. They decided that the class used to get the Database name from the config string wasn’t needed. Instead, they just added the string to the subject line of the emails. I received an email with the address and credentials for a test database in my inbox. When I asked why they had done this I was told: “it didn’t do that on my machine locally”. A recent example of this I have seen is when a fairly senior member of the team pasted the same Ninject mapping into multiple projects. These projects shared a common project which had a Ninject factory. The various projects only needed to implement mappings local to them. I had to make a change to the mapping and the 20 projects had to be updated.

Obviously, we are all human. We all have intense time pressures on us. We could blame laziness or someone else who wrote a package or library. The one thing we need to remember is that the code we write we are responsible for. Whether you are writing a piece of homework or software for industry there are consequences to your code. Your marks will suffer or a machine will fail to operate. While there are processes and testing teams to save you there is a cost to having to rework code. Estimates are shot, the cost of delivery goes up. This is something most developers do not consider. Nor is their professional reputation. So next time you create that pull request, make sure you understand and can defend your code in all environments it will run. Once you can, hit submit.

If you have any thoughts around this issue then contact me via twitter or email.