This too will be deleted
I’m Rowan, a tech lead at Dunelm, writing stories about the intersection of Engineering, Automation and Psychology.
There’s a huge variety of metrics and principles by which you can evaluate if code is ‘good’ — speed, memory usage, readability, extensibility and codebase conformity.
When I started out as a kid, tinkering with simple tutorials, my main goal was just code that worked, I didn’t really know what best practices were or how to build a maintainable codebase I just frankenstiened whatever snippets I found online that looked about right. I’d like to think I’ve grown a bit as an engineer since then.
Once I started to actually study I fell in love with algorithms and optimisation, everything from procedural generation to genetic algorithms. Not to mention absolutely riveting stories of how programmers at Nintendo got every last byte that could possibly be squeezed out of the handhelds that ran the games of my childhood. I took that perspective with me when I started to tackle real, practical problems. In fact, one of the key tricks behind my victory in an image recognition competition as a late teenager was by cutting down the images in the training data into much smaller sizes and feeding them en masse to the machine learning algorithm!
I squeezed data into barely a few bytes and wrote fast sorting algorithms, pulled clever (at the time) tricks out of my sleeves to get our software running just that little bit faster and smoother. Was any of it good code? It worked, certainly and it was fast. I can only imagine the headaches I caused for the engineers who came after me and tried to make it do anything except what it did though.
As I matured as an engineer I started to think about reusability, moving to a coding style that was more focused around how the process of writing software could be faster. I threw myself behind designing and developing the games engine our company used, standardising our common use cases and problems and we frankly halved the time it took to develop and ship games. I spoke to engineers and QA to find out what about their job was laborious and ripe for automation — a clever bit of software that took screenshots in 26 languages (and a special 27th language that I’ll write another article about some time) cut the localisation QA process from over a week down to a few days.
Was this finally good code? It was used day in and day out, it was flexible and it solved real and tangible problems. However when the day came that we needed to swap out some core parts of our engine, an office full of engineers had to wait weeks for me to figure out how it could be done because I had created a massive single point of failure that understood how it all worked — me.
I’ve started to settle into a new philosophy for the code I write as I reach the Tech Lead stage of my career, code that’s for more than just me. I’ll write fast code, but I’m not thinking at the function level. I’ll write practical and reusable code, but I’m not thinking at the codebase level. I’m writing code that one day, another engineer will come along and want to change or totally scrap what I did at the time. I’m writing code to be deleted.
So what does this look like?
It means my architecture includes anti-corruption layers where appropriate, so domains and systems don’t become enmeshed and we can peacefully retire software and functionality we don’t need anymore. It means I’m thinking about the domain my code sits in, so I don’t muddy the purpose of existing software and make it hard to untangle later down the line.
When I’m writing code I’m thinking about similar things, but at a lower level — strategy patterns and dependency injection. My functions and components tend to be very single-purpose and explicit, which makes it really really easy to just delete functionality that’s no longer needed and reuse blocks of code. I put more comments alongside my code than most, which makes it as clear as possible where to start digging when you need to begin renovations.
It affects how I approach code reviews too, I try to keep my feedback focused on avoiding magic numbers and types rather than loop optimisation. I’m going to ask the annoying questions in reviews and meetings like “have we documented this?” when all I want to do is go back to my roots and just start hacking some code together.
I’m sure my perspective will change again as my career continues, but for now I’m writing code for the engineers that come after me. They’ll need to meet changing business needs while moving quickly and I want to make it easy for them.
Because one day, this too will be deleted.
Like my writing? Check out Hacker Highlight: David Creeks and A boatload of red flags in testing!
