Someone told me that easiest way to 'destroy' a programmer is to prevent them from programming for a month or so. Is that correct? What should I do to make sure I stay in practice if I'm not in a position to program as part of my job?
I think the person you refer to may have mixed two different levels of knowledge/ability.

The first is general problem solving ability. This is not going to fade away, as others have explained with good examples. I myself had two breaks in my career as a software developer, once for a year, and the other was close to a year, during which I did practically no programming. I could come back to the profession without major problems after each of these. 

However, as Chris put it, my knowledge of specific language/API features became "rusty". That is the other level, which is more short term knowledge, and it can indeed fade away fairly quickly (although IMHO not in a month - you would need several months to notice the difference). 

Note though that these things often have a shorter half-life anyway - APIs change, preferred language idioms get obsolete and new ways come along, etc. Let's say you have several years of experience in language A, but nowadays you are programming exclusively in language B. Your skills in language A will inevitably get rusty over time. However, you will be able to dust them off fairly quickly.



As for the best way to "destroy" a programmer, I am sad to say there are well known, proven and (unfortunately to our industry) widely practiced methods:


always push him/her to deliver results to unrealistic schedules
demand regular unpaid overtime
burden him/her with bureaucracy, e.g. demand that (s)he get approval from your boss' boss' boss for, and/or fill out lengthy documents before/after each code change
reject any process/quality improvement idea of him/her with whatever excuse you can find (e.g. "if it ain't broken, don't fix it", or "this is just the latest fad, no need to take notice")
initiate a personal bonus system within the team, overtly stating that the team has a fixed amount of total bonus allotted, so team members must compete against each other for it
micromanage him/her, retaining the right to make every technical decision yourself by authority
give him/her inadequate tools for the job (old PC, small monitor) 
cram him/her into tiny and noisy open office spaces, preferably together with totally unrelated but noisy people (e.g. sales/marketing)


If practiced consistently, in a few year's time these are almost guaranteed to make your developer(s) burn out, killing any desire and enthusiasm in them towards programming.

These are some that come to my mind - unfortunately there are more :-(((
