[Purdue-pm] Picking a programmer - summary

[Ken mcNamara]

Thanks for the answers - they were interesting and helpful.

LANGUAGES - 

This statement from 'dsk' clarifies something I think is key -

"Understanding multiple programming paradigms (functional, procedural, object oriented, vector) is more interesting to me than knowing multiple languages. I feel that language is a lot about knowing the correct syntax, a little about understanding peculiarities between languages. Knowing how to think through a problem using a paradigm allows you to approach a problem from many angles, weighing the benefits of each."


My experience suggests that while most people (even technical people) can be taught to program - only a few will be able to do it well.   This would explain why it's more important to hire an experienced (proven) programmer than it is to focus on "language experience".


COMMUNICATION -

Rick W., Mark Ward and dsk make points about communication

dsk: "Being able to figure out what people really want and tease out the use cases seems to be more of an art than a science."

Mark: " They need to be able to work with other people to understand the content of the programming task, the motivation, the impact, the users, etc.  They also need to be able to document their code, if you want a really high quality product."

Rick: "Without the ability to communicate then you won't get good internal code comments nor external documentation.  The daily status reports will basically be a grunt.  The programmer will not listen to nor clarify customer comments, complaints and suggestions.  All of those behaviors can be enforced however you won't get *good* results unless the programmer can actually communicate."


Perhaps this begins with the ability to accept criticism without taking it personally.  It's hard to accept that your code (which you worked on for hours) could have a fatal flaw.


SUBJECT MATTER -

Mark Senn makes an important point -

"Knows subject matter that project is for, at least well enough to get along if not actively understand it. "


Speaks to the ability to communicate.  The end user may not want to work with you if you have zero knowledge of their area.  You don't have to be a 'subject matter expert' - but there has to be a starting point.  The end user will educate a person who can communicate - but the programmer probably has to put forward the first effort.


FUNDAMENTALS -

Mark: " Organized. Experience. Detail oriented. Work ethic. Curiousity."

dsk: "Problem Solving. Curiousity. Creativity."

Bradley Westerman: "Problem Solving. CS knowledge."


Without these - perhaps a person never even attempts programming?


Thanks again.

KenMc