When I first started consulting independently, I was a software prostitute: any opening, name your position, I'd do any job that came my way if the price was right. Now that I'm older and prettier and have several steady clients I can afford to say "no thanks" to some
tricks engagements. What are some criteria for refusal?
- Too busy. Starting with the obvious, if you don't have time for more work, you shouldn't take it. Unless you can sub it out successfully.
- Ethics. You don't want to find yourself working to promote something you don't believe in. But this one gets pretty tricky. It's obvious that you don't take a job from an internationally-located Web ring that publishes explicit pictures of children, but what about a company that has a manufacturing facility in China that employs underage labor? If you say no to that, then how about a software company that provides solutions for that company? What about a vendor to that vendor? The higher up you go in the software food chain, the greater the likelihood that you'll unwittingly benefit some organization that you'd like to hamper instead. Do you shrug it off and say, "I only make the gun, they pull the trigger"? Also, how many different ethical principles must you consult? Does your potential client bank their business on intellectual property laws that you find objectionable? Would they sacrifice user privacy in order to gain more information about their users? Do they subject their developers to the tortures of Visual Basic? (Ultra-smooth segue to...)
- Technological satisfaction. Is this really the kind of work that you want to be doing? I'm not just referring to being on the winning side of the ubiquitous language wars. I can be pretty creative even if I have to use a statically-typed language. What's more important is whether the project itself is pushing some envelope and creating something new. When it comes to development, you become what you do — and you don't want to become the go-to guy for cranking out cookie-cutter applications that immortalize 30-year-old programming standards.
- Insufficient skills. I like being challenged, but I also need to be able to bring more to the table than the fact that I'm a quick learner. To balance this bullet against the previous one, ideally the project should have a pretty high overlap with my niche skills, but should extend beyond them just enough to keep things interesting. I'd love to work on developing the next great programming framework, but I'd be out of my depth trying to make a computer pass the Turing Test. I might be flattering myself just a bit here.
- Conflict of interest. This is really a special case of an ethical problem, but deserves separate attention. Except for special cases where you can provide your services without being privy to trade secrets, you don't want to go to work for a direct competitor of one of your existing clients unless you're ready to cut the ties with that first client. You should also be cautious about taking work from a company that employs your significant other, a close friend, or a member of your family. Not saying that you can't do it, but be aware that if either engagement goes south, the other can suffer as a proxy punching bag.
- Interpersonal issues. Some people are just too hard to work with. I'm sure you can fill in the blanks on this one.
- Low pay. Some projects don't have the budget. I find that this one is becoming less of an objection to me as I grow older, though. Sometimes your heart is in it — like a charity or an open-source project. Sometimes it's fun to help out the small startup and see where it goes. And sometimes those small startups make it big, so taking a share of the business in lieu of pay might even turn out to be a good financial decision in the long run. What you don't want to do is take less than you deserve from a company that's maintaining status quo.