By Sanjay Manohar, University of Oxford, and Software Sustainability Institute fellow
When you try to distil years of experience into words, something is always lost. How can you convey the basic principles of a practical art in a seminar? Teaching coders how to code well is challenging because each person starts with a different set of experiences, a different skill set, and a different end goal in their programming journey. Yet there is something that brings them all together: a passion to improve their code to broaden the set of techniques they have in their toolbox.
As a teacher, it is crucial to remain aware of what students do and do not understand yet. A set of assessment techniques is part of the armament of every educator and allows the use of the most appropriate level of language, criticism and sophistication. These formative tools also give students the feedback they need to see their own limitations and measure themselves against.
On 10th April 2017, I held a seminar on good coding practice for neuroscientists. It was at the British Neuroscience Association Festival of Neuroscience, a national meeting involving neuroscientists of every kind from around the country. In a small seminar room in the convention centre, forty excitable scientists crowded in to learn about best practices for writing neuroscience software.
It has been the culmination of five years of work, during which I have designed and taught good coding at UCL and the University of Oxford. My style has evolved dramatically over the years, starting with grey lectures and flat lists of bullet points. It gradually dawned on me that this was no way to communicate something as deep and intuitive as good coding practices. Slowly I realised that I had to get students to think for themselves, to get them excited, inflamed, and have their own opinions. As I grew as a teacher, I adopted a number of standard teaching techniques, such as Classroom Assessment Techniques, as part of the lectures. And within a couple of years, the lectures were transformed into an interactive and hopefully engaging workshop-style seminar.
For example, I get students to have a short debate about a simple coding decision. They introduce themselves, and begin to discuss their views. Within a few minutes, the room explodes in conversations, arguments, opinions—and with some executive power—I bring the discussion together to arrive at a balanced view. Compare this to the older version of the lecture, where I used to show a black-and-white slide listing the points! The discussion now focuses the needs of the people in the room, matching their level of experience and programming goals. Each person has a chance to contribute and tailor the learning experience to their needs. And each time I give the seminar, it is different!
One of the features of my seminar is that programmers in any language can attend. Many neuroscientists work in MATLAB, R and Python, but I do not assume any particular language in the discussion, which is mainly conducted at a conceptual level. I draw examples from both MATLAB and Python where needed, but all principles are supposed to be applicable across the board. Many people are interested in efficiency and economical coding—how can that be taught without assuming a language? In neuroscience, we are lucky because much of our work involves manipulation of large arrays. And this, it turns out, is remarkably similar in all these languages. I introduce students to some concepts from functional programming, and an approach to parallelisation, which is new to many of them. These concepts mesh into array manipulations to give students power, efficiency and economy.
My unique combination of providing a language-agnostic conceptual framework, and facilitating a lively vehement discussion about best practices, has been a winner so far. It fits perfectly with an educational philosophy that advocates deep learning (as opposed to superficial learning) and building student passion and enthusiasm for writing the best possible code. It aims to provides not only a set of conceptual techniques but also a heuristic base for when to use those techniques. Good coding, for me, is both phronesis and art, but imparting it to others may also be.