If your client has the wrong idea about what they want, what you're delivering, or what is possible, then you're failing to do your job. There, I've said it. Their job isn't to know the technology; that's why they hired you. If they do know a bit, then it generally helps, and I'm a firm believer that if a client commissions work then they should try to understand it (at least on some level). The point is, though, that they have other things to do that don't involve knowing every line of code, the limitations of various browsers, or how much data you can (and should) push through a pipe.

Now I'm sure that I'll be called out here by people claiming that there are plenty of belligerent, combative, wilfully ignorant clients out there. I've encountered a few myself who simply refused to believe a word that I told them. I'll tell you something, though. They are very few, and very far between. The majority of clients just require gentle handling and a little education about their systems. They don't want to be in the dark, and they don't want to fight you to get things done, but they don't know how to relate to what you do.

When I started working for actual clients, I would listen to what they asked for, and build it, no matter how illogical it seemed. If I couldn't figure out why they would want something done in a particular way, I would either rant at my co-workers about unrealistic expectations, or build it in my own way and just tell them I did it theirs.

I would have been a shit to work with then. For anyone who had the misfortune to work with me when I was finding my feet; I'm really, really, sorry.

One of the most important parts of my job is communication. I'm still not great with it (I have a habit of being silent when working on things until I need more information, or until I'm done). Almost every dispute in my career could have been resolved if I had just talked to the client, and asked what they wanted.

Once again, I'm sure I'll receive the virtual scoffs of many other programmers. "Clients don't know what they want when you ask! That's the problem! All they can do is tell you that what you did is wrong!"

This is where being a professional comes into play. The client might not know what they want, but they don't know what you think they want, either. If you don't tell them what you're building, then they won't know until you've built it. By then, it's too late - you've already wasted their time and yours building something that they don't want. You should be communicating with your client during the design phase, through the build phase, through the testing, and through the hand-over. They are giving you their money in the hope that you will build what they want, and if you don't bother to find out what they actually want, then they won't want to give you any more money. If your client doesn't want to pay you any more, then you're not going to flourish for long.

Communication with the client should be early and plentiful - you don't have to pester them with every single detail, but you have to be clear on features that they've mentioned, features that you've offered, and any problems that may derail the project.

If the client has asked for something to be done in one way, and it doesn't make sense to you, ask them why. Don't just ask them why either, but offer them alternatives. If another way would work just as well, then they'd be happy to know about it - especially if it saves them time and money in the future. If there's some really obscure domain-specific knowledge built into the business logic, which contains an edge-case that only their business will ever encounter, then you need to know this before you ignore their spec. You might still be able to come up with a better solution, but you won't know what is important until you ask them.

If something is impractical or impossible, then you have to tell your client. Maybe you can come up with a more practical solution, or maybe it's impractical because that's how the business (or even some government regulation) says it has to run.

Part of your job is to educate your client about how their system works. The first step to doing this is often to educate them as to why they should care. This isn't always easy, but it's worth it. Once your client starts to understand, even in broad terms, what the system does, then they will be less likely to get upset about what it doesn't do. If you don't tell them what you're building, then it doesn't matter how good your system is - it's not the system that thought they were getting.

Finally, you have to remember that while the code is your business, your clients' businesses will be something else entirely. Some battles you have to lose (or not even fight) because as important as a feature or an idea may be to you, there's nothing but financial loss in it for the client. Be mindful that their business is what keeps your business running. If you're going to spend 10 or 20 hours working on a feature that will never get used, ask your client about it first.

Just remember this the next time that you're working on a bloated feature that you think won't work: The client is never wrong; You've just failed to communicate.