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.