After yesterday’s request for ‘constructive code vandalism’ confessions, Steve wrote in:
I used to take the opportunity to leave snarky comments in the code when fixing something that was obviously broken but had gone unnoticed for weeks, months or even years.
It was my way of letting off steam, and I became renowned for it in my dev team.
On the plus side, I’d usually explain exactly why the previous approach was incorrect and why I changed it :D
I did moderate myself when I felt it was appropriate, and I didn’t deliberately single anyone out. My earlier code was often as bad or worse than what I was fixing, so I took the opportunity to point out why earlier me was an idiot too.
As you read this, it’s not immediately clear whether Steve was ‘renowned’ in a good way or a bad way for his snark. But it becomes clear that his feedback was constructive rather than personal.
Of course it’s really useful to have longer explanations of why things have been changed, though I now prefer long commit messages over long inline comments.
Even commit messages along the lines of “Look, it’s been a long day, and I couldn’t get this to work any other way.” or, more often “FUUUUUUU I HAte browsers.” can be useful.
When you come across these as part of a
git history or
git blame investigation they can help to show some of the context of what was going on when the work was done. As a result you may feel better that changing it won’t hurt anyone’s feelings.
These situations also present an opportunity for discussion before the work is done. By all means leave an extended comment that explains the rationale behind the change. But even better, write the comment before doing the work and have a conversation with colleagues, particularly if they were responsible for the original work.
All the best,