in reply to Re: Initiative or otherwise?
in thread Initiative or otherwise?

Let's not redefine things that way.

Programmer B is described acting like legions of people who needed something, found a starting point on Matt's Script Archive, and proceeded from there. My guess is that their average output has the same quality as most people who think that cheating is OK. I have similar opinions of both groups...

Replies are listed 'Best First'.
Re^3: Initiative or otherwise?
by Aristotle (Chancellor) on Jul 08, 2002 at 01:53 UTC

    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.

[reply]
      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]
        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]

In Section Meditations