A common question in developer job interviews is to ask about code that the interviewee is proud of. The assumption here, of course, is that the code you’re most proud of is good code, but is it?
The code I’m most proud of was a full re-write of a PHP (i.e. LAMP stack) application for attendance marking. The original app was a collection of standalone PHP files with PHP, HTML, and SQL all mixed with minimal structure.
I was given free rein to change it as I saw fit, none of the stakeholders was technically savvy enough to know what was required anyway.
At this stage, I had been working as a developer for about 4 years, but not as a web developer. I knew enough to know that the way it had been written was terrible, but had to discover what the “right” way was.
I made a lot of mistakes and would change almost everything if I was starting again: I didn’t use an ORM just raw SQL. I used a micro framework rather than something more full-featured like Laravel. There is a lack of testing because I didn’t find an adequate testing library for PHP until quite late in the project. The routes are not RESTful. The controllers are fat, the models are skinny.
Sounds terrible right? I wouldn’t want to show this codebase to someone who would use it to judge my competency as a programmer.
So why am I proud of it? Firstly, despite all its weaknesses, it mostly just runs without problems. Multiple months pass without me needing to touch the code at all.
Secondly, when I do get a request to change something I can usually find the place in the code and understand the existing behaviour quite quickly, even after not touching the codebase for 6 months or more at a stretch.
At its core, this is what makes good code good. If the code works as intended and is easy to change then it is good code, even if you want to change everything about it.