Subject: Re: what makes a production quality programer? (was Re: New Lisp ?) From: Erik Naggum <erik@naggum.net> Date: Sat, 29 Dec 2001 22:48:07 GMT Newsgroups: comp.lang.lisp Message-ID: <3218654884764918@naggum.net> * Erik Naggum > Fourth, someone who can deal with upgrades just as effortlessly and does > not remember things past after they have changed. * Paolo Amoroso | Can you elaborate on this? While I understand the literal meaning of the | last sentence, I'm not sure whether I also get its complete meaning. Do | you mean that, after a system upgrade, the programmer should no longer | worry about problems that have been fixed by the upgrade? Many people learn through painful experiences and pain avoidance is a very fundamental property of human behavior -- "once bitten, twice shy" has an equivalent and very old idiom in every language. Failure to trust a function because it once was buggy is very common among programmers who learn through trial and error instead of through reading specifications. Even those who do relate primarily to specifications get bitten by the lack of conformance to those specifications by the vendors they trusted to implement them. So instead of shying away from them, a production quality programmer relearns and conditionalizes code on the specific broken versions. This is the hardest part of dealing with non-conforming systems that evolve slowly towards full conformance. Some vendors also think that their non-conforming behavior has made customers depend on it, so have a hard time correcting conformance problems because they think their past customers are unable to accept the painful experience of having to update their code because they did not program according to the specification, either, but according to "whatever works", discovered precisely through a painful process of trial and error. This is one reason conformance to a specification is so important. To your direct question, a properly handled dependency chain for software upgrades should in fact mean that once a dependent system has been upgraded, the problems exhibited by prior versions should no longer be the subject of worries. Absent properly handled dependency chains, there is no hope of controlling any behavior at all, anyway. /// -- The past is not more important than the future, despite what your culture has taught you. Your future observations, conclusions, and beliefs are more important to you than those in your past ever will be. The world is changing so fast the balance between the past and the future has shifted.