Seven lessons I learned in my quest for transforming my teaching (draft, version: 0.1)
(N.B. — This is a work in progress, and the final conclusions/final form of the article may be different)
Last year, I had two revelations — first, that I could use a workshop style delivery of lecture with active learning from the students and teach any topic I wanted that way; second — I could teach without worrying about grading at all, I could go gradeless. This year, I wanted to put both these ideas in the space of one course on research methods I teach at the university and tried to test how it would be if I were to apply both these lessons to my teaching practice. This effort is still going on, and therefore this is a work in progress.
What I changed
- Gradeless grading. — I have three assignments in the course. The course is about research methods in health sciences for postgraduate students; the classes are held in a “block format”: the students attend three blocks of two days each (9AM — 3PM each day per block). As part of the course, the students will have to come up with a research proposal on a topic of their choice. The first of the three assignments is about critical thinking, where they write a draft of a research idea where they outline their topic of choice, review current knowledge, identify the gaps in the current knowledge, and provide an outline of what is new in their work and propose a line of investigation. The critical thinking component draws on a text by Tom Chatfield “Critical Thinking”. In the second assignment, I teach the students data analysis and development of surveys (survey design) and how to validate surveys and find validity and reliability of surveys. I also teach them how to use the free and open source statistical programming environment R, using the tidyverse package and teach them data science using R. This draws on the work by Hadley Wickham and the gitbook contents “Data Science in R”. The graphs are drawn on ggplot2. You can see the interactive python notebook I use for the second component here. I used the codes in the interactive python but demonstrated and worked with the students using Rstudio. This was done so that they could work on the codes in a different environment and practice after the class was over.
- The third block is about writing a research report and this draws on the book by Williamson and Bizup and also on a blog by Pat Thomson. The emphasis here is to write a paper having had the key concepts of research methods and critiquing health research. The assignment components involve first writing a research idea, then in the second assessment, the students add data analyses and surveys to the developing proposal and finally, in the third assessment, students write or complete their proposal.
- Grading in the course works as follows: I provide them extensive feedbacks and engage myself with the work they have done, but I do not assign them a grade at the time of providing feedback. Instead, I ask them to grade themselves based on their understanding of their own work, my comments and notes on their work, and their own impressions. I insist that this way of grading allows them to understand the importance of their own work, forces them to read my comments and helps them to better appreciate their own measures. I learned about gradeless grading or ungrading from the work of Jesse Stommel (see his course outline on cinema studies to learn more about how he does it) and Sein Michael Morris, Arthur Chiaravalli, and others. I understand that there is a growing tribe of educators who have decided to go gradeless and I am inspired by what they are doing. Working with adult learners who are self-motivated learners who have come to the university to “upskill themselves”; some of them are PhD students (PhD in the university where I teach is through research not classwork), and I believe for these students, learning outcomes are more important than an emphasis on grades alone. But I need to adjust to the grading system at the university with letter and number based grading, hence I have to make some adjustments.
- Use a software/data carpentry framework to teach. — I learned about software/data carpentry last year and got myself a carpentry instructor certificate. As part of the certification process: (1) I attended an all-day online course (in my case, as I could not travel anywhere to complete an in-person software carpentry instructor training course, and it was an all-night course to accommodate myself with the US time zones since I am based in New Zealand), (2) I had to demonstrate that I could teach following the principles of software carpentry, and (3) I had to participate online in discussions with other members who have undergone the training to discuss the training processes. These three activities opened myself to another aspect of transforming my teaching from a more lecture based teaching style to a more activity based teaching style for almost any topic. The emphasis of software/data carpentry is on teaching and enabling learners to learn statistical programming and languages such as R and Python, and also how to use open source and free tools such as git, and process data using OpenRefine but the scope of the work and tutorials are expanding regularly. Now, you can use software/data carpentry style teaching for Authorship (“Author Carpentry”), and use libraries as well (“Library Carpentry”). After the training programme and part of the certification process, I have started working with my mentor Jonah Duckles (thank you Jonah) and have scheduled regular discussions on how to use carpentry style lessons for running workshops and developing classroom materials for teaching tertiary classes and training of PhD students and post-docs when not conducting workshops. Jonah taught me how to use a course development template where I could develop lessons.
- What did I do to develop software/data carpentry style teaching for my course. — Here, to begin with, I created a github repository for my course where I put my codes and teaching/tutorials as a series of statements, challenges, and exercises for the students to complete in-class, as real time work, rather than only ideas that were delivered in the form of lectures that they had to listen to passively. Second, I included the link to the github repo in the course management programme (based on Moodle) that the students could access. Third, I asked students to download and install R and Rstudio for their R based training that I provided on the second block. Fourth, I created an R based tutorial on a Jupyter Notebook and uploaded the Jupyter notebook on an Azure Notebook and shared the link. As you can see in the Jupyter notebook, I wrote explanatory comments to each code I included there. I did this on purpose so that after the class the students could practice from the Jupyter notebook. As Azure included R, Python, and other environments, the students would also be able to run the codes directly on the Azure servers if they created logins. Fifth, I created a hackmd.io document and used it to teach how to design a survey questionnaire. We used this in the class/workshop where the class learned together as they edited the document real time in the class as to how to design a survey. I delivered these components using the framework of delivery of Software/data carpentry which included the following:
- Live coding or emulate live coding. — Live coding is a component of software/data carpentry style teaching where the instructor first writes code on his computer that is connected to a data projector. The data projector throws up the image of the code being written on the wall; the attendees view the code being written in live and they copy the code and write them on their own machines. Then the instructor and the attendees (trainees) run the code together and study from the code snippet and the results. The instructor explains the code and the results. In classes where I taught R, I used this format where the students had to follow or write the codes after me and I would first write the codes on my computer attached to the data projector and the students would follow me writing the code and run them. If some of them went ahead and found the process slow, I’d give them a challenge to work with and while they worked with the challenge, the others would work with the process and catch up. This was done to ensure every one was on the same page.
- Repeated feedbacks. — This is part of software/data carpentry training sessions, where the attendees are asked to repeatedly provide feedbacks on how they are doing, what they have learned, check their understandings. The instructor frequently stops and asks questions about their understanding, and poses challenges (simple easy challenges whose purpose is to understand for the instructor that the instructions and the topic is clear to the students/attendees). The students respond to the challenges and the instruction progresses.
- Faded Examples. — These are situations where the instructor writes half finished examples of functions or codes and asks the participants or attendees to complete them. These are kept as puzzles or tools to check the understanding of the attendees.
I built these three features in the modules I taught in the course. The live coding was straightforward for teaching programming R; for designing surveys, I worked along side the students using the hackmd.io document, and similarly worked on other examples during the discussion on critical reflection. Repeated feedbacks were based on using red and white post-it notes in the class where the students indicated how they were learning; also using questions and answers. Faded examples were used in teaching R and dplyr and functions.
The lessons I learned
- Need to arrange for backup computers when needed. — I emailed all students a week ahead of class asking them to bring their laptops to the class. Some brought, others didn’t. I had to arrange for additional and backup computers. Again, while some brought computers to the class, these computers were not all the same. Some had old Windows machines and some had Macbook Airs that needed some handholding.
- Learner motivation is the difference between software/data carpentry and a classroom where software/data carpentry style lessons are used. — Not all learners are equally motivated to learn the materials in the class they signed up. This is different from the setting of a software/data carpentry where the lessons are focused and the students know that they are motivated to learn a particular topic within a short time. This may be driven by their personal needs or professional requirements. I cannot assume that all students, no matter how mature they are, will be equally motivated to learn in the way. As a teacher I may overlook this issue of motivation if I design my class only on the basis of lectures, assignments, and providing a grade with some feedback (a standard practice), but as I transitioned into a class teaching pattern that forced me to be actively interested in the students’ active learning mode, issues around their motivation to do the course and what they wanted out of it surfaced. A possible approach could be to bring the discussion on motivation to learn upfront early in the course or a free discussion session. Students arrive at a class with different expectations and with different experiences of having gone through classes that have not traditionally utilised this format.
- A strict structure is necessary. — I find a need for a well-defined structure for the class is needed for this style of teaching. In the old style (lecturing/assessing/grading), you can excuse yourself if the structure is a bit lax and say that it allows for a more relaxed pace and you can also invite other teachers to come and teach into your class (you can still do that in this format), but a well-defined structure with time boundaries is necessary here. First, if I am working along side my students and we are learning in modules, then it is important that we finish each step of the work in time before we move to the next module. The pace is set by the slowest student and that is OK. This makes it a journey. The same is true for assessments. When I gave detailed notes and comments on their assignments for the first time and asked students to reflect on their grades, many of them were confused as to how they would do this, in spite of me providing them guidelines of grading themselves. They were looking for strict rubrics that they could use to grade themselves. So a fine tuned structure that details everything from the order of the classes, to the grading process can be helpful, although personally at this stage, I believe that a more relaxed approach towards teaching works best for me.
- Set expectations early on. — It is necessary to explain to the class early on that this learning is more of a journey that meeting end points. Students who are more familiar with more goal directed learning often get frustrated when they realise that their codes are not working or they made simple errors and spent time in trouble shooting rather than “learning” some points covered in the class. It is essential to emphasise that time spent in trouble shooting is as much part of the journey of learning as the learning of content itself. It is the journey that matters.
- Putting files in the cloud, VPN, and cloud computing may work well. — In the software/data carpentry approach, they do not prefer that students or instructors work from VPN or cloud and that everyone brings their own devices. Working in the classroom, I found that for that to happen, I cannot set any expectations. The students may not understand how to manage their technological devices. Therefore, using the university provided VPNs would not be a bad idea. That standardises the devices and tools we would use, and take out issues around version conflicts and incompatibility of devices and tools that beset some students. There would still be issues around which browser people use to access the code machines (such as Internet explorer 6, believe me, there are still some that use those), but by and large, that would help to solve some problems around incompatibility. Plus the files are persistent.
- Gradeless/flipped grading is well-accepted by the students. — I found that students loved the gradeless grading scheme and found that this freed themselves from the fear of grades down the course. In turn, this helped them to focus on the topics taught in the class and on the nitty gritty of the work rather than fret about what grade they would be after. After the first grading exercise when they were unsure how they would grade themselves, it seemed to me that the students knew what grades they would be after and tailor their work towards achieving that. It also improved their timely submission as they know that this is about detailed feedbacks rather than a grading exercise.
- Students tend to grade themselves lower than what I’d have graded them. — I was surprised to find that most students would grade themselves lower (at least a notch or two) that what I’d have graded them going by my comments on their work.