On 19 February 2015, I went to something called the HEA new to teaching workshop which was a part of a larger HEA ‘transitions conference’. Now, I’ll be the first to admit that I’m not new to teaching, but there was a bit of the workshop that I was really interested in: a section that was about how to teach introductory programming. The reason for my interest is that teaching programming is pretty difficult: some students excel, whereas other students struggle.
The session was facilitated by Karen Fraser from the HEA. I’ve met Karen numerous times before, but I have never been to a session that Karen ran entirely on her own. Instead, her role has been always to facilitate and introduce other speakers.
The aims of the day were to think about and reflect on our teaching practice, consider different ways of teaching, consider what things we are doing well, and share practice between each other. This is a quick blog summary of the event. I’ve written it for a number of reasons: it’s a set of notes that also contains links to useful resources, a way to tell my line managers what I’m getting up to, and to share some personal reflections about the event with Open University and other colleagues.
Professions
Karen opened the session by asking us a couple of questions: ‘is computing a profession?’ and ‘is academia a profession?’ My immediate response to the first question is: yes, because there’s a body called the British Computer Society (BCS.org) which aims to develop the professionalism of those working within the computing and IT industry.
I noted down that the purpose of the HEA is to enhance professionalism in higher education. There are a number of issues that it addresses: reward and recognition, career progression, and continuing professional development. In some respects, these areas can be connected to something called the Professional Standards Framework (PSF) where HE professionals can apply to gain different levels of professional recognition. Karen briefly summarised the PSF, telling us that it contained six aspects of core knowledge, five areas of activity, and four professional values.
Returning to the original question, did we hold the view that higher education is a profession? From memory, I believe the consensus was that higher education should be viewed as one. It was also interesting to hear that the HEA has applied for a charter to become a professional society in the same way that the BCS is.
Teaching and learning
It might sound obvious, but one of the key aspects of professionalism in higher education is the need to foster and continually update knowledge and understanding about how students learn, both generally, and within their subject or disciplinary areas.
These key points led us to a discussion about the different types of teaching techniques that we could use in our discipline. These ranged from the use of role play, applying a technique called action learning and demonstrating, such as showing students what code looks like in a debugger. At this point I had a thought about the virtues of animations. When I was industry I learnt a lot when I watched another more experienced programmer at work. This short discussion was immediately making me think about what might help students to get to grips with the fundamentals of computing.
In my notes, I made the comment: ‘pair programming: advantages and disadvantages’. I’m not exactly sure what I meant by this, but gently picking apart this theme immediately suggests a broad range of different issues: the importance of continuous learning within the computing and IT industry, the question of what skills industry is looking for and what universities can do to help, and the importance of soft skills in subjects such as IT and computing.
Teaching introductory programming
The next part of the session moved from considering the academic as a profession to the specifics about teaching of introductory programming.
We discussed some of the problems and challenges: students need to know about different programming languages and tools, and there is also the necessity to develop problem solving skills and increase student’s awareness of strategies of programming design and implementation. A key point was that programming is a creative exercise; it’s all about the solving of new problems. A perpetual challenge is how to map (or translate) real world problems into code.
Karen showed us a slide that asked a single question: ‘where do students struggle and what do you think their problems are?’ During the resulting discussion, I made a note of the following points: as lecturers we can’t teach programming, we can only help students to learn it; students need to put ‘the hours in’ (since programming is like any skilled activity). Also, the context for learning is important: we need to explain why we’re doing what we’re doing.
Other key points were: the importance of expectations, inexperience and confidence; the importance of how to decompose problems, and asking students whether they are fundamentally interested in the subject. An interesting question (to students) could be: ‘are you prepared to be confused?’ and asking students to reflect on their own experience with computing devices and their knowledge of hardware and software.
Some other interesting points related to the activity (or exercise) of ‘making a cup of tea’, to learn the idea of problem decomposition (this, incidentally, is an exercise that some of our Open University TU100 tutors use at a programming day school). Other skills might include the ability to identify sequences, patterns and steps (along with understanding how to do, and translate into computer code basic arithmetic). Finally, MOOCs (free on-line courses) were mentioned as possible way to allow students to acquire background knowledge. One thought was that perhaps a MOOC might help students transition between A-level and degree level study.
Another question was introduced: why is teaching (or learning) programming so difficult? Some tentative suggestions were that programming is a skill, and it is something that is learnt by doing, and also programming isn’t a prerequisite for computing modules. There is also the challenge of dealing with the syntax (or structure) of programming languages, and that students might not have experience of important concepts, such as data typing.
We were taken through two other slides: thoughts about problems with students (a lack of analytical, reasoning and planning skills?), and thoughts about problems with lecturers (a disconnect in terms of communication and issues surrounding instructional materials, teaching methods and teaching strategies). These problems can have impacts. These might be students becoming disillusioned and the waning of enthusiasm which could lead to a failure to attend practical classes. But what could we (as lecturers or educators) do? Some thoughts related to the importance of learning design, early identification when students get lost, the importance of fast feedback, and the encouragement of reflection.
All this led to a discussion that had the title: ‘what delivery techniques could we use to engage students and help them understand difficult concepts?’ The group came up with the following thoughts (amongst others): Use of the institutional virtual learning environment and flipped classrooms (Wikipedia), the use of small groups, facilitated debates, use of media stories, the creation of animation to demonstrate ideas, translation of algorithms into ‘physical theatre’ (pretending students are different values based on height), use of robots, the idea of ‘code as a performance’ (as something the lecturers, or students create front of others, potentially also demonstrating failure), application of peer assessment, use of in-class question and response systems, helping students to create their own resources, and inviting students to present different ideas to each other.
An important point was made: research (I’m not sure which research!) has shown that students have a hierarchy of pedagogical preferences when it comes to learning programming: students like programming lab sessions more than they like working on projects. Lectures, it seems, isn’t viewed as an effective way to teach programming. Thinking back to my own experience as an undergraduate (when I had to learn a programming language called Pascal), I can completely relate to this.
On the subject of peer assessment, we were introduced to a system called Peerwise (University of Auckland). I hadn’t heard of this system before. We were shown a brief introductory video about the system (Peerwise website). I have heard of other peer assessment systems, such as WebPA which (I understand) used to be funded by JISC. An idle thought is that it would be interesting to do a comprehensive review of these peer assessment systems (since I seem to think there are a few other systems out there).
After lunch…
A provocative question was posed in the first session after lunch: should programming be taught in the first year of a degree? An alternative perspective was that perhaps we ought to first teach other subjects, such as data structures and algorithms before moving onto programming. This way, students get the opportunity to understand more about some of the fundamental concepts of software and computing. My own view is one that connects back to earlier discussions, namely, that since programming is a fundamental skill, and it’s something that takes a long time to master, we need to give students the experience of what is meant by programming early on in the curriculum.
The next session was about sharing good practice in lecturers. One of the biggest take away tips from the day was the idea of changing something every fourteen minutes: divide an hour lecture into different sections that are punctuated by videos, run discussion activities or question and answer sessions, get willing students to come to the front of the class, or change the entire tenor (or tone) of a lecture by telling a story or an anecdote, or take a bit of time to introduce other resources, such as MOOCs. Another thought is to ask students to prepare something for a tutorial (but always remember that you’ve done this! On the subject of videos, we were offered an example: a clip entitled The Friendship Algorithm (YouTube) from the comedy series The Big Bang Theory.
The workshop ended with a chat about a range of different issues. We chatted about the importance of reflection so we can understand more about our performance as lecturers, and also the importance of reflecting on what our students have learnt from our teaching practice. Another topic was the importance of feedback, and how feedback is perceived by students.
A final take away point was a reference to a paper by Chickering and Gamson entitled Seven Principles for Good Practice in Undergraduate Education (Washington news centre, PDF). Although there isn’t anything in this paper that struck me as substantially new (which was published around twenty five years ago), it does represent a neat set of principles that can be fairly easily remembered and internalised. When I was looking through the paper, one thought was: ‘how might these principles be translated or adapted to the on-line distance education context?’ or ‘what attributes of a module design might adhere to these principles?’
Final thoughts
Not long after I joined this session, Karen said to me, ‘you’re not new to teaching, are you Chris?’ In some respects this question was a challenge. It was also a challenge that immediately led to a reflection. The answer was: ‘I’m not new to teaching, but I’m here to see if there is anything new I can learn’.
I was there for two reasons. The first reason is that one of my jobs is to help to induct new tutors to the university and to help to run associate lecturer development sessions, which means it would be useful to know how the HEA does things. Secondly, as mentioned earlier, I have an interest in the teaching of introductory computing and programming.
The whole day turned out to be useful: Karen’s discussion about the professionalisation of higher education was interesting and informative, and the day turned out to be a useful opportunity to share teaching practice and to learn about new resources. By the end of the day I ended up coming out of the session with more questions than I went in with. This, of course, is a sign of a good day.
HEA new to teaching workshop
On 19 February 2015, I went to something called the HEA new to teaching workshop which was a part of a larger HEA ‘transitions conference’. Now, I’ll be the first to admit that I’m not new to teaching, but there was a bit of the workshop that I was really interested in: a section that was about how to teach introductory programming. The reason for my interest is that teaching programming is pretty difficult: some students excel, whereas other students struggle.
The session was facilitated by Karen Fraser from the HEA. I’ve met Karen numerous times before, but I have never been to a session that Karen ran entirely on her own. Instead, her role has been always to facilitate and introduce other speakers.
The aims of the day were to think about and reflect on our teaching practice, consider different ways of teaching, consider what things we are doing well, and share practice between each other. This is a quick blog summary of the event. I’ve written it for a number of reasons: it’s a set of notes that also contains links to useful resources, a way to tell my line managers what I’m getting up to, and to share some personal reflections about the event with Open University and other colleagues.
Professions
Karen opened the session by asking us a couple of questions: ‘is computing a profession?’ and ‘is academia a profession?’ My immediate response to the first question is: yes, because there’s a body called the British Computer Society (BCS.org) which aims to develop the professionalism of those working within the computing and IT industry.
I noted down that the purpose of the HEA is to enhance professionalism in higher education. There are a number of issues that it addresses: reward and recognition, career progression, and continuing professional development. In some respects, these areas can be connected to something called the Professional Standards Framework (PSF) where HE professionals can apply to gain different levels of professional recognition. Karen briefly summarised the PSF, telling us that it contained six aspects of core knowledge, five areas of activity, and four professional values.
Returning to the original question, did we hold the view that higher education is a profession? From memory, I believe the consensus was that higher education should be viewed as one. It was also interesting to hear that the HEA has applied for a charter to become a professional society in the same way that the BCS is.
Teaching and learning
It might sound obvious, but one of the key aspects of professionalism in higher education is the need to foster and continually update knowledge and understanding about how students learn, both generally, and within their subject or disciplinary areas.
These key points led us to a discussion about the different types of teaching techniques that we could use in our discipline. These ranged from the use of role play, applying a technique called action learning and demonstrating, such as showing students what code looks like in a debugger. At this point I had a thought about the virtues of animations. When I was industry I learnt a lot when I watched another more experienced programmer at work. This short discussion was immediately making me think about what might help students to get to grips with the fundamentals of computing.
In my notes, I made the comment: ‘pair programming: advantages and disadvantages’. I’m not exactly sure what I meant by this, but gently picking apart this theme immediately suggests a broad range of different issues: the importance of continuous learning within the computing and IT industry, the question of what skills industry is looking for and what universities can do to help, and the importance of soft skills in subjects such as IT and computing.
Teaching introductory programming
The next part of the session moved from considering the academic as a profession to the specifics about teaching of introductory programming.
We discussed some of the problems and challenges: students need to know about different programming languages and tools, and there is also the necessity to develop problem solving skills and increase student’s awareness of strategies of programming design and implementation. A key point was that programming is a creative exercise; it’s all about the solving of new problems. A perpetual challenge is how to map (or translate) real world problems into code.
Karen showed us a slide that asked a single question: ‘where do students struggle and what do you think their problems are?’ During the resulting discussion, I made a note of the following points: as lecturers we can’t teach programming, we can only help students to learn it; students need to put ‘the hours in’ (since programming is like any skilled activity). Also, the context for learning is important: we need to explain why we’re doing what we’re doing.
Other key points were: the importance of expectations, inexperience and confidence; the importance of how to decompose problems, and asking students whether they are fundamentally interested in the subject. An interesting question (to students) could be: ‘are you prepared to be confused?’ and asking students to reflect on their own experience with computing devices and their knowledge of hardware and software.
Some other interesting points related to the activity (or exercise) of ‘making a cup of tea’, to learn the idea of problem decomposition (this, incidentally, is an exercise that some of our Open University TU100 tutors use at a programming day school). Other skills might include the ability to identify sequences, patterns and steps (along with understanding how to do, and translate into computer code basic arithmetic). Finally, MOOCs (free on-line courses) were mentioned as possible way to allow students to acquire background knowledge. One thought was that perhaps a MOOC might help students transition between A-level and degree level study.
Another question was introduced: why is teaching (or learning) programming so difficult? Some tentative suggestions were that programming is a skill, and it is something that is learnt by doing, and also programming isn’t a prerequisite for computing modules. There is also the challenge of dealing with the syntax (or structure) of programming languages, and that students might not have experience of important concepts, such as data typing.
We were taken through two other slides: thoughts about problems with students (a lack of analytical, reasoning and planning skills?), and thoughts about problems with lecturers (a disconnect in terms of communication and issues surrounding instructional materials, teaching methods and teaching strategies). These problems can have impacts. These might be students becoming disillusioned and the waning of enthusiasm which could lead to a failure to attend practical classes. But what could we (as lecturers or educators) do? Some thoughts related to the importance of learning design, early identification when students get lost, the importance of fast feedback, and the encouragement of reflection.
All this led to a discussion that had the title: ‘what delivery techniques could we use to engage students and help them understand difficult concepts?’ The group came up with the following thoughts (amongst others): Use of the institutional virtual learning environment and flipped classrooms (Wikipedia), the use of small groups, facilitated debates, use of media stories, the creation of animation to demonstrate ideas, translation of algorithms into ‘physical theatre’ (pretending students are different values based on height), use of robots, the idea of ‘code as a performance’ (as something the lecturers, or students create front of others, potentially also demonstrating failure), application of peer assessment, use of in-class question and response systems, helping students to create their own resources, and inviting students to present different ideas to each other.
An important point was made: research (I’m not sure which research!) has shown that students have a hierarchy of pedagogical preferences when it comes to learning programming: students like programming lab sessions more than they like working on projects. Lectures, it seems, isn’t viewed as an effective way to teach programming. Thinking back to my own experience as an undergraduate (when I had to learn a programming language called Pascal), I can completely relate to this.
On the subject of peer assessment, we were introduced to a system called Peerwise (University of Auckland). I hadn’t heard of this system before. We were shown a brief introductory video about the system (Peerwise website). I have heard of other peer assessment systems, such as WebPA which (I understand) used to be funded by JISC. An idle thought is that it would be interesting to do a comprehensive review of these peer assessment systems (since I seem to think there are a few other systems out there).
After lunch…
A provocative question was posed in the first session after lunch: should programming be taught in the first year of a degree? An alternative perspective was that perhaps we ought to first teach other subjects, such as data structures and algorithms before moving onto programming. This way, students get the opportunity to understand more about some of the fundamental concepts of software and computing. My own view is one that connects back to earlier discussions, namely, that since programming is a fundamental skill, and it’s something that takes a long time to master, we need to give students the experience of what is meant by programming early on in the curriculum.
The next session was about sharing good practice in lecturers. One of the biggest take away tips from the day was the idea of changing something every fourteen minutes: divide an hour lecture into different sections that are punctuated by videos, run discussion activities or question and answer sessions, get willing students to come to the front of the class, or change the entire tenor (or tone) of a lecture by telling a story or an anecdote, or take a bit of time to introduce other resources, such as MOOCs. Another thought is to ask students to prepare something for a tutorial (but always remember that you’ve done this! On the subject of videos, we were offered an example: a clip entitled The Friendship Algorithm (YouTube) from the comedy series The Big Bang Theory.
The workshop ended with a chat about a range of different issues. We chatted about the importance of reflection so we can understand more about our performance as lecturers, and also the importance of reflecting on what our students have learnt from our teaching practice. Another topic was the importance of feedback, and how feedback is perceived by students.
A final take away point was a reference to a paper by Chickering and Gamson entitled Seven Principles for Good Practice in Undergraduate Education (Washington news centre, PDF). Although there isn’t anything in this paper that struck me as substantially new (which was published around twenty five years ago), it does represent a neat set of principles that can be fairly easily remembered and internalised. When I was looking through the paper, one thought was: ‘how might these principles be translated or adapted to the on-line distance education context?’ or ‘what attributes of a module design might adhere to these principles?’
Final thoughts
Not long after I joined this session, Karen said to me, ‘you’re not new to teaching, are you Chris?’ In some respects this question was a challenge. It was also a challenge that immediately led to a reflection. The answer was: ‘I’m not new to teaching, but I’m here to see if there is anything new I can learn’.
I was there for two reasons. The first reason is that one of my jobs is to help to induct new tutors to the university and to help to run associate lecturer development sessions, which means it would be useful to know how the HEA does things. Secondly, as mentioned earlier, I have an interest in the teaching of introductory computing and programming.
The whole day turned out to be useful: Karen’s discussion about the professionalisation of higher education was interesting and informative, and the day turned out to be a useful opportunity to share teaching practice and to learn about new resources. By the end of the day I ended up coming out of the session with more questions than I went in with. This, of course, is a sign of a good day.