He writes: "Every problem has a certain amount of 'pain' or 'value' to the customer — and THIS is what sets the price point in the customer's mind. This is what determines your compensation (and 'perks'). Not some 'perceived value' you place on your own head."
I absolutely agree. Despite my whiny demands, I guess I'm still at or below the pain level for my clients — many of whom have been with me for years. I suppose I am spoiled because, thanks to all my great clients, I haven't had to actively look for new business in a long time.
But why is that the case when there are so many offshore developers willing to write software for pennies on the dollar compared to what I charge? The short answer is: because they can't do what I do — yet.
Speed doesn't equal quality
Permit me to grossly overgeneralize for a minute. My experience with many offshore developers is that they're usually quite bright, highly motivated, and can churn out a ton of code. However, I often see a tendency to emphasize "get it done" to the detriment of "get it done right." A thousand wheels get reinvented rather than constructing a wheel factory. The result is usually something that works as advertised, but it doesn't see to the bottom of the problem, and so it quickly becomes a hard to maintain mess.
I think this approach springs from an urgency for offshore developers to prove themselves by producing a large body of tangible results. Back when I was a green-horn programmer, I used to crank out hundreds or even thousands of lines of code in a day — but it wasn't particularly good code. Nowadays, I write much less code, but it's code that matters. It's often 10 lines of code that required hours of design. It's the $49,899.95 "X." And it's usually more important for what it teaches than for what it does.
Tips on becoming a code guru
Here's my advice to hungry contractors around the world: seek deep comprehension of your field. Learn to think deeply about each problem you encounter and resist the urge to "just code it." Remember that the first attempt should be a prototype, the second attempt highlights the limitations of your design, and it's usually not until the third version that you have something worth unleashing on your client. Read all you can about different design and programming methods. Even if you never use three fourths of the methods, they'll make you think more thoroughly about the methods you use. Do not just rapidly acquire every résumé bullet you can think of or simply collect an example of every algorithm you think you might need to copy/paste someday.
If even a modest percentage of offshore developers begin focusing more on becoming gurus instead of coding machines, someday I might have enough competition to drive down my rates. From what I've seen, though, I think I'll be able to retire before that happens.
Chip Camden has been programming since 1978, and he's still not done. An independent consultant since 1991, Chip specializes in software development tools, languages, and migration to new technology. Besides writing for TechRepublic's IT Consultant blog, he also contributes to [Geeks Are Sexy] Technology News and his two personal blogs, Chip's Quips and Chip's Tips for Developers.