Dealing with code written by ‘The Others’
Start respecting your peers
Like many developers, I often come across code written by other people that makes me either grin or cry. Usually, my first reaction is to tell myself something like ‘Who the hell has written such poor code?’
This is a big mistake, because finding a culprit is not the point, it won’t improve or change anything, and in worst cases, one of your colleagues might be blamed, or feel humiliated. A way better question would be:
What were the reasons that led the developer to write it this way?
Maybe the guy (or the girl) was under high pressure by management to finish, maybe it was their first day, maybe someone else refactored the code which made it look terrible, maybe the specs were unclear. Maybe it was me. Wait, what? Me?
Embarrassing myself
I remember a day where I had to read some piece of code I had written a few years before. There were some basic mistakes in the code that sounded horribly wrong and I immediately felt ashamed to be the author of those lines.
Was I such a low-skilled developer 3 or 4 years ago? For sure, I gained experience in the meanwhile but that’s not all. At that time, there were few development guidelines, the system architecture was quite new, the whole team was being rebuilt, and it was like a first prototype. The code had also been reviewed and merged by the architect. Last but not least, it had been working finely on production until now. So in the end, although the code could be improved (and it is always the case, even for you who think you are the best coder in the world), it was not that bad.
Legacy code
The previous paragraph leads to a more general consideration: your code will eventually be legacy code for someone. Never forget that. There will always be a guy like you who will read your code and make fun of it (or silently make a facepalm, more likely).
I use to follow Graham Lea on twitter, and I really enjoyed his recent retweet (original tweet by Woody Zuill) about legacy code, and which inspired me this short post:
Wrap-up
In conclusion, here are three lessons I have learned and tried to keep in mind:
- Even in software development, even when working with ‘geeks’, respect is key, in all cases, every day. Think about it when doing a code review. It helps a lot.
- If the code I am reading (and that I am considering as poor) had not been written, I might not have this job. The company may still be alive today thanks to this piece of code.
- As a lead developer (or architect, senior, manager, …), start by asking yourself what was not understood by the developer, and what you could have done to avoid this situation.
Now, this poor code is also your responsibility, not only the others.
Dealing with code written by ‘The Others’ was originally published in codeburst on Medium, where people are continuing the conversation by highlighting and responding to this story.
