[Tutor] Debugging skills

[dn]

Prefacing these remarks with the comment that I don't (currently) teach 
Python-from-scratch, nor for that matter, procedural coding from-scratch 
(and why would I, given the wide-availability of materials?).

Many of the issues-raised and under-lying themes, apply at a variety of 
'levels' of learning...


On 3/01/24 12:56, Mats Wichmann wrote:
> On 1/2/24 16:27, Alan Gauld via Tutor wrote:
>> On 02/01/2024 22:30, ThreeBlindQuarks via Tutor wrote:
>>> ...the best gift for some learners is learning debugging skills.
>>
>> Interestingly the paper book version of my tutorial has a chapter on
>> debugging. However, I've never got round to adding that chapter
>> to the online version. I probably should...
> 
> That would be cool.

+1


> I think the topic of which debugging technique to choose is quite 
> interesting.  Inserting prints, logging events, adding decorators which 
> emit useful information, actual debuggers - both the quite basic pdb and 
> some more advanced variants, various sorts of profiling and other 
> external inspection, and... test-driven-development is really a kind of 
> debugging technique: you write a failing test, and then work until you 
> can get the test to pass, that's really another form of debugging, as 
> long as you keep the unit of test simple enough that you don't just go 
> "I wrote the code, and I have no idea why it's failing my test". There's 
> probably more things that I didn't call out explicitly. Different 
> approaches are usually needed for differing situations.

The over-bearing issue (in both senses) is that starting-from-scratch 
presents a significant 'learning-curve'. The challenge with any 
(properly-structured) course is less 'what to teach' but how to control 
the learning into manageable 'chunks'.

I think we've previously discussed or touched-on the question of 
choosing an editor (quite aside from the 'real men use NotePad' meme). 
Do we recommend neophytes start with a simple tool which does not add 
significantly to the cognitive-load; or should we 'start as we mean to 
go on' with a professional-level tool, eg PyCharm; and save 'extra 
effort' later?

This ties-in with the above discussion because a casual look-around 
reveals very few courses or books which start-off in the Python REPL 
despite its characteristics of immediate-feedback and (better) 
line-by-line (syntax) error-revelation. (cf its impermanence!) Yet, the 
REPL is such a useful go-to tool to track-down issues, as illustrated in 
the OP (and so-frequently making Tutor responses more difficult than 
they need-be). Perhaps, those of use with experience of 
compiled-languages can more readily appreciate these advantages? 
(whereas to quote Joni Mitchell, others don't know what they've got 'til 
it's gone?)

Which led me to wonder if an intro-level session might eschew a 
local-editor altogether. There are a number of REPL-its, Fiddles, 
"on-line compilers" (sic), all the way 'up' to full-fat on-line IDEs, eg 
PythonAnywhere and Cloud9. They all save the hassles of an installation 
step (and the inevitable consequent question from mystified MS-Win 
users). Yet this is not the real-topic!


At this point I'd like to digress to mention another phenomenon which we 
(in this discussion) have to consciously stop to consider: when we 
learned 'software' back in the ?good old days, there was also a 
fair-amount of parallel instruction in 'hardware'. I recall building 
circuits with microprocessors and learning about "registers" cf stacks, 
interactions between memory and ALUs, and so-on. Today's learner seldom 
enjoys such a more-rounded background - and many courses eschew same 
simply to 'make progress' or because of a perception that it is "not 
necessary" (ref: OP-comments about "jump ahead").

Similarly, back-then, many came from a math-background. Accordingly, 
once the assignment-operator was 'disconnected' from the mathematical 
"equals", learning something like FORTRAN or BASIC was much closer to an 
exercise in mechanisation than learning something 'new'. Again, today's 
learners seldom 'enter' through that portal and often struggle with the 
concepts behind 'a variable is like an algebraic quantity' in the way it 
"stands for" a value - which may change. Change? Huh? My name doesn't 
change, why do these 'names' have different values/meanings???

Accordingly, I wondered if one could commence training with Phil Guo's 
excellent PythonTutor? This combination of text-expressed code, 
graphical representation, and the opportunity to limit execution to its 
line-by-line progression, neatly attacks many of the issues and concerns 
raised.

(to 'close the circle', if an installation-step is not regarded as an 
over-large potential pot-hole, consider Thonny - the "Python IDE for 
beginners", which also offers the above advantages)


The impatience of learners has always been a factor. We have a 'new 
generation' of folk who have the idea to 'get into' AI. Rather than 
Python being seen as a tool, some even have the idea that learning 
Python 'first' is an unnecessary block to their goal and want to learn 
'just the basics' and move-on. Sadly, many (training colleagues) have 
caved-in to the idea that 'the customer is always right'; and the 
over-sold enthusiasm of many a YouTuber who offers 'training' which 
depends on (their) plethora of assumptions (chief amongst which is that 
nothing will ever go-wrong - hence instructions commencing with 
"simply...").

Even basic psychological research reveals the fallacy of "students are 
the best judges of what [they need to] know" (in both present and future 
tenses!), eg Kruger and Dunning. This has even been used by an 
idiot-politician attempting to avoid questioning and the use of 
actual-facts (to justify what became a futile and fatal endeavor).


That said, the most important aspect of training is to encourage rather 
than discourage. Thus, curiosity (all too rare) is to be kindled (and 
directed), yet enactment kept achievable!

This is where the 'project approach', which certainly has virtue, "such 
as an online list of programming exercises that are not really designed 
as a teaching experience where each section extends what has already 
been learned." [OP] is a faint-hope or a 'silver bullet', and not a 
'fast-track' to 'real programming' (whatever that is?). It is the 
combination of a good understanding (which comes from a designed 
curriculum) and practical proof of learning ("mastery") which leads to 
long-term success.

There have been many trainees who have tackled an early-challenge of 
writing code to convert temperature between Fahrenheit and Celsius 
(Centigrade). It's a further step of meta-cognition to realise that 
once-solved, the techniques-learned can be applied to similar problems, 
eg converting between financial-currencies, or between metric and 
'imperial' measures. (the same psychology powering the idea of 
'programming patterns'!). Accordingly, unless 'made' to stop and think, 
many trainees will solve that little assignment and then want to move-on 
quickly - without realising the wider picture.

Similarly, the process of breaking things down, or building them up 
("step-wise refinement" - learned by many of us at the feet of Niklaus 
Wirth's books, RiP!) is not an obvious problem-solving approach to many 
(inside or outside of IT). Accordingly, a need to train - but when? 
(before writing any code/I just want to get on with it; or after 
trainees get themselves into a jam/"why didn't you explain this to begin 
with?"). Hind-sight is such a wonderful thing! However, in all cases, 
such 'received wisdom' is built upon 'learning' - and the cost/value of 
that learning is seldom factored into such debate/criticism!


There are numbers of web-pages which advise 'how to post' or 'how to 
express your question', but 'the bottom line' is that very few read them 
- and even fewer BEFORE their first post. We see this in training 
courses, with all aspects of 'admin' - trainees prefer to skip such 
'fluff' (polite re-wording) because they just want to 'get on with it'.

Few trainees have been introduced to the 'rubber duck'. Consequently, we 
face questions which can't be answered without further questions - 
which, in-turn, often causes the OP to grumble. However, if unable to 
coherently ask questions of humans, how do such questioners expect to be 
able to communicate with a (pedantic) machine? Back to the theme: How 
many accelerated code-camp style courses or 'simply...' YouTube series, 
include 'soft skills' in their content?

When post-ers fail to follow-up, but persist in asking similar 
questions, ignoring advice, the easiest course is to copy-paste. 
Alternately, because we (on this list) are all volunteers, ignore them - 
we all have better uses for our time (a tactic not available when I'm 
at-work!).


My research-area encompasses the high drop-out rate from Internet-based 
courses (actually, any "distance course" short of legal-compulsion, eg 
Australia's historic "School of the air"). Accordingly, I've not 
looked-at a slightly-similar concern: the many people 'start' in 
IT/programming but quit-the-business within a few years. Why does this 
happen? Unreasonable demands and 'stress' are obvious factors. I wonder 
if the type (and depth) of training somehow contributes? Have you looked 
at this end of things?
(hah! ,,, couldn't resist the pun)



Web.Refs
Tool: https://pythontutor.com/
Paper for Tutor-consideration: articles/java-visualizer.html
Thonny: https://thonny.org/
Known unknowns: https://en.wikipedia.org/wiki/There_are_unknown_unknowns
A reasonably-readable article: 
https://www.learning-mind.com/known-unknowns-unknown-unknowns/
Rubber-ducking: https://en.wikipedia.org/wiki/Rubber_duck_debugging

-- 
Regards,
=dn