[TUHS] really Pottering vs UNIX

[TUHS] really Pottering vs UNIX

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2373 bytes --]

On Thu, Sep 14, 2017 at 4:09 PM, Jon Steinhart <jon at fourwinds.com> wrote:

>
> Well, I'd suggest that a lot of this has to do with people who have vision
> and people who don't.  When you look at UNIX, you see something created by
> a bunch of very talented people who had a reasonably shared vision of what
> they were trying to achieve.
>

​Jon - I mostly agree, but would twist it a little differently (hey, we've
been arguing since the 1970s, so why stop now).

I think you are actually touching on an idea that has been around humanity
for a long time that is independent of the computer field.  We call it
"good taste."  Part of acquiring good taste is learning what is in bad
taste, a heavy dose of experience and frankly the ability to evaluate your
own flaws.   What I always love about Dennis, Ken, Doug, Steve and the rest
if the team is their willingness to accept the shortcomings and compromises
that were made as the developed UNIX as a system.   I never saw them trying
to claim perfection or completeness, much less and end state had been
reached.  Always looking for something better, more interesting.  And
always, standing on the shoulders of others...

What I really dislike about much of the crowd that has been discussed is
that they often seem more contented to kick people in the shins that
standing on their shoulders.

I used to say, when we were hiring people for some of my start-ups, what we
wanted was experienced folks that had demonstrated good taste.  Those are
people you can trust; and will get you pretty close to where you want to be.

In fact, to pick on one of my previous employers, I have always said, what
DEC got wrong, was it was always striving to be perfect.  And lots of
things never shipped, or when they did (like Alpha) it was wonderful, but
it did not matter.  The opportunity window had passed.

Part of "good taste" is getting the job done and on time.  Being "good
enough" and moving on to the next thing.   Sun (certainly at the beginning)
was pretty good at this idea.   The UNIX team clearly got a lot of it right.

It is easy to throw stones at others.  It is hard to repeatedly get so much
right for so long and UNIX has and did.

Clem

​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170914/da3bc291/attachment.html>

[TUHS] really Pottering vs UNIX

[Bakul Shah]

> On Sep 14, 2017, at 1:46 PM, Clem Cole <clemc at ccc.com> wrote:
> 
> I think you are actually touching on an idea that has been around humanity for a long time that is independent of the computer field.  We call it "good taste."  Part of acquiring good taste is learning what is in bad taste, a heavy dose of experience and frankly the ability to evaluate your own flaws.

More to do with a sense for quality. Often developed through experience
(but not just that). I think what we need is a guild system for
programmers/engineers. Being an apprentice of a master craftsman is
essential for learning this "good taste" as you call it.

> 
> Part of "good taste" is getting the job done and on time.  Being "good enough" and moving on to the next thing.   Sun (certainly at the beginning) was pretty good at this idea.   The UNIX team clearly got a lot of it right.

Agreed.

[Just nitpicking here! I think we agree on the underlying concept]

[TUHS] really Pottering vs UNIX

[Dan Cross]

On Thu, Sep 14, 2017 at 5:15 PM, Bakul Shah <bakul at bitblocks.com> wrote:

>
> > On Sep 14, 2017, at 1:46 PM, Clem Cole <clemc at ccc.com> wrote:
> >
> > I think you are actually touching on an idea that has been around
> humanity for a long time that is independent of the computer field.  We
> call it "good taste."  Part of acquiring good taste is learning what is in
> bad taste, a heavy dose of experience and frankly the ability to evaluate
> your own flaws.
>
> More to do with a sense for quality. Often developed through experience
> (but not just that). I think what we need is a guild system for
> programmers/engineers. Being an apprentice of a master craftsman is
> essential for learning this "good taste" as you call it.


No, please; not this old saw again.

This guild system for software keeps coming up but I don't see how it
cannot but be abused. I remember reading one of those self-help books by
one of the agile types (I forget which one) and there was a vignette about
one of the self-styled agile gurus (Robert C Martin, I think) coming into
some room where people were undergoing "apprenticeships" an, seeing an
overflowing trashcan and taking out the trash. The person telling the story
went one and one about being so embarrassed because s/he was "just" a lowly
intern and this "master software craftsman" had taken out the trash.

I pretty much stopped reading after that. Sorry, but I cleaned enough heads
and squad bays when I was in the Marines; Robert C Martin can take out his
own trash, thank you very much. Also, I read one of his books once and he
misspelled "Lieutenant" in the chapter about quality and attention to
detail (a minor detail I was acutely aware of because I was a Lieutenant at
the time).

I think a better system than putting us into this rigid hierarchy system is
to think of programming as somewhat analogous to writing; it requires
proofreading and good editing. Some authors are better than others;
practice helps a lot, writers workshops can help, seeking out advise and
mentorship from more accomplished writers similarly, etc.

But the guild/craftsmanship metaphor just doesn't work for me.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170914/fdb77415/attachment.html>

[TUHS] really Pottering vs UNIX

[Wesley Parish]

Quoting Dan Cross <crossd at gmail.com>:

> On Thu, Sep 14, 2017 at 5:15 PM, Bakul Shah <bakul at bitblocks.com>
> wrote:
> 
> >
> > > On Sep 14, 2017, at 1:46 PM, Clem Cole <clemc at ccc.com> wrote:
> > >
> > > I think you are actually touching on an idea that has been around
> > humanity for a long time that is independent of the computer field.
> We
> > call it "good taste." Part of acquiring good taste is learning what is
> in
> > bad taste, a heavy dose of experience and frankly the ability to
> evaluate
> > your own flaws.
> >
> > More to do with a sense for quality. Often developed through
> experience
> > (but not just that). I think what we need is a guild system for
> > programmers/engineers. Being an apprentice of a master craftsman is
> > essential for learning this "good taste" as you call it.
> 
> 
> No, please; not this old saw again.
> 
> This guild system for software keeps coming up but I don't see how it
> cannot but be abused. I remember reading one of those self-help books
> by
> one of the agile types (I forget which one) and there was a vignette
> about
> one of the self-styled agile gurus (Robert C Martin, I think) coming
> into
> some room where people were undergoing "apprenticeships" an, seeing an
> overflowing trashcan and taking out the trash. The person telling the
> story
> went one and one about being so embarrassed because s/he was "just" a
> lowly
> intern and this "master software craftsman" had taken out the trash.
> 
> I pretty much stopped reading after that. Sorry, but I cleaned enough
> heads
> and squad bays when I was in the Marines; Robert C Martin can take out
> his
> own trash, thank you very much. Also, I read one of his books once and
> he
> misspelled "Lieutenant" in the chapter about quality and attention to
> detail (a minor detail I was acutely aware of because I was a Lieutenant
> at
> the time).
> 
> I think a better system than putting us into this rigid hierarchy system
> is
> to think of programming as somewhat analogous to writing; it requires
> proofreading and good editing. Some authors are better than others;
> practice helps a lot, writers workshops can help, seeking out advise
> and
> mentorship from more accomplished writers similarly, etc.

I agree with that. To write a story or an article, you have to know where you are going with it. You need 
to know how to make the best use of your resources - the language, the register of language eg chatty 
versus formal versus jargon versus whatever - which implies you have to know those resources, you 
need to know how everything fits together in their contexts unless you are writing satire or comedy or 
such in which case you are deliberately aiming for the resulting absurdity. Etc, etc.

And you don't get that from being told about it. You have to do it. And you have to revise it. And you 
have to be humble about it, too. Taking criticism on board in on of the hardest things from any writer.

But that's how it works.

Wesley Parish

> 
> But the guild/craftsmanship metaphor just doesn't work for me.
> 
>  - Dan C.
>  



"I have supposed that he who buys a Method means to learn it." - Ferdinand Sor,
Method for Guitar

"A verbal contract isn't worth the paper it's written on." -- Samuel Goldwyn

[TUHS] really Pottering vs UNIX

[Kurt H Maier]

On Thu, Sep 14, 2017 at 09:24:44PM -0400, Dan Cross wrote:
> 
> I think a better system than putting us into this rigid hierarchy system is
> to think of programming as somewhat analogous to writing; it requires
> proofreading and good editing. Some authors are better than others;
> practice helps a lot, writers workshops can help, seeking out advise and
> mentorship from more accomplished writers similarly, etc.

It's a good thing real engineers don't put themselves on these
pedestals.  We wouldn't have any bridges left.

I'm glad NCEES is making efforts to formalize 'software engineer' as a
class of PE; maybe in another hundred years or so I'll be able to
believe promises that programmers make.

khm

[TUHS] really Pottering vs UNIX

[Steve Johnson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1443 bytes --]



More to do with a sense for quality. Often developed through
experience
 (but not just that). I think what we need is a guild system for
 programmers/engineers. Being an apprentice of a master craftsman is
 essential for learning this "good taste" as you call it.

I guess I'm not so totally against guilds per se.  Since I believe
that programming (at least is a profession) is a service industry, I
think that doesn't come naturally to a lot of otherwise bright people
(including, I might add, me).  Back when I was writing FORTRAN, I was
working for a guy with very high standards who read my code and got me
to comment or, more usually, rewrite all the obscure things I did.
 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.  

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

Steve


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170914/3013a1fc/attachment.html>

[TUHS] really Pottering vs UNIX

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3224 bytes --]

below...

On Fri, Sep 15, 2017 at 1:42 AM, Steve Johnson <scj at yaccman.com> wrote:
>
>
> I guess I'm not so totally against guilds per se.
>
> ​Dan I hear you, but I think I agree with Steve here..​




>  Since I believe that programming (at least is a profession) is a service
> industry, I think that doesn't come naturally to a lot of otherwise bright
> people (including, I might add, me).
>
> ​Amen.. I think this is the key point, I was trying to make.  What I
called 'good taste' was being show examples.   Reading others code.
Thinking about a problem.    Think about simple, ugly CS problems and why
they are hard or ugly.  Your moral equiv of cleaning a few latrines.

​




>  Back when I was writing FORTRAN, I was working for a guy with very high
> standards who read my code and got me to comment or, more usually, rewrite
> all the obscure things I did.  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.
>
>  Amen
​ !!!   ​
I worked as an assembly programmer supporting TSS and York/APL when I first
broke in.
​  I had exactly the same experience.  Were as one of my friends did not.

I'll not name the person here because he's a good friend and many of you
know him.   But a one-time officemate of mine at start up and MIT grad​
were working on a system. And I was b*tching at him about something he had
written.   It was marvelous code, quite ingenious.   His comment was "Well
I only comment stuff I did not understand."


I look at him agast.   I said... "'Fred' you are on the smartest guys I
have ever known.  There is not much you don't understand.   Comment it for
us mortals please."

This was a lesson I was taught very early in my career (there are usually
spelling and grammar errors because of my dyslexia, but my comments are
usually parsable and understandable 40 years later - even by me).



>
> Maybe a guild is a bit too stuffy,
>
> ​Right - the image seems heavy weight, which is not what I intend.



> 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.
>
> ​Exactly!!!​

>
> I don't think I would have found this in a book or long midnight hours
> hacking away...
>
> ​And to those people that took the time to guide and teach me, I am
forever indebted. My hope is that I am able to pay them by helping the next
generation a small amount, and trying to keep their ideas and spirits alive
in those new programmers.  I hope the new programmers do continue to write
new things and extend the art, but as I said recognise, they do their work
the shoulders of some wonderful and great people starting with tools and
ideas that hopeful they understand they learned from those masters.

Only time will tell. ​


>
> Steve
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170915/c366af6a/attachment-0001.html>

[TUHS] really Pottering vs UNIX

[Chris Torek]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1494 bytes --]

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

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!

Chris

[TUHS] really Pottering vs UNIX

[Paul Winalski]

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

Mine, too.  In grad school in 1976 I learned Computer Science, not the
art of Software Engineering.  The latter I learned from my project
leaders and supervisors at my first job at DEC.

-Paul W.

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

[Toby Thain]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2118 bytes --]

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
> 

[TUHS] Maintainability, Guilds, RMS, etc. all lumped into one

[Jon Steinhart]

Well, here I go trying to be the voice of reason.  Not my natural state :-)

Can't see any good coming out of RMS bashing.  I'm one of those who thinks
that GNU/Linux is absurd; RMS had nothing to do with Linux.  I can imagine
that, like many of our peers, he has ego issues may feel slighted that Linus
gets more media attention than he does.  Maybe he would be happy if anything
built with GNU tools would append a tag line equivalent to the bandwidth-
wasting "sent from my iPhone" stuff on emails.  All that aside, he has had a
huge and positive influence with the GPL and by making many of the tools that
we all depend on available for free.  I remember that when I switched from
SunOS to Solaris that Sun started charging for the C compiler and I was very
happy to have gcc available.

I would claim that the issues of maintainability, guilds or other standards
for programmers, etc. is really a management issue.  And it's exacerbated by
what I have observed about management which is that it's not about managing
any more.  Since managers are theoretically responsible for programmers
sensible things don't happen when the managers are not competent.  Nothing
says it more than the Chief Security Officer at Equifax being a music major
with no relevant skills.  What could possibly go wrong?

Managers don't care about maintainability today, and I'm not sure that it
would matter if they did.  When I started working there was an expectation
that one would look after one's employer's interests and the employer would
look after yours.  That's pretty much gone for a number of reasons.  Few
programmers are going to worry about maintainability when they expect to
change jobs frequently.

As an aside, one of the reasons why I chose to work for myself is that I got
spoiled by having awesome management on my first job.  I remember Hank Macdonald
who I think was co-director of whatever branch of area 10 in which I was working
at BTL pulling up a chair next to me at 3AM one late night/early morning and
asking me how it was going.  I told him great except for some problems with
display flicker at which I was staring.  He thought about it for about 30 seconds
and said "I'll bet your delay constants are too big."  He was right.  I realized
that he was a director because he had mastered everything that everyone under him
was doing, not because he couldn't.  All other managers that I've had since were
Peter Principled.  Oh, and under Hank I had Joe Condon as a supervisor which was
another amazing experience.

When I went to work at Tektronix I had an expectation that I'd spend my entire
career there.  Of course, shortly after I started the technical founder was
replaced by an uneducated bean counter who looted the company.

But, I remember a day when someone who sat near me celebrated ER (engineering
release), which meant that his product went to manufacturing.  A day or two
later someone from manufacturing was sitting in the chair by his desk asking
questions.  This happened for a week or so and then that engineer's desk got
moved down into manufacturing.  I observed this and told myself that I would
never let that happen to me.

Another thing from Tek was that we supported products for ten years after ship.
That made maintainability and reliability important.  When someone makes a web
page component that's going to be around for a few months at best it's hard to
justify spending dollars on maintainability.

Final thing on this thread: get used to it.  As with any field, programming is
a commodity item now.  It's not a field populated primarily by people with PhDs.
Think about the number of baristas who were hired as programmers during the
.com boom.  And the "everybody must learn to code in high school" movement
is not about making more programmers like the ones on this list.  It's about
calling people programmers who don't even have the prerequisite skill of knowing
how to coffee drinks.  It's still a management problem because these people are
being hired to do jobs for which they really don't have the skill.  It's part
of the hollowing out of America; we still have great sounding names for a lot
of things that no longer really exist.

Fortunately for people like me, companies often get in serious trouble and need
someone who knows about bits and cycles and interrupts and propagation delay and
so on.  Good for the toy budget.

I'll illustrate this with an emergency job that I did a few years ago.  I was
hired to get something working with a hard 3 week deadline where the person who
had done the original work claimed that everything worked but it only worked
for him; nobody else could get it to work.  One of the things that I noticed
was that the absolute maximum electrical values on one of the parts was being
exceeded.  Mentioned it to the CTO who looked at it and told me that she had
looked at the circuit diagrams of the chips and wasn't worried.  I responded
with "I guess you've never worked at a company where you were responsible for
warranty repairs."  Turns out that she hadn't.  On the software side, I replaced
around 8,000 lines of undocumented code with about 300 lines including comments
and whitespace that did the job.  Probably less than 100 lines of actual code.
I see this over and over with the "we'll just import packages and make library
calls and call it programming" mentality.

BTW, it's not just software.  On this same project there was a problem internal
to the Atmel SOC.  Turns out that Atmel had just purchased a bunch of IP and
glued it together on the chip and even they didn't know the particular detail
that I needed.  Took several months of escalation to finally get it resolved.

Jon

[TUHS] Maintainability, Guilds, RMS, etc. all lumped into one

[Bakul Shah]

> On Sep 16, 2017, at 12:12 PM, Jon Steinhart <jon at fourwinds.com> wrote:
> 
> I would claim that the issues of maintainability, guilds or other standards
> for programmers, etc. is really a management issue.
...
> Final thing on this thread: get used to it.  As with any field, programming is
> a commodity item now.  It's not a field populated primarily by people with PhDs.

I think we can do a lot without requiring a PhD. Programming
may be a commodity but there is a need for introducing more
professionalism. Or "good habits" if not "good taste".

It is clear by now that in many cases software quality is no
less critical than the quality of work needed in building
critical physical infrastructure (which in turn is also now
affected by s/w quality!). Software has become quite pervasive
& pretty much everything seems hackable (in the break-in sense).
While security is a separate issue, at least we can try to not
make breaking in easy via buggy software.

I don't know what the solution is. I am leery of any
"professional programmer" kind of certification as being
sufficient. I don't think we even know what that should
entail. Schools already teach software but these graduates
don't seem prepared enough for the real world.

One thing that does help is mentoring. But we can't rely on
managers for that. Managers are like general contractors,
responsible for coordination and project delivery on time.
But while time to deliver is measurable, measuring quality is    
far more nebulous and in my experience this delivery on time 
goal almost always trumps delivering quality. Second, even a
good manager is simply not going to have time to train people
+ his bonus doesn't depend on that.

> Fortunately for people like me, companies often get in serious trouble and need
> someone who knows about bits and cycles and interrupts and propagation delay and
> so on.  Good for the toy budget.

I did this for 13 years. I enjoyed some aspects like solving
problems others failed at but overall fixing problems that
shouldn't have been created in the first place was rather
unsatisfying. I much preferred jobs where I had the freedom
to build things from scratch.

> BTW, it's not just software.  On this same project there was a problem internal
> to the Atmel SOC.  Turns out that Atmel had just purchased a bunch of IP and
> glued it together on the chip and even they didn't know the particular detail
> that I needed.  Took several months of escalation to finally get it resolved.

Reminds me of the an Intel processor I ran into once. They
wouldn't even admit the chip had a fault but after staring at
my client's code for a month that was the only thing that
made sense. The bug manifested only in a running system
involving a PC, client's hardware IO board, an IBM mainframe
and a phone system. So we flew down to client's customer
side, hooked up a logic analyzer on the PC bus, and within
15 minutes we had the trace proving the chip bug. Intel then
said, oh yeah, that problem is known and is on the errata list.

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

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2040 bytes --]

On Sat, Sep 16, 20
​ ​
17 at 2:05 PM, Toby Thain <toby at telegraphics.com.au> wrote:

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


​I hear you and I agree in so many ways but .. but its hard to get someone,
particularly some one young and eager to to see that value.​   This is why
I like to have them work side-by-side with my my senior folks.   And
everyone does maintenance - everyone working on the same project.   I'll
carefully pick something for them to do.   But some of my best and creative
work, has come from some of my most junior folks - because they did not
know it was hard.  That said, it's my job to keep a weather eye on them.

But I want the sr folks doing the maintenance work also.   Just like when
is a system programmer, I was required to be and system operator (the grunt
task - changing tapes, paper, answering questions) at least 4 hours a
week.  Why?   because it was incentive to make sure we had the procedures
right and easy.



Jon described the effect of putting everyone together at Bell Labs
(and Tektronix).  I admit, Jon and I were lucky.   We grew up in
environments were we got to working most anything, but we were next to pros
(if not geniuses).   But we knew them as people and colleagues and they
quietly taught us.  And I picked up 'good taste' by readying their code,
looking at their designs; have been comment on mine.  Having them show me
something...

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170918/1fae963c/attachment.html>

[TUHS] really Pottering vs UNIX

[Bakul Shah]

> On Sep 14, 2017, at 6:24 PM, Dan Cross <crossd at gmail.com> wrote:
> 
> I think a better system than putting us into this rigid hierarchy system is to think of programming as somewhat analogous to writing; it requires proofreading and good editing. Some authors are better than others; practice helps a lot, writers workshops can help, seeking out advise and mentorship from more accomplished writers similarly, etc.

I think programming has more in common with carpentry or some     
such construction related profession than writing. Often you   
work in collaboration with others (most writing is a lonely   
toil). The component you work on has to fit well with others'.  
Finishing on time and the cost of materials and labor matters.  
What you build is something people use over and over again and
reply on for shelter and comfort. The structural integrity of
your work matters. Overall architecture matters. Skill with
tools matter.  Understanding the material you work with and
where it is suitable matters. There is a lot more craft than 
creativity. While the highest form of writing is considered to
be creative writing.

You pointed out how the maser/apprentice relationship can be
abused but so can teacher/student, boss/employee etc. ones.
The point of a master/apprentice or mentor/mentee relationship
is ensure that the practical knowledge is passed on.  It is
what and how and why and under what conditions. And also what
not to do, etc. It is not just what the apprentice *wants*
to learn but also what he needs to learn. And learn by doing.

You mentioned proof reading and editing. Typically is no such
editing function in software. [You touch my code, you own it!]
We have code reviews by peers but these reviews tend to be too
low level. Everything must have a test but that still doesn't
help you write better structured software. 

Someone blamed open source for the poor quality of code.  But
I have seen far worse quality code used by companies.  In
one job they had two millions lines of C++ code. It seemed
they only did additive programming. Layers upon layers of
cruft. These programmers were intelligent but they didn't have
the knowledge or training or oversight or perhaps passion.

As a programmer for hire for many years I saw a lot more of
this. In one place the way they got a 'clean' compile of 
ported C code was by liberal use of casting. You can fool a
compiler but you can't fool runtime. And it wasn't even a 
difficult port. And debugging skills are in short supply.
Too many times no root cause analysis is done. Fixes in 
the wrong place. 

Things like agile programming and scrum and sprints -- not  
sure how well they work when it comes quality. 

What I am getting at is we have better languages and better
tooling but there is a critical need for better training.

> But the guild/craftsmanship metaphor just doesn't work for me.

The guild idea not going to fly in any case. Nobody has any
patience any more and egoless programming doesn't exist.
Not sure what will work.

[TUHS] really Pottering vs UNIX

[David]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2044 bytes --]

On Sep 15, 2017, at 1:32 AM, tuhs-request at minnie.tuhs.org wrote:
> 
> From: "Steve Johnson" <scj at yaccman.com>
> To: "Dan Cross" <crossd at gmail.com>, "Bakul Shah" <bakul at bitblocks.com>
> Cc: "TUHS main list" <tuhs at minnie.tuhs.org>
> Subject: Re: [TUHS] really Pottering vs UNIX
> Message-ID:
> 	<d92047c5a36c6e72bd694322acb4ff33e3835f9f at webmail.yaccman.com>
> Content-Type: text/plain; charset="utf-8"
> 
> 
> 
> More to do with a sense for quality. Often developed through
> experience
> (but not just that). I think what we need is a guild system for
> programmers/engineers. Being an apprentice of a master craftsman is
> essential for learning this "good taste" as you call it.
> 
> Back when I was writing FORTRAN, I was
> working for a guy with very high standards who read my code and got me
> to comment or, more usually, rewrite all the obscure things I did.
>  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.  
> 

When I taught at UCSD I always made it a point to inform the students
that the person who will be maintaining their programs in the future will
all be reformed axe murderers. These nice folks learned C (at the time)
on MS-DOS 3.1 and weren’t as homicidal as they used to be. They would
however be given your home address and phone number in case they
had questions about your code.

It was always good for a laugh and I went on to explain how code outlives
the author and so you should take care to make it easy for someone else
to work on your code.

The other thing I did was to have students give their programs half
way through the project to a randomly chosen (by me) other student.
They were not allowed to assist the recipient and grades were based
on how well the final program met the requirements given at the beginning
of the project. Code quality went way up on the second project compared
to the first.

	David

[TUHS] really Pottering vs UNIX

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1688 bytes --]

On Sat, Sep 16, 2017 at 4:09 PM, David <david at kdbarto.org> wrote:

>
> The other thing I did was to have students give their programs half
> way through the project to a randomly chosen (by me) other student.
> They were not allowed to assist the recipient and grades were based
> on how well the final program met the requirements given at the beginning
> of the project. Code quality went way up on the second project compared
> to the first.

​CMU used to have a required SW engineering course that did that.   It was
the 3rd course required after Data Structures and before Compilers, OS or
anything 'large.'  It was a Mary Shaw innovation.   I always thought it
was brilliant.   The CMU course assumed you worked in 3-4 person teams and
at least two transfers were done over the course of the semester.   Your
team was not allowed to replace whole sections of code.   If you thought
your team got screwed somehow, you could appeal to the TA, who could chose
to give you a different group's code yet; but could not use you own last
version.

CMU stopped teaching the course a few years ago - I gather it was really
tough to admin - students always b*tched about, but they did learn a lot of
practical stuff.   But when I took it, I thought it was one of the best
courses I had as an undergrad in ~75 (we build an airline reservation
system in Algol).   It was my first exposer to source control, peer review,
excellence in commenting, full documentation, etc.. -- so many ideas that I
so take for granted.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170918/930e05dc/attachment.html>

[TUHS] really Pottering vs UNIX

[David]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2222 bytes --]


> On Sep 18, 2017, at 7:17 AM, Clem Cole <clemc at ccc.com> wrote:
> 
> 
> 
> On Sat, Sep 16, 2017 at 4:09 PM, David <david at kdbarto.org> wrote:
> 
> The other thing I did was to have students give their programs half
> way through the project to a randomly chosen (by me) other student.
> They were not allowed to assist the recipient and grades were based
> on how well the final program met the requirements given at the beginning
> of the project. Code quality went way up on the second project compared
> to the first.
> ​CMU used to have a required SW engineering course that did that.   It was the 3rd course required after Data Structures and before Compilers, OS or anything 'large.'  It was a Mary Shaw innovation.   I always thought it was brilliant.   The CMU course assumed you worked in 3-4 person teams and at least two transfers were done over the course of the semester.   Your team was not allowed to replace whole sections of code.   If you thought your team got screwed somehow, you could appeal to the TA, who could chose to give you a different group's code yet; but could not use you own last version.
> 
> CMU stopped teaching the course a few years ago - I gather it was really tough to admin - students always b*tched about, but they did learn a lot of practical stuff.   But when I took it, I thought it was one of the best courses I had as an undergrad in ~75 (we build an airline reservation system in Algol).   It was my first exposer to source control, peer review, excellence in commenting, full documentation, etc.. -- so many ideas that I so take for granted.
> 
> Clem

I learned a lot myself by teaching the class in this way. One was that
some students didn’t need to be concerned about anything; they could
take almost any code and make it right. And at the other end were students
who, given any pre-existing code would never be able to make heads or
tails of it, regardless of the original quality of the code.

Still, I think that at the end everyone in the class came out ahead because
they understood that programming was never going to be a go it alone
proposition, you either started something you never finished or got to finish
something you didn’t start.

	David