Computer Workshops

Computer Workshops

Many courses in the School of Mathematics include computer labs, from Y1 to PGT. Most of these are programming labs, typically Python or R labs (with some exceptions).

The guidance given for tutoring workshops also applies for tutoring computer labs. This section is intended to provide additional advice pertaining specifically to computing and programming.

Computing labs in the School

Most computer labs function like pen-and-paper workshops: students spend the time working independently on practice exercises or a particular task, sometimes assessed. As in a workshop, they have the opportunity to work actively on computing problems, to discuss with their classmates and tutors to develop their understanding, and to get immediate feedback and help from peers and tutors.

In a “traditional” computer lab room, each student sits at a station; often groups of 2-3 students sit near each other and work together. Labs can also be held in workshop rooms, with students sitting in small groups and working on their laptops, sometimes using the large monitors at the table to work together. Tutors usually walk around the room, check in on students’ progress, and offer help when needed.

There is perhaps less of a “unified” model for computing labs in the School, as different courses have different learning outcomes related to computing. For instance, some courses introduce a new programming language, in which case the computing labs (and the type of issues students will encounter) will likely centre around developing programming skills (in a mathematical context). Other courses, usually Honours or PGT, assume previous knowledge of a language or software, and the labs are therefore more likely to centre around problem-solving skills and mathematical applications.

In any case, the Course Organiser should provide a briefing at the start of the semester to clarify:

• the aims of the computer labs for the course, the learning outcomes for that course related to computing;
• the software and/or services students are expected to use, e.g. a particular IDE, a cloud computing service, computational notebooks, etc.;
• the type of task students will work on during the labs, and whether it is assessed;
• if/how students are expected to collaborate (e.g. casual discussion with neighbours, well-defined group with different roles for each group member…);
• the expectations for marking and feedback for computing work.

Preparation

As for workshops, we should prepare before a computing lab. The Course Organiser will normally provide the task and solutions in advance; however, it’s a good idea to attempt the task without consulting the solutions first. Beyond making ourselves familiar with the exercise, this is also a good way to anticipate the difficulties or misunderstandings that most students are likely to encounter during the workshop. For instance, if you find yourself consulting the documentation to find a function, a particular section in the lecture notes, or a method or snippet used in a previous exercise, make a note of this; it will likely become a useful pointer to suggest to a student who gets stuck.

During the computer labs

During the labs, our job as tutors is to support students in developing their computing and/or problem-solving skills. Again, the general advice given for workshops applies: encourage students to ask lots of questions and explain their thinking to you and to each other, avoid spelling out the solution for them, and give suggestions and pointers to the course material (and other relevant resources, e.g. software or language documentation) to help.

Troubleshooting and debugging

Many problems students will encounter during a programming lab are essentially bugs – programming mistakes which can make a program exit with an error, or produce an incorrect result.

However, tutoring is not debugging! In that situation, our job as tutors is to support the student in locating the problem, understanding the error, and correcting the code themselves. Troubleshooting and debugging is a very important skill for students to develop, so that they can get themselves out of trouble and fix their own issues independently later on; computer labs are a crucial place to support them in developing these skills.

A good rule of thumb when helping students in the lab is to avoid taking over the student’s keyboard. There really shouldn’t be a need for tutors to touch a keyboard during a lab. If we’re not sure ourselves what the problem is, we should debug it together with the student, but let them type and navigate their own workspace.

Here are some practical things we can do to help students develop their troubleshooting skills:

• Ask the student to explain their thinking, if they have an idea where the problem could be, what they have tried so far. Take it from there to make further suggestions – meet them where they are.
• Encourage them to print (display) values at key places. For example, if a value is supposed to be updated in a loop but the end result is not as expected, suggest to add print commands before and after the line which performs the update, to display the value and check whether it is indeed updated correctly. This is a quick-and-easy way to inspect code without having to know how to use a debugger.
• Plots and other visualisations can also be used at intermediate steps for debugging when appropriate.
• Show students how to search, navigate, and understand documentation. For example, when a student encounters an error when calling a library function, even if you already know what the problem is, encourage them to search the documentation entry for the function, instead of pointing out the problem straight away.
• Sometimes the documentation is not enough; it’s OK to ask students to look things up with their favourite seach engine – we do this all the time ourselves. When doing this, it’s useful to remind students that most code found in search engine results (mainly this will be from StackOverflow, blog posts, etc.) is not held up to the same standard as the official documentation, and to take it with a large grain of salt. If students use a snippet found on a website, encourage them to keep a note of at least the URL in their code comments, for their own reference as well as to avoid plagiarism (particularly crucial in assessment!).
• If we are stumped ourselves, don’t hesitate to ask another tutor in the room to come help with troubleshooting (or even another student, depending on circumstances). This also shows students that everyone can get stuck every now and then!

Runtime errors

Particularly for novice programmers, runtime errors can look scary, and error traces impenetrable. A good message to communicate to students is that error messages are here to help; decrypting these is the first step in locating and understanding the error. Asking questions about the error message is a good way to start guiding a student through the debugging process – for instance:

• “What type of error is this? What do you think this means?”
• “Do you remember seeing an error like this before? In what context?”
• “Where/which line does the message say that there is an error?”
• etc.

As we uncover more details about the error, we can ask more specific questions (e.g. where did you define this variable, how many input arguments does this function normally take & how can we find out, etc.). The general idea is that we want to build students’ confidence in decrypting error messages and using the information to debug their code by themselves (“teach a man to fish”). Doing it ourselves for them means that they miss out on developing these important skills, and can reinforce the misconception that one needs to be an “expert” with obscure specialist knowledge to understand error traces and debug code.

Logic or structure errors

For issues with logic or structure, where the program runs but produces the wrong result, a concrete strategy which works surprisingly often is rubber duck debugging, where the tutor plays the role of the rubber duck. Ask the student to explain to you what their program does, line-by-line, in as much detail as is necessary. In all likelihood, they will realise at some point that their code does not, in fact, do what they intended to do.

This is not only a great debugging method, it also helps students to develop their program comprehension skills, by explaining the structure of their code (see Useful resources below). Tutors can also provide useful information and guidance at various points if students get stuck, to help them bridging gaps. Again, computing labs are a learning environment, not just a debugging session.

Problem-solving issues

Another common issue faced by Mathematics students, particularly those relatively new to computing, is often flagged with a comment along the lines of “I don’t know where to start”. We might see a student faced with a statistics or mathematics problem, with some understanding of the premise, and their hands on the keyboard, ready to type code – but stuck.

Many students at first see mathematics and computing as two separate entities, and don’t expect to be using pen-and-paper during a computer lab. It’s important to remind them that computing is first and foremost a tool they can use to solve problems. In the same way that they learned in school to translate a “word problem” into a mathematical equation, to finally solve the equation and obtain the result, they now must learn to start from a mathematics or statistics problem, and work out a structured procedure to find the solution, to finally implement and run this procedure on a computer to obtain the result. Designing the procedure is the difficult part – it’s a skill that needs practice.

Again, a good strategy is to ask questions to get the student to explain and break down the problem; when working in groups, we can also prompt other students to explain their thinking to each other. In any case, encourage students to use pen-and-paper to work out simple examples, compute a few iterations by hand, sketch out diagrams, etc., before even thinking about typing code. Computing educators at Duke University have developed a Seven Steps method to follow for computational problem-solving, which is a great resource for students, as well as a useful guide for us to help them.

Useful resources

• The Seven Steps method: poster (linked above) and accompanying paper with further details.
• The Teach Computing project has a good collection of resources for computing pedagogy. These are mostly designed with school pupils in mind, but are still incredibly useful, particularly to support novice programmers. Highlights include the “Pedagogy quick reads” on code tracing and the block model to support program comprehension. These suggest activities and questions we can ask students to help them explain and understand how a program works, by essentially breaking it down into smaller parts.
• By the same organisation, the Teach Computing podcast often discusses broader topics and challenges in teaching computing, e.g. inclusion and accessibility, cognitive load, peer instruction…
• Brown, N., & Wilson, G. (2018). Ten quick tips for teaching programming. PLoS computational biology, 14(4), e1006023. https://doi.org/10.1371/journal.pcbi.1006023
• The Computing Education Research Blog by Prof. Mark Guzdial at the University of Michigan is an extensive resource from a leading researcher in computing education.
• Software Carpentry provides all their course materials under a Creative Commons license, including their instructor training material. This includes lots of evidence-based, practical advice on supporting students in learning computing, including discussions about learning and cognitive development, how to foster an inclusive and positive learning environment, etc.
• Software Carpentry also hosts a blog with, amongst other topics, a good number of posts about teaching.