We’ve all been there: code that hurts your brain to look at, let alone comprehend.
Not written by you, of course. You wouldn’t write a mess like that, and you can hardly believe that somebody else did (or maybe you can…?)
Your mind wanders to who to blame for this abomination before your eyes. You start complaining to the person sitting next to you. Then to your boss. Then you decide that it’s time for a coffee and then to browse for new jobs.
Sound familiar? I bet it does!
The difference between an average programmer and a good one is in what you do next.
Do you ignore it and try to forget you ever saw it, or do you attempt to improve it?
I have a simple rule that I like to follow: I always try to leave the code in a better state than I found it.
This might involve small improvements, like improving code formatting, renaming methods or variables, or adding useful comments. Tiny improvements add up over time, especially if the whole team is doing the same thing!
Or the improvement could be larger, like refactoring or adding test coverage.
Yes, this can take time, and yes you do have that deadline to consider. But it’s amazing how quickly small improvements can be done; certainly in much less time than it took to understand that grotesque code. Which means that your improvement might make it much quicker for the next person to understand – and that next person might be you, when you revisit it in a year’s time…
The important thing is to do it, and encourage your whole team to do it. Don’t be afraid to change things. Take responsibility for that code, even if you didn’t write it: embrace collective code ownership!