Coding is a tough field to teach.

From the 1s and 0s of binary to a wide range of programming languages which extend from the low level to compiled and interpreted languages such as Python or JavaScript.

There is Web, app and mobile development as well as countless frameworks.

I've recently started to teach coding and have since been consuming every resource I can get my hands on!

With these findings and coupled with my hands-on observations, I've put together a list of tips for anyone currently or thinking of teaching the subject.

If you're a fellow academic, you'll be glad to know that I've attempted to root my methodology in scientific research.

1. Use Real-World Examples

Beginners should ideally be working on authentic projects not dissimilar to what's used in the real world, such as programs that manipulate images, audio, and video.

A practical approach not based on abstract coding but real life concepts has proven to both keep students engaged for the long term and set them up for success later on. [1] Learning to code doesn’t just concern the syntax and semantics of a programming language, but it’s equally as important to learn how to construct programs.

The best way to do this is adopting a step by step approach. Students perform better when tasks are broken down into clearly labeled steps (or subgoals). Giving subgoals a name helps students to see the similarity between coding problems. When students are novices, the connection between examples isn't always clear, for example returning the highest number from an array of ages and then finding the first address alphabetically from an address book array may seem like very different problems to beginners, but a skilled programmer knows they require almost an identical solution. [8–9]

Instructors should use pre-written software libraries or source code with all the library imports done. Setting those things up can be arduous and ideally students should be able to see the tangible effect of their code quickly, keeping the lesson fun and engaging from the get-go.

2. Let them be free

As well as using predesigned project templates, you don't want to manage all their interaction with software.

When concepts are fresh in students' minds, it's tempting to want to drive momentum and introduce the next module.

But sometimes you gotta take off your teaching hat and let your students feel free to practice and complete problems on their own or even just have some time to play around and be a bit silly.

Let them come with their own ideas and follow their lead, even if that means changing your lesson plan. Although their ideas will probably seem a bit wacky and overly ambitious, fostering their curiosity might lead them to even come up with solutions you would never have considered yourself.

Younger students in particular, but also more generally, love to create little games or apps they can show off to the class/friends/family. Reacting to the feedback of others, they'll start making adjustments and adding complexity in an organic iteration process.

Our creativity is our first and foremost asset. Students following their own ideas are driven to create something more unique and compelling than whatever is being prescribed by you.

Now, that's how you also show that coding is a fun and rewarding process.

If they get stuck, refrain from taking control of the mouse, it might be tempting to quickly want to keep things moving but that robs them of the experience of fixing the problem themselves through independent research - an absolute key to being a professional coder.

3. Narrow your focus to a single programming language

A principle that extends to all fields of education is that transference only comes with mastery. [1]

The courses therefore should remain in a single programming language until students have made sufficient progress of grasping the fundamentals.

An experienced programmer can easily take the information they know about loops and function calls in one language and reuse it in another language, whereas a beginner is only just making sense of the base-logic.

Trying to force transition to another syntax too early can confound learners and erode their confidence.

4. Code live

Teachers should teach code by coding live in front of their student and not solely rely on slides.

This is beneficial because:

• Teach have to type as they go which slows the teaching down and gives time for students to absorb information.
• If the teacher hits an unexpected roadblock, they can walk through how they diagnose and fix errors. Textbooks are unable to cover all possible failures. In addition, observing teachers reassures students that it's fine for them to also make mistakes.
• It encourages the incidental transfer of knowledge through osmosis. Osmosis is immersion through exposure and an analogy for natural, organic and indirect learning. Students watch how instructors work, ask questions as they arise and learn more than the teacher actively intended such as useful short cuts in the code editor.

There is an important trick to keep in mind when coding live in front of your students.

Studies have shown that students will remember what they learn during a demonstration less if they do not anticipate the result of the demonstration. What that means is making learners predict the intended outcome of your demonstration before you start demonstrating. This should be done and recorded in a public way, for example, with a show of hands, holding up A, B, C, or D-marked cue cards, or talking to their neighbor. [7]

The fear of being publicly incorrect may encourage some healthy competition and lead students to pay more attention and focus on what they are learning. Teachers should be vigilant not to punish or condemn but rather to use these wrong predictions as an opportunity for further discussion of the topic.

One other thing to keep in mind!

Just be careful not to go too slowly and avoid writing in boilerplate code (such as a library import statements). This not only slows things down, but can also divert from the lesson's anticipated aims. This can be avoided by starting the lesson with a partial skeleton of the project or keeping such code on hand to copy and paste when needed.

5. Broaden the lesson

Whilst coding is going to form the bulk of your lesson, you don't always need to literally code to teach code.

For example, there's a teaching device called Parsons Problems, also known as “mixed-up code problems”. Students are given a coding problem and all the lines of code required to solve it, however, the lines are mixed up. It's then down to them to reassemble the program in the correct order.

Faced with syntax, algorithms and design, beginners can become overwhelmed. Parsons Problems are one such way to reduce the cognitive load by breaking down concepts into manageable bite-size chunks.

Think outside of the box and remember that coding is a broad sphere. Many of the skills necessary to code effectively can be trained via other methods in order to mix up your class.

Soft skills are also important and should have a place in your lesson, here's an article I wrote on the importance of soft skills in coding.

6. Scale Your Teaching For Larger Groups With Peer Instruction

Although one-on-one tutoring with full concentration on a single student is probably the single best way to learn, it's not always possible.

Sometimes, you're teaching several, twenty, or even several hundred students at a time through the medium of an e-learning course.

The challenge in scaling your teaching to larger audiences is handling with each students' unique understanding and misconceptions of a topic.

There is, however, an interesting and established methodology called Peer Instruction to counter this. [3]

It was originally created by Eric Mazur at Harvard for larger-scale classrooms. [5] Peer instruction has since been studied and applied to a variety of subjects including computer programming. [6]

How Does It Work?

1. The instructor provides students a brief introduction to the topic.

2. The instructor then presents learners with a list of multiple-choice questions that probe for misconceptions rather than factual recall. The choice of questions must be well designed. There is no point in asking a trivial question that all students will get right. The ideal questions are those for which 40% to 60% percent of students are likely to answer correctly first time. ([4], p. 23)

3. Student then independently formulate their initial answers.

4. Following this, students have several minutes to discuss their answers with each other (typically 2–4 students in small groups). They then attempt to answer the multiple-choice questions again.

5. The teacher will then respond and only move on once all the students have the right answer. If any of the wrong answers remain prevalent after the group discussion, the teacher can directly address any lurking misconceptions.

Peer instruction is mostly a method that tries to offers an experience closer to individual mentorship but in a scalable way.

Group discussion greatly increases the comprehension as differences in reasoning can be found among students. It also forces them to make their thoughts transparent.

The teacher is then able to target specific misconceptions and adapt their explanation accordingly before moving on.

7. Use pair programming

Pair programming is a software development strategy in which 1 computer is shared by 2 programmers. The typing is handled by one person (called the driver), while the other (called the navigator) gives feedback and suggestions. The two regularly switch roles over the course of the day.

Pair programming is a good real-life programming practice used in top companies such as Google.

It can also assists in the classroom, particularly in instances where ability levels differ widely among students.

The pair tackle a task together complementing each other's skill set. The less skilled member gets individual instruction from the stronger, while the stronger member re-enforces their own understanding by explaining.

You can swap their roles 3 or 4 times every hour so that the dominant personality cannot control the entire session.

8. Beginners are not experts

When you are an expert, it’s easy to forget what is was like to be a beginner.

Ask a skilled programmer to iterate over a list of integers and generate the average, they’ll use their stored knowledge to recall the exact pattern needed and code it in seconds.

Beginners on the other hand may need to write out the algorithm on paper and contrast it with previous examples. They may not have mastered debugging and have only a limited understanding of what the code is doing.

By merely doing what professionals do at a slower pace, novices do not become professionals.

Look at it this way - we don’t teach reading by taking a classic novel and reading it at a slower pace. Kids learn to read from shorter books with simpler phrases and larger prints before gradually progressing.

So stay mindful of using small, self-contained tasks at a level acceptable for novices and with appropriate resources. [3]

QA

Coming soon

References

[1] Gick ML, Holyoak KJ., 1987. The cognitive basis of knowledge transfer. In: Cormier SM, Hagman JD, editors. Transfer of learning: Contemporary research and applications. Academic Press.

[3] Brown NCC, Wilson G., 2018. Ten quick tips for teaching programming. PLoS Comput Biol 14(4).

[4] Council NR., 2015. Reaching Students: What Research Says About Effective Instruction in Undergraduate Science and Engineering. Washington, DC: The National Academies Press.

[5] Mazur, E., 1996. Peer Instruction. Harlow: Pearson Education.

[6] Porter L, Bailey Lee C, Simon B, Cutts Q, Zingaro D., 2011. Experience Report: A Multi-classroom Report on the Value of Peer Instruction. In: Proceedings of the 16th Annual Joint Conference on Innovation and Technology in Computer Science Education: p. 138–142.

[7] Miller K, Lasry N, Chu K, Mazur E., 2013. Role of physics lecture demonstrations in conceptual learning. Phys Rev ST Phys Educ Res.

[8] Morrison BB, Margulieux LE, Guzdial M. Subgoals., 2015. Context, and Worked Examples in Learning Computing Problem Solving. In: Proceedings of the Eleventh Annual International Conference on International Computing Education Research. ICER '15. New York, NY, USA: ACM: p. 21–29

[9] Margulieux LE, Guzdial M, Catrambone, R., 2012. Subgoal-labeled Instructional Material Improves Performance and Transfer in Learning to Develop Mobile Applications. In: Proceedings of the Ninth Annual International Conference on International Computing Education Research: p. 71–78.