Ben Allfree :: Painless Programming

I talk to a lot of prospective clients and can divide them into two groups:

1) those who want to transact business
2) those who want something else

It’s easy to tell. The people who want to transact business call with a specific project objective, ask specific project-related questions, and make their decision within 5 minutes.

If you’re not able to do that, you are in the Something Else group. It means that for whatever reason, you are standing in the way of your own success. Here are some clues to self-identify with group #2. If you find yourself using words like these, it’s time for a reality check:

* simple/quick/easy/just (”This is very simple…”)
* future (”If this goes well, there will be more work in the future”)
* explain (”What I really need to do is sit down and explain this to you”)
* local (”I need someone local, someone I can see”)
* reliable/expert/top-notch/ninja/guru/coder/scripter (”I’m looking for a ____”)
* no/not (”No offshore. My project is not like the others…”)
* percent (”This project is 90% done, I just need to…”)
* skills/test/strong (”There will be a test to see how strong you are…”)

Let me explain why all of these words are bad news: they are ways of talking about yourself and the “soft” qualities you seek instead of stating plainly and simply what the job is.

One reader wrote in to say that these were simply ways of assessing attitude, skill, and competence. I don’t disagree. My assertion in this article is that if you are choose to do so in these ways, you are in trouble. You’re telling a lot about yourself and your project by what you choose to focus on. If you focus on soft qualities instead of explaining exactly what the job is, my assertion is that you do not know what you want. The people in group #1 evaluate soft qualities while talking about their concrete objectives. You can too, if you know what you want.

Think something is simple or quick? It isn’t, or you wouldn’t be asking for help. Try taking the line out of the project description and see if the essence of your goal is still intact.

Will this lead to future work? The fact that you needed to mention it means it’s a little too important in your mind. It takes the focus off the present. Try omitting future talk.

Feel like you have to explain the project to me? Your project is broken until it can be decomposed into logical steps for others without background information. Trust me, the back story is not necessary if you know what you want today.

Need someone local? Working with embedded systems might be the one exception to the on-site requirement, but otherwise I think it’s another indication that you don’t know how to get what you want. It seems easier if you can sit down with someone face to face. It might even be easier. The point is, you’re confused about what you need and that’s a red flag.

Need an “expert” who is a “reliable ninja”? That says to me that you are looking for a mind reader. That’s why the last normal programmer did not work out. Try skipping subjective qualities like this and focus on the specific, objective qualities you do need.

Spending time in your ad focusing on negatives or explaining what the project is not? There is a whole universe full of things that are not your project or not your ideal programmer. Only you can describe what your project is and who the programmer is. Try removing talk that is unrelated to your goals.

Is your project 90% done? Avoid inserting your own estimates. I have to make my own anyway. There’s no useful information there, other than expressing hope that it’s close to being done. And every time I hear this, I know the project is nowhere near done.

Got a test for me to take? This is debatable. Yes, coding is where the rubber meets the road but I think you should be able to pre-qualify candidates without the test. Pay them to spend that kind of time if you really want someone to offer what is essentially a sample of the service you will receive.

Again, none of these things are outright wrong, I have just found over thousands of project meetings that placing focus on these areas invariably indicates deep problems with the project fundamentals.