I definitely agree.

I have to caution that we do not have enough information to make an informed call on the skills of programmer B - neither as far as his abilities as a programmer are concerned nor about his ability to judge the quality of the downloaded code. Nor do we know how critical the task was and how acceptable a sloppily coded solution might be in this case.

But I feel that in practice, people who take this approach are cargo cultists far, far more often than not.

Not reinventing wheels is a good mindset, but it requires being able to tell round wheels apart from square ones. Many people quite simply lack the experience and expertise to do so. That is why places like the CPAN are so important.

Makeshifts last the longest.

We may not make an informed statement on the abilities of programmer B, but we know enough to make an informed guess.

Programmer B's method of development was cut and paste, followed by light editing. People who routinely develop this way are generally not very good. Good developers engage in code reuse by modularizing and then reusing modular chunks.

This is why I object to dws's rewrite. It changes the evidence of programmer B's development methodology significantly for the better. It also eliminates the common element of starting with someone else's work and presenting the result as your own.

Programmer B's method of development was cut and paste, followed by light editing. People who routinely develop this way are generally not very good.

The task is to prepare a demo. To infer from that what Programmer B's "routine" development strategy is requires assumptions based on facts not in evidence.

It also eliminates the common element of starting with someone else's work and presenting the result as your own.

Where do you see any indication that Programmer B misrepresented his/her work?