Psychology of Programming Interest Group : work in progress meeting: Day 2
Tuesday, 10 Feb 2015, 10:31
Visible to anyone in the world
Edited by Christopher Douce, Monday, 10 Jul 2023, 16:43
Teaching programming at a distance
The first presentation of the second day was by yours truly. I gave a short talk about a university funded project that aims to understand more about the teaching experience of Open University associate lecturers who are tutoring on the TT284 Web Technologies module.
One of the purposes of the project was to understand issues particular to the learning (and teaching) of programming. An area of particular interest is the transition between the first level modules (which use some visual programming language) to the second level modules which require students to pay more attention to other issues, such as language syntax.
I wasn’t able to present any firm findings at this stage (since I keep getting sucked into the idiosyncrasies of my day job), except that three themes that were emerging were that some students can struggle with understanding what PHP is and how it works, confusion about Javascript, and the perpetual battle to understand regular expressions (which is, I believe, an issue that pretty all developers, expert or novice, seem to have)
The question and answer session was interesting. There was some chat about a coding DoJos (group coding sessions), the use of MOOCs (FutureLearn and the Kahn Academy), and how get students talking to each other.
Holistic programming teaching at Middlesex
Franco Raimondi’s talk was rather different to all the others: he showed us some robots (real hardware!) that he used in his teaching. They had an interesting design, using both Raspberry Pi devices that were connected to Arduino microcontrollers.
One question was: why use both? The Arduinos are used to control analogue input, but the heart of the control is managed (as far as can understand it) by the Raspberry Pi devices. Students then have the challenge of how to design and implement a communication protocol between the Pi and the sub-component. I personally think this is a great approach: students are exposed to different devices and learn more about their purpose. When I had a job in industry, one thing that I had to do is figure out how to get one embedded controller talking to another: Franco’s robots would have helped me a lot to figure out how to do this. More information about the robots can be found by taking a look at the MIddlesex Robotic plaTfOrm: MIRTO website.
Okay, so there is an interesting robot, but how are they used in practice? Franco described a series of lectures, design workshops, programming workshops and physical computing workshops. In the workshops (if my notes are correct!) students are asked to solve different problems, such as to write a line following algorithm where the robot has to cater for 90 degree turns, and to complete different line circuits as fast as possible. Students could also implement control algorithms, such as PID controllers (Wikipedia) (which again takes me back to the days when I worked in industry for a while), remote control and managing the taking of cameras by controlling the Raspberry Pi.
What I found really interesting was that the platform (and the workshops) made use of a programming language called Racket (Wikipedia). Racket is a language that I had not heard of before, but apparently it has roots in the Lisp language. In some respects, I commend the choice (because it’s great to expose students to different programming paradigms), but on the other hand, there is something to be said for getting to grips with tools that are used in industry. I guess this just goes to show that whenever you come along to workshop like these, you always learn new stuff.
Towards the end of Franco’s session, he spoke about a system to record Student Observable Behaviours, which then led onto a discussion about learning objectives. Apparently, the use of ‘observable student behaviours’ is something that Middlesex use, perhaps as a part of their assessment strategy. We were shown a web-based tool that lecturers can use to gather evidence of student engagement and activity.
I don’t know what this relates to, but I also made a note of a place called The Crystal (Crystal website), which was also described as the Siemens technology centre. As soon as I looked into it, I realise that I had once seen it before: on a cable car ride across the Thames. I now know how to get to The Crystal if ever I need to visit it!
I enjoyed Franco’s session: he covered a lot of ‘tech stuff’ in a very short time. Students at Middlesex are clearly challenged and are clearly kept busy!
One thought is that different computing courses and degrees cover different topics and perspectives. When I was heading home from the workshop I remembered that The Open University covered a bit about robots too on a first year undergraduate module that has the code: TM129 Technologies in Practice (OU website). Students are also presented with the challenge of creating a line following robot. Rather than using real robots, a simulated one is used (but, students can get to see real ones if you come along to an engineering day school).
Measuring programming achievement after a first course
The next presentation was by Ed Currie who presented what were described as ‘thoughts and preliminary research’. One of the key thoughts (and one that I found most interesting) was why some students find programming so difficult. One note that I have made is that we can’t teach it, students can only learn programming. It’s not up to us; it’s up to them, and our job (as lecturers and teachers) it to facilitate the learning.
Ed mentioned the idea of Threshold concepts (Wikipedia) by Meyer and Land. I’ve made a note of the point that ‘sequence is a threshold concept’ (when it comes to programming). I remembered hearing the phrase before from a colleague who was doing what I think was some research to see what happened when students grappled with key ‘threshold concepts’.
Two great phrases that I’ve noted down are ‘neo-piagetian stages’ and ‘flip classroom’ (Wikipedia). In some respects the OU has always been doing ‘flipped classrooms’, i.e. students study some material and the go to a face to face tutorial to apply what has learnt, either in terms of solving a problem, or through facilitated discussions.
I don’t know what the context was or where this came from, but I also made the note ‘sharing of learning stories’. This might have just been an idle idea during Ed’s talk, or something that Ed had said. When it comes to learning how to do computer programming, I’ve got my own story (which might well be insufferably dull!), and I’m sure that other people have their stories. Perhaps something could be gained (in terms of learning strategies and approaches) if we find the space to discuss and share how we know what we know.
Reflections on teaching design patterns
The final presentation of the day and final presentation of the workshop was by Carl Evans, who is a lecturer at Middlesex. Carl talked about his work on an MSc module and his experience of creating and presenting a module about software design patterns.
In computer science and software engineering, Design Patterns is one of my favourite topics. A couple of points that Carl made really resonated with me. One was that ‘industry needs architects, not just programmers’. Another great point (and one that I totally subscribe to) is that there is an increasing expectation (from industry) that graduates can work with frameworks as well as know how to use programming languages. In some ways, this point connected up with Thomas’s keynote.
Carl mentioned Sun/Oracle certifications, the use of layered architectures, and frameworks called Spring (Wikipedia) and Hibernate (Wikipedia) that I have heard of, but have never used in anger. A quick look into these frameworks quickly shows that design patterns feature pretty prominently.
A really questions are: how do we best teach patterns, and where do we start? Is there a pattern about how to teach patterns? I noted down that a refresher about the object-oriented approach is useful, before taking students through different categories of patterns, such as object creation patterns, enterprise patterns, data access patterns, and compound patterns (I was writing everything down pretty quickly at this point, so I might not have managed to the nuances of everything that was said).
Carl also told us about a site called Design Patterns Library which I don’t think I’ve seen before. One book that was referenced was Head First Design Patterns by O’Reilly. There seems to be a claim going around that says that these ‘head first’ books are based on ‘neuroscience’ (but I’ve yet to find out exactly what exactly this means: claims like that immediately make me sceptical!) Either way, anything that helps to make important technical concepts understandable is a good thing.
Final thoughts
I don’t know how many Psychology of Programming Work In Progress events I’ve been to, but it’s been quite a few. This might have been my fourth or fifth. I have enjoyed every single one, and I enjoyed this one at Middlesex University too. It was well organised, friendly and thought provoking. The talks were really interesting, covering distance learning, errors, notation, robots, challenge of teaching object-oriented programming and a whole load of other subjects too. The great thing about these events is that you never know what you’re going to get, which means that you never really know what you’re going to learn (and this can be, invariably, a very good thing too).
From my perspective, the event helped to strengthen an opinion I have, which is that we need to figure out how to help students (and practicing programmers) how to best understand and work with software frameworks. This issue is not only a computing education issue, but also, significantly, a psychology of programming issue. The first subject that I studied when I discovered this subfield of computing (or of psychology, depending on your ‘home’ discipline) was the topic of program (or software) comprehension. It’s clear from this short workshop that this continues to be (for me) an important topic.
Psychology of Programming Interest Group : work in progress meeting: Day 2
Teaching programming at a distance
The first presentation of the second day was by yours truly. I gave a short talk about a university funded project that aims to understand more about the teaching experience of Open University associate lecturers who are tutoring on the TT284 Web Technologies module.
One of the purposes of the project was to understand issues particular to the learning (and teaching) of programming. An area of particular interest is the transition between the first level modules (which use some visual programming language) to the second level modules which require students to pay more attention to other issues, such as language syntax.
I wasn’t able to present any firm findings at this stage (since I keep getting sucked into the idiosyncrasies of my day job), except that three themes that were emerging were that some students can struggle with understanding what PHP is and how it works, confusion about Javascript, and the perpetual battle to understand regular expressions (which is, I believe, an issue that pretty all developers, expert or novice, seem to have)
The question and answer session was interesting. There was some chat about a coding DoJos (group coding sessions), the use of MOOCs (FutureLearn and the Kahn Academy), and how get students talking to each other.
Holistic programming teaching at Middlesex
Franco Raimondi’s talk was rather different to all the others: he showed us some robots (real hardware!) that he used in his teaching. They had an interesting design, using both Raspberry Pi devices that were connected to Arduino microcontrollers.
One question was: why use both? The Arduinos are used to control analogue input, but the heart of the control is managed (as far as can understand it) by the Raspberry Pi devices. Students then have the challenge of how to design and implement a communication protocol between the Pi and the sub-component. I personally think this is a great approach: students are exposed to different devices and learn more about their purpose. When I had a job in industry, one thing that I had to do is figure out how to get one embedded controller talking to another: Franco’s robots would have helped me a lot to figure out how to do this. More information about the robots can be found by taking a look at the MIddlesex Robotic plaTfOrm: MIRTO website.
Okay, so there is an interesting robot, but how are they used in practice? Franco described a series of lectures, design workshops, programming workshops and physical computing workshops. In the workshops (if my notes are correct!) students are asked to solve different problems, such as to write a line following algorithm where the robot has to cater for 90 degree turns, and to complete different line circuits as fast as possible. Students could also implement control algorithms, such as PID controllers (Wikipedia) (which again takes me back to the days when I worked in industry for a while), remote control and managing the taking of cameras by controlling the Raspberry Pi.
What I found really interesting was that the platform (and the workshops) made use of a programming language called Racket (Wikipedia). Racket is a language that I had not heard of before, but apparently it has roots in the Lisp language. In some respects, I commend the choice (because it’s great to expose students to different programming paradigms), but on the other hand, there is something to be said for getting to grips with tools that are used in industry. I guess this just goes to show that whenever you come along to workshop like these, you always learn new stuff.
Towards the end of Franco’s session, he spoke about a system to record Student Observable Behaviours, which then led onto a discussion about learning objectives. Apparently, the use of ‘observable student behaviours’ is something that Middlesex use, perhaps as a part of their assessment strategy. We were shown a web-based tool that lecturers can use to gather evidence of student engagement and activity.
I don’t know what this relates to, but I also made a note of a place called The Crystal (Crystal website), which was also described as the Siemens technology centre. As soon as I looked into it, I realise that I had once seen it before: on a cable car ride across the Thames. I now know how to get to The Crystal if ever I need to visit it!
I enjoyed Franco’s session: he covered a lot of ‘tech stuff’ in a very short time. Students at Middlesex are clearly challenged and are clearly kept busy!
One thought is that different computing courses and degrees cover different topics and perspectives. When I was heading home from the workshop I remembered that The Open University covered a bit about robots too on a first year undergraduate module that has the code: TM129 Technologies in Practice (OU website). Students are also presented with the challenge of creating a line following robot. Rather than using real robots, a simulated one is used (but, students can get to see real ones if you come along to an engineering day school).
Measuring programming achievement after a first course
The next presentation was by Ed Currie who presented what were described as ‘thoughts and preliminary research’. One of the key thoughts (and one that I found most interesting) was why some students find programming so difficult. One note that I have made is that we can’t teach it, students can only learn programming. It’s not up to us; it’s up to them, and our job (as lecturers and teachers) it to facilitate the learning.
Ed mentioned the idea of Threshold concepts (Wikipedia) by Meyer and Land. I’ve made a note of the point that ‘sequence is a threshold concept’ (when it comes to programming). I remembered hearing the phrase before from a colleague who was doing what I think was some research to see what happened when students grappled with key ‘threshold concepts’.
Two great phrases that I’ve noted down are ‘neo-piagetian stages’ and ‘flip classroom’ (Wikipedia). In some respects the OU has always been doing ‘flipped classrooms’, i.e. students study some material and the go to a face to face tutorial to apply what has learnt, either in terms of solving a problem, or through facilitated discussions.
I don’t know what the context was or where this came from, but I also made the note ‘sharing of learning stories’. This might have just been an idle idea during Ed’s talk, or something that Ed had said. When it comes to learning how to do computer programming, I’ve got my own story (which might well be insufferably dull!), and I’m sure that other people have their stories. Perhaps something could be gained (in terms of learning strategies and approaches) if we find the space to discuss and share how we know what we know.
Reflections on teaching design patterns
The final presentation of the day and final presentation of the workshop was by Carl Evans, who is a lecturer at Middlesex. Carl talked about his work on an MSc module and his experience of creating and presenting a module about software design patterns.
In computer science and software engineering, Design Patterns is one of my favourite topics. A couple of points that Carl made really resonated with me. One was that ‘industry needs architects, not just programmers’. Another great point (and one that I totally subscribe to) is that there is an increasing expectation (from industry) that graduates can work with frameworks as well as know how to use programming languages. In some ways, this point connected up with Thomas’s keynote.
Carl mentioned Sun/Oracle certifications, the use of layered architectures, and frameworks called Spring (Wikipedia) and Hibernate (Wikipedia) that I have heard of, but have never used in anger. A quick look into these frameworks quickly shows that design patterns feature pretty prominently.
A really questions are: how do we best teach patterns, and where do we start? Is there a pattern about how to teach patterns? I noted down that a refresher about the object-oriented approach is useful, before taking students through different categories of patterns, such as object creation patterns, enterprise patterns, data access patterns, and compound patterns (I was writing everything down pretty quickly at this point, so I might not have managed to the nuances of everything that was said).
Carl also told us about a site called Design Patterns Library which I don’t think I’ve seen before. One book that was referenced was Head First Design Patterns by O’Reilly. There seems to be a claim going around that says that these ‘head first’ books are based on ‘neuroscience’ (but I’ve yet to find out exactly what exactly this means: claims like that immediately make me sceptical!) Either way, anything that helps to make important technical concepts understandable is a good thing.
Final thoughts
I don’t know how many Psychology of Programming Work In Progress events I’ve been to, but it’s been quite a few. This might have been my fourth or fifth. I have enjoyed every single one, and I enjoyed this one at Middlesex University too. It was well organised, friendly and thought provoking. The talks were really interesting, covering distance learning, errors, notation, robots, challenge of teaching object-oriented programming and a whole load of other subjects too. The great thing about these events is that you never know what you’re going to get, which means that you never really know what you’re going to learn (and this can be, invariably, a very good thing too).
From my perspective, the event helped to strengthen an opinion I have, which is that we need to figure out how to help students (and practicing programmers) how to best understand and work with software frameworks. This issue is not only a computing education issue, but also, significantly, a psychology of programming issue. The first subject that I studied when I discovered this subfield of computing (or of psychology, depending on your ‘home’ discipline) was the topic of program (or software) comprehension. It’s clear from this short workshop that this continues to be (for me) an important topic.