Who is a Programmer? (was RE: WDSC and Linux)

CODE/400 Discussion & Support <code400-l@xxxxxxxxxxxx> writes:
>What happens when something you know how to "use
>effectively" breaks?  Can you debug it?  Do you know enough about what it
>is
>SUPPOSED to do to determine what it's not doing?

Actually, Joe, I'm with you on this one (I think I am, anyway :-). If
something I write doesn't work as expected, then I need to be able to
analyze it step by step until I find the problem, and then bullet-proof it
so that it doesn't happen again. In fact, I've long thought that a big
difference between really good programmers and not-so-good ones is not
that the really good ones write bug-free code (although I think they learn
to over time), but they are much more dogged about tracking down the bugs
that they create.

I guess my question is one of degrees: do I really have to know how to
write an operating system to be qualified to write an invoice processing
program? To take a simple example, if I WRITE a record in my program, I
think I should know exactly what data is in that record, where it came
from, and why it's there. If the wrong data gets written, I need to be
able to track down the cause and fix it. But do I really need to know
where that data went on the disk? Or how the disk controller got it there?
Or which registers the processor used to control the whole process?

Frankly, I'm not convinced I do (maybe you'll change my mind :-). On the
other hand, I may well need to know about output buffers; especially if my
record doesn't seem to be getting written as quickly as I expect it to be.
So the line separating what I need to know from what I don't may not be a
firm one, and it may depend on the problem I'm trying to debug (I don't
like hardware, for example, but I've learned quite a bit about it over the
years because of problems I've had to solve that were hardware-related).




Mike Naughton
Senior Programmer/Analyst
Judd Wire, Inc.
124 Turnpike Road
Turners Falls, MA  01376
413-863-4357 x444
mnaughton@xxxxxxxxxxxx