If you've ever contracted a programmer, whether it be through a company or a freelancer, you've likely encountered some rather frustrating responses to your requests. Programmers aren't always right, but for the most part, the ones I know are honest and have the goals of the client in mind. In general, you don't want to upset him -- it's simply not in your best interest.

Here are five of the top ways to piss off your programmer.

5. Be long-winded and wordy. Long, over-explicit explanations about something needed on the site usually does more harm than good. Programmers don't need too much information. They need short, concise, descriptive explanations, not novels. Use bullets and make sure you're not talking about something the programmer either hasn't heard before or couldn't know about because it's using internal company jargon. More is not better. I once received a seven paragraph explanation that was basically saying, make the links on the site red.

4. Badger him. If you ask every other day what's with the site, what's new, what's taking so long, you'll likely piss off your programmer. You can ask for weekly updates if they aren't supplied on their own. Don't be impatient, it usually doesn't help. Unless you have something stated in the agreement that keeps the work open-ended (a bad idea), there should already be a timeline for the site and it will likely be adhered to barring any unexpected changes. I had a client who called me every morning as soon as he saw I was online for a month, until I basically created a mini-blog for him with daily updates on the project management site. It's your right to know what's happening but give some space.

3. Be slow to respond. This is the opposite of the previous way to piss off your programmer. When you get a question, answer it to the best of your knowledge, promptly. These questions could sometimes be the difference between finishing a project on time or not. Also, if you promised to supply material -- content, images, configurations -- make sure they get to the programmers on time. I had a project delayed for three weeks because the client never sent me the final design.

2. Withhold payment. You may think that this would be the number one way to piss off your programmer. Yes, it's bad and can really frustrate the people who depend on that payment, but there's worse. Maybe I think that because it hasn't happened to me, but I know programmers who have experienced it. Withholding payment is a poor punishment, is rarely effective, will likely keep the job from being completed, could land you in court and should only be used as a last resort. If there is something going on and the programmers are not holding their end of the bargain, talk it out. Always return to the agreement you made to make sure that something has blatantly been breached before taking a step like that. And make sure it's not just a matter of interpretation. Payments are their livelihood and keep in mind that both you and the programmer want to complete the project.

1. Make late additions. "It's just a minor change," you say. "It'll take just a minute." That's what you think. Programmers follow a program. Most, like architects, build according to a blueprint -- a site program or characterization, which is different than a list of requests. Most price quotes are based on this program. Problems arise when you try to change or add things in mid-stream. Some late additions are really simple and most programmers will implement them without making a big deal about it. But others can be very time-consuming. Let the programmer decide and try as much as possible to stick to the plan. I actually can't remember a project where this didn't happen at least once. But if a well-written agreement and plan are handy, 99.9% of the issues are resolved quickly. Not sticking to the plan will really piss off your programmer.

I've written before in Pitfalls in Communication with Developers about the need for a good site development plan. Many of the items can be avoided if you together write a good plan and follow it to the end. A well-built website will always have the ability to make additions after the project is complete.