3 quick rules for talking to a web developer

These are just some thoughts following my being on the other side of the meeting for once in a long while. I saw how the web developer we were speaking with had an impact on the rest of our team, so I'd like to provide some pointers for dealing with those times where the person you're talking to knows more about the problem space than you do.

• Do not get intimidated by jargon

  • If your developer starts using words like "XHTML, CSS, Doctype, W3c Validation, PHP, MySQL, CMS, Ruby on Rails, Apache" or generally anything you don't understand, make sure you ask what it is.

    If the developer is firing the terms faster than you can keep up with, a common mistake, it's his fault: not yours. He's probably trying to impress you more than he's trying to help you.

  • Most of those terms you don't need to think about. Whether your use a Transitional or Strict Doctype has no impact on you, the client. The developer should make such decisions on his own. That's why you hired him.

    This is a job interview tactic: using as much jargon as possible to prove he's been around code a while. It's nothing a client needs... as I mention in the next rule: you're going to assume your developer is all powerful, anyway, so don't let the developer waste your time with term-dropping, as it won't change what you ask of him.

• Keep focused on functionality: your developer is all-powerful.

  • It's your job to figure out what needs to be made. It's the developers job to figure out how it's going to happen. Assume your developer can do anything, then let him push back and say no, just don't be offended when he does so. Push till you find the limit of your developer, then you know you're getting the most out of your investment.

• Think about the future.

  • A site is no good if it needs just as much work to maintain as it does to build the first time. Ask specifically how you will make updates to the site, learn what a CMS is, and find out which one your developer intends to use, if any.

  • Find out if you'll get a tutorial on how to use the CMS if it's not immediately apparent (for instance, if you've used that particular CMS in the past).

Overall, ask tons of questions. Most developers love talking about what it is they do, so they'll be happy to tell you precisely what the difference between the OSI and TCP models are, which by the way, if he finds the need to tell you this without you asking, you should probably fire him.

Happy meetings.