On Mon, Jul 21, 2025 at 10:24 AM Paul Winalski <paul.winalski(a)gmail.com>
wrote:
.. that is why I've always considered the
comments to be an integral
part of the code, and when doing code reviews I've refused to approve code
changes where the comments are too sparse or where the comments don't match
the code.
Amen.
I've mentioned this to Paul before, but Mary Shaw's trick from the old CMU
sophomore software engineering course was spot on. You were 3-4 person
teams, and the entire class was working on the same project [when I took
it, we were building an airline ticketing and equipment reservation
system]. The first part required each team to write a specification for
the project (which was collected and compared/graded against one that TAs
had written). Then the TA gave everyone their "common" spec, which
your team started to program for the first part of their spec. Then, two
weeks later, the TA handed over your codebase to another team (and you were
given the code from another team still). This process was repeated over
the 12 weeks, 4 or 5 times as each part of the project was completed.
You were not allowed to use your code base; instead, you had to build on
the base provided by the TA for each section. [There was an escape clause
of going to the TA if the code you got was a disaster, but then you got a
different group's code, and you just lost time working on the earlier
version - so it was easier/faster to fix any bugs you found].
People never wanted to be cursed by their classmates. The first thing you
always did was do a code review and then run both the tests you had been
given and your own against the base to see what you had. As a result, the
students learned to write code that was clean, well-tested, and properly
commented and documented, because their peers would be reviewing and
depending on it. If you were serious, you certainly did not want to get a
reputation for writing crap.
The sad part is that I believe CMU discontinued that course a few years
ago, because the graduate student TAs hated it. It could be a tremendous
amount of work for them.
BTW: IIRC that course was when I had a future Turning Award winner as well
as someone else who would make a name in the Multics community as
programming partners.
Clem