[TUHS] How do we learn about maintainability - was Re: really Pottering vs UNIX

[Toby Thain]

On 2017-09-15 3:10 PM, Chris Torek wrote:
>> ... He made the point that a good program never dies, and many
>> people will read it and modify it and try to understand it, and
>> it's almost a professional duty to make sure that you
>> make this as easy as possible for them.  

+1

> 
> This is true of many good programs.
> 
> On the other hand, many programs are not good programs.  And it
> winds up being true of many bad programs too. :-)
> 
>> Maybe a guild is a bit too stuffy, but being mentored by someone
>> with their head screwed on straight, and consequently making a
>> point to seek out excellent examples of the programming art and
>> learn from them had a profound effect on my skill as a programmer
>> and my career.
> 
>> I don't think I would have found this in a book or long midnight
>> hours hacking away...
> 
> I'm not so sure: I learned some of this myself when working on my
> Z80 assembler written in (some Microsoft variant of) BASIC.
> Because it was such a terrible language, I had to keep a master
> "notes" table giving each subroutine's line numbers, input
> variables, and output variables (no call-by-anything in BASIC so I
> had to stuff a register name like "BC" "DE" "HL" "IX" "IY" into
> one global variable, "GOSUB 10100", and take the result back in
> more global variables).
> 
> Nonetheless, it's true that seeing / recognizing "good" vs "bad"
> software is a valuable pattern matching skill.  As with all such
> things, the best trick I've ever discovered is not just to learn
> from my own mistakes, but to learn from *other people*'s mistakes
> too!

YES - this is why I believe being a maintenance programmer on other
people's code is so important; you'll be left with a real understanding
of why good practice is important, and, quite likely, a fiery desire to
try to make things better.

I think any junior programmer would benefit from at least five years of
maintenance experience. Giving them greenfield projects out of the gate,
especially unsupervised, merely adds to the pile of unmaintainable stuff
- while teaching them very little.

--Toby

> 
> Chris
>