I like reading other software blogs as much as writing my own. My big advantage so far, is that I don’t tell people how to write code (yet). Why is this an advantage? Because, so far, I’ve managed to avoid the wrath of the Perfect Programmer.
Who is the Perfect Programmer? He’s (or she’s) the one who responds to the blog posts with things like: Don’t let Jeff Atwood Lead Your Web Project or corrects silly bits of code on code postings, where the correctness of the code example doesn’t matter because it’s only for illustrative purposes.
Fortunately, in my career, I’ve only run into a few perfect programmers, who have commented on my code without tact. My code is far from perfect (even perfect programmers write crappy code), but most people who have commented on it have at least done so constructively. This brings us to my real point for this post.
Criticism is a dish best served warm (as opposed to revenge, which we all know should be served cold – it must taste like gazpacho). I’ve found it best to approach someone in a more questioning manner, asking someone to explain what they were trying to do first. After all, is it possible that you misunderstood the intent of the code or the design?
In a previous life, I worked with a guy who was a good coder, but could be a bit on the testy side. He had added a new feature to the API that was very useful, but would be difficult for users to interact with. A couple of people told him so and he became very frustrated with the criticism and insisted that it was perfect as is. I was asked to talk to him, so I went over to his desk and asked him to show me the new functionality. He told me about it and showed me the code that a user would have to write. There was one piece of information the user would have to supply that wasn’t obvious to me, and therefore users as well. I simply asked him to tell me about what the user would have to do to get this piece of information. Once he started to explain it, he stopped in mid-sentence. He said, “I can see how I can make this whole thing much simpler,” and he did. He changed the code and it was very clear and much simpler than the original. I had gotten him to criticize his own code.
Along the same lines, this is one reason why I always write comments and documentation on my classes. I find that once I start trying to explain what the code is supposed to do that I find out how convoluted I may have made it. Try thinking like a user when you design something. Try thinking like your colleague when you have an issue with their code. You’ll find that people will learn to trust you and accept suggestions more readily without getting defensive.