How can I make a non-programming person recognize a good programmer?

Let's assume that I would be a good programmer and I knew that my (non programming) customer will have to decide between me and a competitor. Let's say that I, as an experienced programmer, would obviously see that my competitor is inexperienced and trying to fool the customer with some nice presentations or an expensive suit.

And here is my problem: How can I empower my customer with the aibility to distinguish between a good and a bad programmer? What can I tell or teach him to be able to look a bit behind the scene?

Same problem, other situation: The nice guy from HR has to hire some programmers on his own. How can I brief him?

Here some solutions that seem obvious, but do not work well:

• Tell the HR guy to send the best 10 candidates to me. (Changing the assumption -- "non programming person" -- is a solution, but not to this problem.)
• Give the customer 5 questions he should ask the competitor. (Bad style and the customer still has no clue.)
• Teach the customer how to code. (errrr ... try again please)

From stackoverflow

• For the latter question: let him explain something. For instance polymorphism or inflexion.

  A good programmer should be able to explain it to a person without any programming skills.

  Nicholas : I'll agree that it might be an okay way to weed out bad programmers, but it isn't exactly a benchmark for "good programmers". I know a few programmers that could explain polymorphism to my grandpa, but that doesn't translate to the quality of their work.

  Jonke : I know people that are good at teaching "generic" programming but they can't write a single line in real application. (Hello World is not a real application).

• Short answer: You can't. At least, not until you define a "good programmer".

  Without that clarification, I'll take a page from Joel's book and say that the primary qualities of the programmer are pretty easy for a non-programmer to measure: Smart, and gets things done.

  Jonke : I agree but I would like to have "Done, and get things smart" if I can choose.

  MrFox : "getting things done" is hard to decide in the situations above

  Nicholas : MrFox: as a HR hiring rep? I'd hope not.

• This is a perfect situation when Marketing skills come in handy. This is exactly one of the reasons good programmers need good marketing skills. Otherwise marketers will win. And precisely because marketing is understandable to the layman that we need to compete on that ground and not on programming alone.

  Jeff had a great post about his that came from Steve Y's great speach about this

• Tell your non-expert that if this guy walks through the door, give him a job.

  S.Lott : Depends on the job. I've read interviews with Knuth and he doesn't seem focused. He might follow his gut and instincts a little too much. Great if you're hiring someone to invent fundamentally new kinds of apps. Maybe not so good for shipping product on schedule.

  Ali A : Yeah, I agree, I was just trying to be funny.

  Ali A : (a deadly game on s.o.)

  Ken Liu : that guy doesn't even use email. http://www-cs-faculty.stanford.edu/~knuth/email.html

• In my experience there really isn't a way that you can make a non-programming person realise that your competitor is worse then you, because no matter what you say, the customer has in the back of their mind the fact that you are trying to get the same work as your competitor and that is going to colour their judgement of whatever you say.

  In my experience it is better to simply show the customer your past record of successes vs your competitors past record and then encourage them to ring former clients of both you and them and get their opinions.

• Just like Nick Baldwin wrote, a non-programmer can't evaluate someone's technical skills and that's why we around here always have some kind of technical expert for interviews.

  S.Lott : Here's a suggestion -- vote up the answer you like. Add comments. But repeating the answer you like can be seen as a waste of time.

  t3mujin : I took Nick's answer to add my own experience: in my company there's always someone with a technical background in interviews.

• The customer is a person who doesn't need to know if you are a very good programmer. He has a problem and you can help him to fix it...and that's it...if you try to explain him that you are best than your competitor hi won't care! Hi just wants his problem fixed...

  Now you need to convince the customer that you are offering the best solution to his problem and that you will help him to decide what's best for him and his business...if you can do this without mentioning any technologies or languages or frameworks that maybe the customer will pick you.

• I think you need to describe the qualities that set a good programmer apart from the rest: good communication skills, attention to detail, ability to describe problems from different perspectives, knowledge of business, ability to organize.

  If you think of it, the process of running a SCRUM meeting would be good description of the organizational skill that a programmer possesses. How would the programmer describe a problem that they are encountering, and how is this affecting his / her schedule. Furthermore, can these descriptions be described in business language and with analogies? The mark of a facile mind is one that can switch gears and still communicate.

  On the skill front, when you describe good programming skill to a potential customer, what are those things that make a good programmer? How do design patterns help? How does in depth knowledge of a related system bring dimension and breadth to a developers experience.

  Finally, does the developer have a blog? Maintaining a blog can speak to the level care one takes when maintaining skills.

• It's all about trust. Does your customer trust you and ask for your opinion? Does HR trust you?

  If they don't trust you, you can't make them or empower them or influence them at all.

  If they do trust you, then your opinion will be of value and you now have the real problem of getting them to ask for your help in choosing a programmer.

  I interview programmers by the dozen. I suspect it isn't because I've got great questions or some profound insight into the programming mind. I interview programmers because my opinion is trusted.

  If you opinion isn't trusted (or isn't trusted enough), what's wrong with your relationship? What aren't you doing? What could you do more of, less of or differently to improve the level of trust.

  Here's one theory: lack of trust can be mutual. Perhaps you don't trust them to do the right thing and it shows. Because you don't trust them, they don't trust you.

• A couple of people have mentioned things like "define a good programmer".

  A Good Programer is more than the sum of his parts. He will know multiple languages in several disciplines and knows how to use several of them together. He will also know how his skillset interacts with others in a team (e.g. to the DBA or the webmaster) -- he may in fact have the skills to be those other people to some extent. Moreover, he will be able to speak about his experience and achievements using these skills from a position of authority and modesty. A HR person should be able to recognize both of these.

  The other way to answer your original question is that they have to watch someone who knows what they are doing pick good programmers from not good programmers, being aware that this is the skill they are being asked to learn.

• Show the non-programmer something that will dazzle him, a small demo of a killer application (something very fancy) always gets the job done.

  Edit: if you don't have any killer apps, the you gotta ask yourself if you really are better than the competition. ( Customers want good applications, not bad ones that have great code in them ;-) )

• Your question is sort of like asking, what makes a good President?

  The answer turns out to be the same as well. Most likely a person is going to be good at a specific task if they have an interest in the job at hand, experience, a good work ethic, can communicate, and are intelligent. While all those are very general qualities and do little to identify the specific toolset that a programmer might need, they certainly lay the groundwork for the ability to learn and comprehend specific areas like programming.

  You can't inform others about the specific qualities of a complicated domain (i.e. programming) without at least knowing that they know something about the domain. So the most logical thing to do is rely on the thing people have been doing for generations: judge the overall qualifications of the candidate.

• This is where being able to articulate your accomplishments come in handy. Explain in detail, but in a fashion that is understandable to non-technical folks what projects you've been a part of, your part in the project, what you did, and why what you did was so great.

  When you're trying to sell your self (in an interview or trying to land a contracting job), the interviewer knows that you are directly competing with other people. You saying "I am better than the other guy" or "the other guy stinks" means nothing to them, because you are competing with the other guy and the interviewer expects you to compare yourself more favorably to your competition.

  But if you are truly a good programmer, your accomplishments will be more impressive than your competition's accomplishments and the interviewer will take notice.

• Don't compete with your competitors on direct technical skills. While they're burbling on about ASP.NET or whatever, you can explain how you would add real value to the business.

  In other words, cut out the technical muddle and go direct to the business problem.

• A good portfolio of your past work can do most of the talking for you. It has worked for me on a couple of occasions, and I think to a non-programmer, seeing might be believing - if what you show is genuine and good.

• One thing I've done in the past to help a non-programmer manager in the hiring process is to set up a short test covering some of the fundamentals I'd expect a "good programmer" (for that particular role) to be able to cover pretty easily.

  It worked surprisingly well - some people interviewed well, but bombed in the (not too difficult) test. Some interviewed so-so, but blitzed the test.

  When faced with two people who both interview well, when one scores 5/25 and the other scores 23/25, you know who you're going to more inclined to offer the job to..

  I know it's far from perfect, but it's actually worked so well for me that I'm now disappointed when I go to job interviews and they don't test me in any way. In fact, in almost 10 years in my industry I've never been tested in any way, shape or form when applying for a new job.