× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.