[Purdue-pm] Picking a programmer - Summary 2

[Ken mcNamara]

Mark F. and Mark S. contributed some additional valuable points -

////////////////////////////////////

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.


TESTING -

Mark Fisher adds a valuable point:

I'll throw one more into the mix - checking that they can program rather than just cut'n'paste. I was lucky enough to start giving a little programming test when I helped with interviewing before I ran into a programmer who could talk his way around anything, but was unable to program his way out of a burning paper bag.

The Fizz-Buzz problem is pretty good for this, as it doesn't require any domain-specific knowledge.




FUNDAMENTALS (implicit qualities) -

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?

Mark Senn added 3 points to fundamentals:

Patience, Filtering out the noise, and Being able to Focus

Without patience, which is increasing difficult to find in undergraduate
students at Purdue University, some people probably never get past writing
their first hard programs that requires thinking, handling lots of special
cases, learning new subject matter, etc.  So, patience might be able to
be added to the implicit qualities a programmer has.

"Breaking a problem into component parts ignoring information that
doesn't matter" makes programming easier.  For example, given this problem:

  " Mark went to McDonald's yesterday---it was hot and muggy---and took
   advantage of a deal to get two sandwiches for the price of one by
   filling out a survey at mcdvoice.com.  He paid $5.16 for a $4.91
   bill.  How much money should he get get back from the young clerk?
   It's handy to minimize the number of coins one carries around."

The only thing that is relevant is:
   "….paid $5.16 for a $4.91 bill.  How much money should he get back?'…."

 The answer is 25 cents.

One more subtle point here - the client might reject the program because it
should have returned "A quarter".  

Speaks to the point of taking criticism.

Finally - FOCUS

"Being able to focus" is a key skill for a programmer.  I think today's
youth can't focus because school is becoming more group-oriented and
they don't think as much on their own.  I see students working together
who can't go for more than a very minutes before drifting off into
something unrelated.  Their attention spans are near zero because
they've never worked on a problem for more than a few minutes.  They are
constantly distracted by music, over the ear headphones (when crossing
the street), Facebook, cell phones, etc. and I think that affects their
brains (no references for that offhand but I've read that others think
that also).

Thank you all!

KenMc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/purdue-pm/attachments/20140824/21ecd83d/attachment-0001.html>