Attention Developers: The Problem Isn’t Technical
Out Of Date Warning
Languages change. Perspectives are different. Ideas move on. This article was published on December 14, 2008 which is more than two years ago. It may be out of date. You should verify that technical information in this article is still current before relying upon it for your own purposes.
How many times have we heard it? Our bosses, colleagues, everyone, it seems, reminds us time and time again that we’re actually customer service professionals, as well as developers. Seems we’d get it, right?
The subject may have been flogged to death, but I’m going to bring it up one more time. Why? Two reasons: first, because we all need the reminder from time to time. And second, because I need the reminder on a daily basis.
It’s easy to believe as developers that the focus of our jobs ought to be on writing applications and reading through spec documents. It’s not. All of us are customer-focused, and customer facing. Even those of us who develop internal applications or who develop for client services teams (like I do), we have customers: the people who commission the things we build.
With that in mind, there are a few things that we (I) should remember when dealing with customers:
- Our customers are often less technical than we are. It’s nice when we have a customer who understands code or is hiring us because they’re overloaded and need some work done; but that’s rare. This brings me to the next point…
- Our customers trust us. They’ve placed an enormous amount of trust in the developer that they’ve selected. We need to show that we’ve earned that trust, and that we deserve it. A great developer should always exude confidence, show the client that they understand, ask intelligent questions, and demonstrate that they have a full, professional-level understanding of the issues at hand.
- Our customers want us to help them make decisions. There’s an old saying that the customer is always right. Not in development. Often times a customer doesn’t know what they want, so how can they be right about their choices? It seems developers have the hardest time with this: their client will say “we don’t know how we want this to work, can you show us some ideas?” The developer, who is much more comfortable demonstrating his solutions in code than in words, will fumble around and sometimes even make a bad recommendation. Don’t do this. Even if it means taking time and saying “let me get back to you,” a great developer will be able to give a client options, and then help the client pick the best one.
- Customers don’t understand what we do, or how we do it. A client will rarely say “I think this will take five hours” and be right. It’s not that the client has high expectations, or is stupid. They just don’t do what we do. We have to help them understand. When we say “well this will actually take 25 hours” we better be able to show them why. Here’s where the architecture goes, here’s database optimization, etc. We should never bloat our estimates to enrich ourselves; that’s not the point here. But we should always be sure that the client understands specifics, and that we show them why, not just tell them.
These tips are not just for the world, but for me too. I need to remember every day that I’m first and foremost a customer service professional. The client is my client, and I work for them.
Learning design patterns doesn't have to suck.
Design patterns open a whole new world of possibilities. So why are you avoiding them? This brand new book will help you finally understand these wonderful programming techiques!Learn design patterns TODAY »