Your attitude is the defining aspect of your professionalism. How you approach relations with your colleagues is a significant part of that professionalism. As the old maxim goes, do unto others…

This will be a familiar scenario for anyone who’s coded on a project with other developers:

You have a task to fix a defect or implement some new feature and start by opening a file.  Inside, you find a can of worms. The deeper you look, the worse it seems to get. The design is awful, the coding conventions have all been ignored or the work has been left incomplete. In disgust you curse the name of the person who wrote it and wonder what on earth was going through their heads when they created this mess….which now falls to you to clean up.  Who can blame you if you are left feeling angry?!

However, before you organise the witch hunt, fire off the flame-dripping email, or quietly plot the culprit’s demise, consider the following…

• Do you know what constraints they were working under? Was this something written with a manager breathing down the author’s neck because the feature had to be finished in 10 seconds otherwise everyone would be fired? Is the design compromised because the author was forced to use an API that has key flaws that aren’t immediately obvious? Perhaps the author was asked to code using a language or technique with which they were unfamiliar? Read the documentation and file check-in history to understand the decisions that went into the implemention. Until you are aware of the context in which the work was done, you should hold off on your criticism.
• Is the perpetrator a newbie?  If you have some of your first code backed up, go back and see what you make of it with your experienced, professional eye.  Is it perfect?  I thought not!  :)  Would you criticise the efforts of a beginner or would you offer to help and improve their work?  After all, we must all have to start somewhere and humane, helpful advice from an experienced pro can make a lot of difference.
• Everyone has an off day – we’re all human! Even the best of us can look at what we did yesterday and see glaring holes in our thinking.  One of my favourite quotes is by Maurice Wilkes from 1949 when he found his first bug: “As soon as we started programming, we found to our surprise that it wasn’t as easy to get programs right as we had thought.  Debugging had to be discovered.  I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs.”
• Has some subsequent change invalidated the original design? Is your ire directed at the right person? Has someone made a change that has subtly (or not so subtly) altered the original code structure.  Sometimes it’s hard to predict the outcome of changes, especially when code is complex.  Unit tests help and functional testing should cover most scenarios but there are always gaps that bugs fall through.
• Are all the guidelines and policies obvious? Has the responsible individual had the time and resources to get an understanding of the project and the conventions that should be followed?  If your documentation has not been posted on the wiki, or the developers haven’t been given time to read it or the senior developers have not reviewed and commented on the code, then perhaps some of the blame lies elsewhere. With an objective eye, review your processes and try to improve the support structure for your project.

Your reaction now can determine the outcome. Clearly, there is a problem that needs to be resolved but rather than moan about the idiot who put you in this predicament, you can get something positive from it.

• Is this an opportunity to help someone? By patiently and carefully explaining the issue to the original author, you can help them learn from their mistakes. Be non-judgemental, cooperative and supportive. If the developer was unaware of policies, show them the documentation. If they missed a simple design principle or methodological process remind them of it. If they have broken some working code, explain the original problem the code was designed to fix and work with them to find a solution for their requirement.
• Is this another example in a litany of errors?  Sometimes, you just cannot escape the fact that some people aren’t the right fit for the role.  If you have someone who is lazy, uncooperative or just plain incompetent, you may need to do something a little more drastic. Automatic checkstyle on code commits, organised peer reviews and code quality workshops are all things you can introduce into a project that will help improve code quality.
• Before you escalate poor performance to your manager, consider if the individual has been given the right work. Have they been given continuously boring or unsuitable tasks? If so, perhaps they may excel if given a different set of challenges.
• Finally, are there other factors that are impacting their motivation, focus or cooperation? Can you help to mitigate or overcome problems they may be experiencing?

I don’t for a second claim myself to be a saint - I’ve moaned, groaned and griped with the best of them. However, I hope that as time has gone by, I’ve learnt (sometimes the hard way) that being constructive is always the best approach.  Don’t start an underground whispering campaign against an individual; this is demeaning and counterproductive.  Instead, work with the person to overcome their shortcomings and improve both your working lives.  After all, that’s the kind of patience and respect you would appreciate next time you mess up.