Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site bnl.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!houxm!hogpc!houti!ariel!vax135!floyd!cmcl2!philabs!sbcs!bnl!jpm
From: jpm@bnl.UUCP
Newsgroups: net.lang.c
Subject: Re: Comments on book review: Bugging != Hacking
Message-ID: <437@bnl.UUCP>
Date: Mon, 30-Apr-84 23:42:11 EDT
Article-I.D.: bnl.437
Posted: Mon Apr 30 23:42:11 1984
Date-Received: Wed, 2-May-84 06:09:57 EDT
References: <219@cubsvax.UUCP>
Lines: 24

Hacking is like bugging in that the programmer doesn't
spend hours designing a program that will take 5 minutes to
write, but a good hacker can sit down at the terminal and
make it work the first time. A good hacker is also quick to
see that what he is doing isn't working out the way he
wanted it to and can change the design quickly and easily.

I am in the process of writing a message system for a school
district (really a glorified BBS). I designed files and
general ideas ahead of time, but over the last month I have
made many changes and added things that I never would have
thought of had I not sat down and started hacking at it.

I think a good way to think of bugging is hacking by an
inexperienced programmer. It takes experience and ability
not to turn hacking into bugging. The student refered to in
fortune!crane's article would probably end up bugging
instead of hacking because of inexperience (not to put down
students as a class (I am one of them!) but "student" does
imply you are still learning).

---
>From the pseudo-random mind of John McNamee
..!decvax!philabs!sbcs!bnl!jpm		jpm@Bnl.Arpa