Re^3: Initiative or otherwise?

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.

Generally, scenario one is much harder to judge than scenario two, irrespective of the fact which has already been pointed out that the goals differ.

Makeshifts last the longest.

Comment on Re^3: Initiative or otherwise?

Replies are listed 'Best First'.
Re: Re^3: Initiative or otherwise? by Anonymous Monk on Jul 08, 2002 at 22:34 UTC
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.	[reply]
Re: Re: Re^3: Initiative or otherwise? by dws (Chancellor) on Jul 08, 2002 at 22:41 UTC
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?	[reply]
Re^6: Initiative or otherwise? by Aristotle (Chancellor) on Jul 09, 2002 at 01:15 UTC
To infer from that what Programmer B's "routine" development strategy is requires assumptions based on facts not in evidence. Are we discussing the validity of code reuse or an approach to developing demos? If you place too many constraints, the analogy becomes meaningless and we end up debating a specific situation bearing no relation to anyone else's reality. Makeshifts last the longest.	[reply]