Re: [tlug] New programming revision site - by a TLUG'er

["Stephen J. Turnbull" <stephen@example.com>]

黒鉄章 writes:

 > I appreciate you're pointing out the general case about employment
 > but that's getting off-topic.

Off your topic, yes, but once you post to a list you don't own the
topic any more.

 > Can I get a more concise view on whether or not programming
 > language revision on a spaced repetition intervals is going to be
 > worthwhile or not for a non-neglible population of programmers?

What do you mean by "a spaced repetition intervals"?  If you are
referring to the "programmed instruction" nature of your quiz, getting
a new short question every few seconds, sure, it's probably somewhat
helpful.  If you're talking about "you might want to do a quiz every
couple of months," I'd say "almost certainly not, what you want to do
is take the appropriate quiz(zes) several times in the two weeks
before a qualification test or job interview".

The thing is that, as we've all agreed, there are two reasons for
knowing stuff.  (1) Getting the job.  (2) Doing the job.  For getting
the job, you want to know random details to impress the interviewer.
(If a good interviewer, she'll be looking for fluency, not details,
but as we've agreed, knowing details is an important component in
fluency, and at the level of programmer you claim to be, it's the
dominant component that can be easily improved.)  So this kind of
revision[sic - is that Australian for what Americans would call
"review"?] before a job interview is probably useful, although I'm not
sure how much it will contribute to fluency.  People should try it and
see.

For doing the job, other things are much more important than random
details, because the job will teach what details you need to know in
your daily work.  (And if you don't learn by doing quickly, you
probably ought to be thinking about a different career.)  If you
encounter a new problem that you don't have a pattern for, you'll be
hitting the books anyway, so looking up new syntax etc isn't a big
deal at that time.

An important issue here is that I suspect that the current questions
are kind of a checklist of syntax you personally have had to look up
recently.  That's especially effective for you (that's a good thing,
see below), but it looks kind of random from the point of other
programmers, most likely.

Watts Humphreys (_A Discipline for Software Engineering_,
_Introduction to the Personal Software Process_, highly recommended)
recommends a detailed process.  One part of that process is recording
your bugs, which he breaks down to quite a detailed level for the
generic template, and he proceeds to recommend that you evolve even
more detailed personal templates.  Many people have trouble with
forgetting semicolons in C, many others have none, for example.  If
you don't have (much) trouble with semicolons, then in your personal
form you should aggregate that kind of bug with similar bugs (or into
the "misc syntax errors" bug type).  If you do, you should consider
breaking down the "semicolon error" class according to the kinds of
mistake (omitting the semicolon before "then", omitting the semicolon
for an empty statement, inserting a bogus semicolon in some particular
syntax, ...).  The point is that he makes this recommendation *because
in his experience as an engineering process consultant, people have
different bugs in their thinking about a language's syntax*.

This suggests that (1) users should be able to customize the
likelihood of certain kinds of questions to concentrate quizzes on
personal problem areas or work needs, (2) recording *per-question*
results for a user is a good idea (I didn't check to see whether you
did that), so that they can see *what* they have and have not learned
from the process, not merely if they've learned *anything*, and (3)
automatically increasing the likelihood of questions that were missed
in the past might be useful.

 > (Actually what I was mostly hoping for was comments about the
 > interface and bug reports.)

The "browse questions" feature is a nice touch.  I didn't use it, but
just having the option was appreciated.

In the SQL question about "quantification", the last two answers were
identical AFAICS.

Regarding interface, lots of suggestions, involving lots of work. :-)

You *may* want to consider restricting "nice touches" to logged-in
users to encourage registration.

To make logging in and registration easier, how about supporting OpenID?

There are established proficiency tests for C++ at least; you might be
doing your users a service if you point them at those tests.  I don't
know if any are free/net-based.  A separate "kuchikomi" page about the
value of such tests would be entertaining for sure and probably
useful.  In fact the pointers could be kuchikomi too, then you don't
have to search for them.

I found the terse "Wrong" off-putting.  I expected an explanation of
what was right and preferably why the wrong answer(s) are wrong.  You
personally needn't provide explanations, other editors can do that,
but if there isn't one, a "Sorry, no explanation yet.  Would you like
to provide one (as much as you know)?" message could be automatically
generated.  The explanation could provide a button linking to the Edit
Explanation form (always present; the explanation might be incorrect
or incomplete even if present).  If the user isn't logged-in, the
button would link to the login/register form instead.

Displaying an explanation if available probably should be a user
option.  There could be a global option with values "always", "when
mistakes are present", and "never", and a per-question hide/show
explanation toggle (available only after answering, I think).

Do you have any "fuzz" questions?  Ie, taking off on the semicolon
discussion above, for C++ you could have a 5-7 line block.  Then
*randomly* insert or remove 0-2 semicolons.  (The UI for answering is
not going to be easy, I suspect, but it would be cool if you can come
up with a good one.)

The nested if question suggested a similar unconventional fuzzable
question: reindent this block with the usual conventions.  Again, good
UI is nontrivial, but I think it's possible.  Eg, in C/C++ the three
main variables in style are where to place braces, how many columns
are taken by one level of indentation, and whether braces are used for
single statements.  If you always provide syntactically correct
braces and simply count levels of indentation, not columns, then a
tabular form like

Reindent line | to level
--------------+---------
              |
--------------+---------
[add line to reindent]

could be used to collect the answers.  The question would be composed
by more or less randomly reindenting 0-2 lines of 5-7 incorrectly.

Recording per-user versions and answers to "fuzz" questions might be
non-trivial.