[TUHS] really Pottering vs UNIX

[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

[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] 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

[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

[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

[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

[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

[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

[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

[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

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