17 Sep
2017
17 Sep
'17
2:09 a.m.
On Sep 15, 2017, at 1:32 AM, tuhs-request(a)minnie.tuhs.org wrote:
From: "Steve Johnson" <scj(a)yaccman.com>
To: "Dan Cross" <crossd(a)gmail.com>, "Bakul Shah"
<bakul(a)bitblocks.com>
Cc: "TUHS main list" <tuhs(a)minnie.tuhs.org>
Subject: Re: [TUHS] really Pottering vs UNIX
Message-ID:
<d92047c5a36c6e72bd694322acb4ff33e3835f9f(a)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
18 Sep
18 Sep
8:17 p.m.
On Sat, Sep 16, 2017 at 4:09 PM, David <david(a)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
8:23 p.m.
On Sep 18, 2017, at 7:17 AM, Clem Cole
<clemc(a)ccc.com> wrote:
On Sat, Sep 16, 2017 at 4:09 PM, David <david(a)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
2652
days inactive
2654
days old
2 comments
2 participants
participants (2)
-
Clem Cole -
David