Last month’s post on this topic has proven very popular.
Recently, Web Worker Daily posted about ways to make money online, and one of the ways listed was to troll the freelance programming marketplaces.
Naturally I couldn’t resist commenting that I could not figure out how anyone can make honest money from those sites!
Warren Seen of Tasmania, Australia mentioned his excellent freelance programmer’s manifesto that I highly recommend you take a look at. I only wish he had called it the freelance software developer’s manifesto. It’s a positioning thing; “programmer” evokes the image of some kind of rote technician or assembly line worker; “software developer” is in my view a much more accurate way to describe what we do. We do not snap together things so much as organically evolve them.
In response to someone’s remark that “people with an eye for quality will always pay a premium for the right kind of service”, Warren also makes the point that “quality as a unique selling point is difficult in software”. How right he is. In a way, your clients have nothing but your word that your $90 an hour efforts have any more value than someone else’s $7 an hour efforts. If this perception were not tripping clients up, there would be no offshore labor market to contend with.
That is why developers must realize they are in a marketing game as much as a technical game. That is one reason I avoid using the term “programmer”. There are clients with “an eye for quality” and you want to attract those kinds of clients. As you get acquainted with the right kind of clients you learn what they like to see. Confidence, honesty and excellent communication skills (both orally and in writing) are important.
Another thing I’ve found invaluable is making clients feel in control by educating them in layman’s terms about what I’m doing and why, and what to expect next. This really differentiates you from someone who says “Sure, I can do that, it’s very simple and inexpensive” and then disappears, only to return (usually late) with something that’s not what the client actually wanted, is full of bugs, or turns out to be impossible to maintain.
All of these practices, coupled with best practices, lead to the truly “affordable” software … the stuff that’s on time, works right, is stable and flexible, and delights the customer. There are no shortcuts.
Lastly, to turn this discussion around, let’s look at the wrong kinds of clients and the whole issue of when to say “no” to a project. You can’t afford to waste your time on abusive clients with unrealistic expectations.
Some clients are dead giveaways — like the fellow who wanted to hire me to clone the Google search engine in six months, and then when speaking of compensation asked me “how much lunch money to do you need?”
Others are more subtle. Constant pressure to do things before they’re done is a major clue, though. In his excellent post, “Programmers are Brain Surgeons”, Sau Sheong Chang asks the rhetorical question, “if your brain surgeon said some procedure would take five hours, would you pressure him to do it in three?” (He gives credit for this quote to Scott Berkun in The Art of Project Management).
Now I grant you I am not as highly educated and trained as a brain surgeon and the software I write seldom influences life-or-death scenarios. But the point here is not that I’m trying to suggest what we do is as awesome as brain surgery; I’m suggesting that the results of rushed software development and rushed brain surgery will be equally unsatisfactory.
Another similarity between the two professions is that if a brain surgeon encounters unexpected problems he does not stop at five hours and walk away; he spends as much time as necessary to complete the job and overcome any difficulties. Clients who have a cow because you estimated five hours and spent ten on a task, just don’t understand what this game is all about. (Naturally if you always take twice as long as you estimate, you need to quit being so optimistic, but that’s a topic for another day).
Clients who always push you to do things yesterday either don’t trust you and assume you are always highballing your estimates; or, they are trying to take advantage of your desire to please them; or they are just plain clueless and cheap. Either way, they are toxic clients.
“Quality” trumps “cheap” any day … for those clients who can appreciate the difference and those developers who can help them appreciate the difference.
{ 1 comment… read it below or add one }
I can’t really agree about the term “programmer” being any worse than “software developer”. To me, when I think of an high skilled person in this field, the word “programmer” comes to mind. The phrase “software developer”, on the other hand sounds more like somebody who just got his or her MSCE for .net or visual basic, or something like that.
Did Kernighan and Pike call them selves “software developers” ? No. They call call themselves programmers and wrote a book titled, “The Practice of Programming“. Those guys wrote UNIX. Similarly, is Tom Christiansen referred to as a programmer or a software developer? What about Linus? What about Larry Page? Those guys are all programmers.
John, on the other hand, is a mere cog in the machine at some mediocre corporation, where he’s working on a customer billing system that is neither brilliant, nor cheap… John is a “software developer”. Is that really the camp you want to be in?
Bob responds: Good points, and I have no objection to being known as a “programmer” — by real programmers. And I’d be honored to be called a “hacker” by a real hacker, or anyone who knows the difference between hacking and cracking. The problem is that my clients — the people who put bread on my table — have a different association with those terms than you or I do. That’s what I’m talking about here. I feel that getting them to accept the heroic image of the programmer is a losing battle. Also, “developer” and “development” send a subliminal message they can relate to, about the organic and holistic nature of architecting and building great software, whereas “programmer” sounds way too mechanistic to the uninitiated. I don’t want to position myself as a worker bee assembling standard pieces; I want to be seen as a professional collaborating with them, understanding their problem domain and their business needs in the process.