× 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.



>>>How many times have we fixed a program, and then not 
>>>really understood why or how we fixed it??  
>>
>>In my case, never.  If I don't understand the 
>>code then I don't put it into production.

>Don't break your arm patting yourself on the back!   I never 
>said I didn't understand the code, I just said eventually 
>something I did fixed the program and I really didn't get 
>to take the time to really figure out which change 
>corrected the problem.

It appears that my brief response has been misinterpreted.  I often post
long, dreary answers, and in trying to be concise, it appears I have been
terse instead.  Let me therefore expand on my brief sentence.

I do not intuitively understand all code that has ever been written.  But as
a professional, I work very hard to move in that direction.  When I come
across something I don't understand, rather than  poking production code to
see how it twitches, I read every reference I can find, search the archives
of various mailing lists and back issues of various periodicals.  I always
assume that someone else has solved my problem before me (rather, I think
the converse: no problem _I_ am going to encounter is new to the universe.)
I don't work on cutting edge stuff, so my problems tend to be somewhat
plain.  In fact, they tend to be my own fault (like taking an SQL example of
null maps instead of a trigger example.)

I've done my homework and am still confused.  Now what?  Instead of "try
this" and "try that", I set up a test bed and pound it with as many test
cases as my little brain can dream up.  Please read the top sentence again
in this context and I hope you'll see that my intent was to say that the
code stays in test until I completely understand it.  Only then does it move
live.  It has been my hard-won experience that if I do not "take the time to
really figure out what change corrected the problem", then I really haven't
finished the job yet, and the code is not ready to go.  All too often, code
"fixed" in this way breaks in production, and _nobody can really explain
why._

So I am not patting myself on the back at all; instead acknowledging my many
shortcomings, and adapting my work ethic so that I do not put questionable
code into production.

Regards,
  --buck

As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.