Introduction

Digital devices and computers play an important role in today’s society. For example, 93% of households in Sweden today have a computer (Internetstiftelsen, 2019). Due to the increased use of digital technology in society, the European Parliament and Council recommended, as early as 2006, that basic skills such as digital knowledge should be provided to citizens through ‘lifelong learning’ (EU, 2006). As a result, several European countries have revised their curricula to include computer programming (Nordén et al., 2017). Programming can be defined as a process in which a human assembles a set of instructions to solve a specific problem with a computer (Buitrago Flórez et al., 2017; Kelleher & Pausch, 2005; Statens Skolverk, 2018b). Nevertheless, in Sweden, programming in compulsory school should be seen as a broader concept that also includes creativity, steering and controlling, simulation, and democratic dimensions (Statens Skolverk, 2017). In this article, we define programming as a collection of these two definitions. However, including computer programming in the curriculum is one thing, and teaching computer programming is another even more complex task. With new content, teachers may become so-called regressed teachers. ‘Regressed expert’ refers to an experienced teacher who has to learn new content and then teach it (Liberman et al., 2012). Teaching is based on teachers’ choices, which depend on both systemic and situational factors (Doyle et al., 2019). In the classroom, these choices can be seen as different experiences and strategies (e.g. methods) aimed at pupils learning computer programming (Sentance & Csizmadia, 2017). Furthermore, teachers’ pedagogical content knowledge (PCK) in computer science, especially programming, is important when it comes to teaching programming. Although this topic has been addressed in secondary education (Bender et al., 2015; Bhaugeerutty, 2021; Buchholz et al., 2013; Giannakos et al., 2015; Hubbard, 2018; Hubwieser et al., 2013; Saeli et al., 2010), research into computer science education in primary schools is scarce.

Technology is a relatively new subject in the Swedish curriculum. It was not until 1994 that technology received its own syllabus (Hartell, 2012). Undoubtedly, computer programming is, at least to some extent, a technological discipline, and the technology subject seemed to be an obvious home for this new core content (Nordén et al., 2017). However, the content was added to both the mathematics syllabus and technology, and the exact formulation in technology is ‘[c]ontrolling pupils’ own constructions or other objects by means of programming’ (Statens Skolverk, 2018a, p. 298). This relatively rapid change in the school curriculum has led to a situation where most Swedish technology teachers lack training in the area (Statens Skolverk, 2019).

As Swedish grades 4–6 teachers may be regarded as regressed experts (Liberman et al., 2012), they need to develop both their content knowledge and their pedagogical knowledge with respect to programming to develop their teaching. However, programming in educational research is limited (Kjällander et al., 2016). Although researchers have shown an increased interest in computer programming in schools in recent years, research in programming in the mathematical subject is more prevalent than research in programming in the technology subject (Björklund & Nordlöf, 2021). Moreover, internationally, most studies on tools for teaching programming do not target 4th−6th -grade pupils, focusing instead on preschool children or older pupils (Hill et al., 2015). As children’s developmental levels often depend on their age, it may be difficult to use results from studies in which older or younger children participate. Hill et al. (2015) argue that there is a gap in the existing literature concerning grades 4–6.

As teachers in Sweden have been challenged with a new curriculum and core content that they have not taught before, it is important to find out how Swedish technology teachers currently tackle the task of teaching programming and which pedagogical strategies they use. In addition, research in the area of computer programming in schools, especially in grades 4–6, is lacking.

The purpose of this study is to analyse how Swedish grades 4–6 technology teachers who have taken on teaching the new core content concerning computer programming, starting prior to it being mandatory, teach it. This study addresses the following research question:

  • What pedagogical strategies do teachers use to teach computer programming?

Background

We first describe the theoretical and analytical stances underpinning this research. This section begins with general descriptions of PCK and then focuses on the pedagogical strategies used to teach computer programming. Next, we elaborate on how these pedagogical strategies are used to analyse the study data. This section ends with two related research perspectives: learning and teaching computer programming.

Pedagogical content knowledge

Much previous research into teaching has focused on pedagogical content knowledge (PCK), a concept introduced by Lee S. Shulman, who claimed that research on teaching methods had ignored a very important fact, namely that the methods a teacher uses have much to do with the subject being taught. In addition, specific pedagogy may be required for students to understand certain parts of the content (Shulman, 1987, 2013). Consequently, PCK combines deep knowledge of both content and pedagogy and how these two parts affect each other. Sentance and Csizmadia (2017, p. 490) state ‘[w]hether the teacher is teaching history, science or computer science, these teaching methods would form part of a teacher’s pedagogical content knowledge’. This specialized knowledge grows with experience, and Van Driel et al. (1998) imply that novice science teachers have no or less PCK compared to experienced science teachers.

Teachers’ practices are influenced by various factors, such as their knowledge in areas other than the content to be taught, their beliefs, their prior knowledge and the context (Gess-Newsome, 2015). In design and technology education, Doyle et al. (2019) conclude that it is important to take a holistic approach to truly understand enacted classroom practices. One suggested starting point is to ask four questions: What to teach? Why teach? What about the students (difficulties and misconceptions)? How to teach? (Grossman, 1990). From a Swedish perspective, the answer to the first question offers some challenges, since it largely depends on the teacher. The Swedish curriculum neither regulates what to teach nor the intended learning outcomes, in contrast with curricula in other countries (Funke et al., 2016; Nordén et al., 2017).

In the Swedish case, as new core content has been included in the curriculum, it is relevant to refer to Liberman et al. (2012) concept of the teacher becoming a regressed expert. A regressed expert is a teacher who is an expert teacher of old core content, who is now confronted with teaching new core content. If the new core content differs a lot from the old, the teacher behaves like a novice teacher, becomes inflexible and does not have answers to pupils’ questions. As an example, Liberman et al. describe a teacher being exposed to a new programming language that differs from the old one. However, in contrast to that example and with a few exceptions, the general Swedish grades 4–6 technology teacher has no previous formal programming education (Statens Skolverk, 2019). Hence, it is likely that the teachers, at least with respect to the core content, can be regarded as novice or regressed expert teachers. This makes Grossman’s (1990) questions important to keep in mind and also raises questions about the teachers’ PCK. Within the pedagogic knowledge (PK) domain of PCK, the question of how to teach is essential. In our understanding of PCK, different general pedagogical strategies belong to the PK domain, whereas different content-specific pedagogical strategies may be descriptors of PCK. For instance, classroom discussion is a general pedagogical strategy, whereas different content-specific pedagogical strategies may be required to teach how to program a loop in C++ or Scratch. In this study, our starting point is to examine what pedagogical strategies Swedish grades 4–6 technology teachers use to teach the new core content on programming and, thus, gain an insight into teachers’ PCK when it comes to teaching programming.

Pedagogical strategies for computer programming

The pedagogical strategies reported in the literature range from generic strategies to content-specific ones. Two examples of the first are Papert’s (1999) eight big ideas and Sentance and Csizmadia (2017) claim that many teachers have suggested constructivist activities, such as using examples that are relevant to pupils’ own experiences. Two examples of the second come from Saeli et al. (2010), who describe strategies such as decomposing problems into smaller chunks and explaining a program. In a recent systematic review of effective approaches for teaching computer programming, Scherer et al. (2020) report that visualization or physicality strategies support the effectiveness of modern programming languages (e.g. Scratch), but in collaborative activities, neither feedback-based instruction nor game-based learning were found to be superior. Moreover, successful programming interventions should be customized for different age groups of pupils (Hill et al., 2015). To teach computer programming teachers can provide different learning experiences and teaching practices and adapt their instruction to the specific circumstances and conditions of the learning environment and their pupils.

Prior to Scherer et al. (2020) review, Sentance and Csizmadia (2015, 2017) surveyed 1417 teachers, mostly from secondary schools, to find out what techniques/methods teachers reported as successful for teaching computer science. Five pedagogical strategies emerged, as follows:

  • Unplugged activities or the use of other physical objects.

  • Collaborative working includes pupils working in pairs or larger groups and special teamwork, such as digital leaders who support classmates. Sentance and Csizmadia (2017) explain that digital leaders are ‘pupils who are good at working with technology’ (ibid., p. 486).

  • Scaffolding programming tasks are activities that support the pupils, for example, debugging or expanding a program or making the whole class participate when a program is written.

  • Contextualisation of learning is when teachers relate programming to other aspects of the curriculum or to real life.

  • Computational thinking includes concepts, practices and perspectives.

Through three interviews with children between 8 and 14 years who had created a Scratch program, Brennan and Resnick (2012) developed a framework with three key dimensions and a broader perspective of computational thinking to study and assess the development of computational thinking, as follows:

  • Computational concepts: the process of working with common computer program concepts, for example, loops and conditionals.

  • Computational practices: the process of creating the computer program, for example, reuse, remix, testing and debugging.

  • Computational perspectives: the process of understanding technology, for example, expressing yourself with Scratch, connecting with other Scratch users and questioning technology.

Sentance and Csizmadia (2015, 2017) acknowledge that their theme of scaffolding programming tasks is closely related to the computational practices theme in Brennan and Resnik’s (2012) framework. ‘Debugging’ and ‘remix’ occurs in both scaffolding programming tasks and computational practices (Table 1).

Table 1 Themes developed by Sentance and Csizmadia (2015, 2017)
Full size table

Learning and teaching computer programming

Learning to program is generally complicated (Gomes & Mendes, 2007; Jenkins, 2002) and abstract (Wong & Jiang, 2018). This is found both when studying programming from a maths perspective and from a technology perspective (Gomes et al., 2006). It is also important that there is a planned continuity from primary school, through secondary school to higher education when it comes to learning to program.(Duncan et al., 2014). In general, pupils are not interested to learn programming (e.g. Funke et al., 2016), and negative attitudes towards programming are passed from pupil to pupil (Gomes & Mendes, 2007), although Jenkins (2002) found that some pupils do have a genuine interest in programming.

Computer programming involves skills (abstraction, generalization, transfer and critical thinking) used at different times by the programmer, which also influence the required learning environment (Gomes & Mendes, 2007). The process of pupils who learn to program can be described as four steps, as a code, as a utility program, as a medium of communication and, at last, as a medium of expression (Booth, 1993). Furthermore, learning computer programming involves both generic problem-solving and programming problem-solving, but there is a gap between the two (Gomes & Mendes, 2007). From a teaching point of view, this gap requires a learning environment to help pupils make the transition. Within this teaching environment, help and hints concerning certain aspects of computer programming help pupils bridge the gap. Analysing complete programs and how they work, what strategies are used and what the bugs are or writing programs from scratch are suggested as useful strategies. In the initial stage, completing incomplete programs is also fruitful. Programming patterns, good programming practices and allowing pupils to test principles, theories and reasoning are also part of the learning environment. In addition, research shows that pupils who participate in pair programming gain a higher understanding of programming compared to those working alone (Denner et al., 2014).

Gomes and Mendes (2007) make general suggestions regarding programming, each classroom is a unique setting that depends on systemic and situational factors (Doyle et al., 2019). When introducing programming in school, teachers have to make different choices depending on these factors, which is in line with the notion of PCK. Moreover, Makki et al. (2018) indicate that teachers’ beliefs and ‘computer comfort’ are important for teaching quality (cf. Doyle et al., 2019). The integration of technical equipment will probably add more to consider in the teaching situation, for example, if equipment and support of the same are lacking (Ertmer, 1999; Mason Bolick & Cooper, 2013) suggest that the teacher should always have a backup lesson prepared when technology is involved.

Computer programming also includes different generic choices: which language to use, which digital device to use, a decision about how to teach this new content and which teaching approaches to use (Statens Skolverk, 2018a). There are pros and cons in every choice, and, according to Hill et al. (2015), researchers have not agreed on the best way to start teaching programming, especially in the younger school years. For instance, unplugged activities, on the one hand, help pupils develop an understanding of computer programming since the computer is not used, and the activities involve play or challenges to explore with are short and simple explanations (Bell et al., 2009). On the other hand, the effectiveness of unplugged activities is debated. It is also not clear whether pupils should start with VPL (visual programming language) or TPL (textual programming language) (Meerbaum-Salant et al., 2011).

Useful pedagogical strategies also depend on the content being taught or what to teach (Grossman, 1990). In secondary education, one reported workshop resulted in 20 different answers for programming concepts, such as control structures (loops, conditions and sequences), variables and decomposition (Saeli et al., 2011). As previously noted, the Swedish curriculum does not regulate what teachers teach (Nordén et al., 2017), which raises the question of whether research results from other countries can be transferred to the Swedish setting.

Methodology

This section deals with the study’s design and sample, the semi-structured interviews, the data analysis and the research ethics.

Design and sample

Qualitative methods offer an effective way to explore a single idea or problem where no causes are related to each other or where different groups are to be compared. We chose an explorative qualitative design since the research data are limited (Hill et al., 2015). A change in the Swedish curriculum has required all maths and/or technology teachers to teach programming. The sample for this study was based on the following inclusion criteria: the teacher should have a certificate for teaching technology to grades 4–6 (10–12 year-olds) and have taught programming in those grades, prior to being included in the study and prior to it being mandatory in the Swedish curriculum. This is described as a purposive sampling (Bryman, 2014; Robson & McCartan, 2016); hence, the sample was intentionally biased, since teachers who had already begun teaching computer programming were actively sought to determine what pedagogical strategies they use. However, this sampling process was challenging, since the study was conducted as the change in the curriculum took place (i.e. programming being mandatory). Finding teachers who had already begun teaching programming to pupils in grades 4–6 was difficult.

More than 20 school principals in two Swedish cities were contacted via e-mail, which resulted in one teacher. A post was made in a Swedish Facebook group of maths teachers with approximately 2500 participants, including some teachers of technology in grades 4–6, which resulted in 13 teachers. Finally, a total of 14 teachers were included in the study. However, although the intention was to only interview teachers with teacher certification, one teacher lacks this requirement. One reason for retaining this teacher in the study is that it reflects the general population of teachers in Sweden, as not all are qualified technology teachers. Moreover, as a former game programmer, this teacher’s background differs from the other participants’ backgrounds. Two participants were full-time teacher trainers at two different science centres. These centres are kind of experimental workshops where teachers and pupils can find inspiration for further scientific studies. Stakeholders in these science centres are often municipalities. Three participants were part-time teacher trainers responsible for increasing digital skills, partly in programming, at their schools. During the search for participants, the criterion of having taught programming was the most difficult to meet, and hence it became the most dominant inclusion criteria. Table 2 shows the backgrounds of the included teachers.

Table 2 Study participants
Full size table

Semi-structured interviews

As this is an explorative study, semi-structured interviews were chosen to generate data about the different strategies teachers use when teaching programming. During a semi-structured interview, active listening contributes to the ability to ask follow-up questions (Kvale & Brinkmann, 2009). All interviews were audio-recorded. In total, 14 semi-structured interviews were completed, including 3 face-to-face interviews and 11 telephone interview. The latter choice was made due to the geographic distance between the researcher and the teacher. All interviews were conducted by the first author. The first part of the interview framed the interview, as questions about teaching years and teaching certificates were included. Hence, the first part contributed to creating a relaxed environment (i.e. ‘Warm-up’ Robson & McCartan, 2016). The second part of the interview included questions concerning pedagogical strategies. The interviews followed a guide with possible follow-up questions depending on how the interviews progressed. The guide was discussed by the first and second authors and tested during the first three interviews. It was determined that no changes were needed.

Data analysis

In qualitative research, it is important to know one’s data to familiarize oneself ‘with the depth and breadth of the content’ (Braun & Clarke, 2006, p. 87). For this reason, the 14 interviews were transcribed verbatim in NVivo 12 Pro, and the material was read and listened to several times. The data formed approximately 10 h of digital audio with roughly 43,000 words.

As Scherer et al. (2020) review was not published until after this study was conducted, the themes in Table 1 (Sentance & Csizmadia, 2015, 2017) acted as the deductive analytical framework during the first data analytical process. However, to define examples of the fifth pedagogical strategy, computational thinking, the descriptions in the original framework had its limitations. Therefore, we also turned to the framework presented by Brennan and Resnick (2012) to clarify how to interpret computational thinking. During this process, it became obvious that even though Brennan and Resnick’s descriptions were used, we encountered a definition issue, since ‘debugging’ and ‘remix’ was present in both the scaffolding and the computational thinking strategies. Therefore, a choice was made in the analytical process. If the teacher discussed ‘debugging’ and ‘remix’ in whole class instruction, it was sorted into Scaffolding. If the teacher talked about how he or she taught ‘debugging’ and ‘remix’ with individual students, it was sorted into Computational Thinking. However, participants do not discuss ‘remix’ in whole class teaching.

Nevertheless, in the interviews the teachers made numerous statements that did not fit the presented analytical framework. Consequently, these data were analysed inductively to provide additional pedagogical strategies to fit the data. Data were coded and different codes were grouped together under a heading with a description. During this process, three additional themes (i.e. strategies) were constructed, as follows:

Do-it-yourself (DIY): Within this theme, the pedagogical strategy is that to learn how to program, pupils need to do it themselves. What the pupil programs, for instance Blue:Bot®, Scratch or robots, is not the focus here as long as each pupil develops the capability to program. Hence, being a spectator is not enough to learn programming. Included in DIY are expressions where the teachers state that some part of the programming process is done individually or as pair programming, with pupils changing roles so that every pupil has access to the computer. Camilla explains exactly how and why DIY programming is important: ‘Well, we first do something together that we all talk about, and then you have to reach down into yourself. It makes everyone try. Should they do it in a group, then there is one who grabs the computer, and then the others sit and watch. So, for everyone to be able to come and try and begin, I think it’s good that they work by themselves, that they dare to test and see what happens when you do this or that’.

Gamification: Within this theme, the pedagogical strategy concerns different competitions and/or elements of game theory, for instance medals and levels. Hence, gamification is described as one possible way to increase motivation within programming tasks (i.e. extrinsic motivation). Jack explains that the pupils have two opportunities to ask the teacher: ‘I use gamification in my teaching, so I gamify different elements. In the younger classes, I hand out something I call auxiliary crystals. The pupils get two crystals each per lesson, and then they have to sacrifice one crystal for me to help them, and then it will not be the whole world if you have to ask a question to the teacher. It may sound strange, but this makes them figure out when they actually need help or if they can look again. It might just be a spelling mistake in the code’.

Progression: Within this theme, the pedagogical strategy is to start with the easier parts of programming and move towards the more difficult parts (e.g. start with unplugged activities and move to text-based programming or choose Scratch before JavaScript). Hence, the pedagogical strategy is about preparing pupils for the next, more advanced, step. For example, Bella describes how progression takes shape: ‘We start with unplugged programming. I have prepared the whiteboard with laminated cards, and then the pupils will program me to make a sandwich. Then we run the courses in Code.org because then they get a pretty good foundation in how to manoeuvre the sprite on the screen. The programming becomes slowly and gradually more difficult. […] then we move on to Scratch’. Furthermore, there are individual statements which, when combined into a whole, give a picture of how progression takes place in that particular classroom. The example above comes from two different statements.

Another researcher (a certified technology teacher with a PhD, not the third author) helped to confirm the deductive data analysis. The researcher was given the coding scheme with examples of explanatory text (i.e. examples that fitted each strategy). A sample of 20% (n = 51) of the statements was coded, and the Kappa statistic was performed to determine consistency between the first author’s and the researcher’s categorizations, resulting in over 90% consensus. During the inductive step, the first author analysed the data and formulated three new themes. The second author compared all the coded statements with the themes and descriptions with a satisfactory result. Both these analytical steps revealed that within a teacher’s statement there may be elements of several themes.

Research ethics

We followed the guidelines for good ethical research practice of the Swedish Research Council (2017). All the participants were given all the required information and gave their informed consent. In the article, the names are pseudonyms, and the only information provided here concerns factors that we think are important for the reader to know (e.g. education in computer programming). Also, the fourteen participants have been given fictitious names following the alphabet from A-N. Male nicknames for male participants and ditto. Only the first author knows who the participants are, their names and where they work. In relation to ethical guidelines, the Facebook post did not mention joining a study but asked if anyone had started teaching programming in a primary school. Not until later, in a private chat in Messenger was the reason for the Facebook post revealed. To further protect the participants, the Facebook post was deleted when a sufficient number of participants had accepted the invitation to participate.

Results

The deductive analysis confirms that the pedagogical strategies presented in Sentance and Csizmadia (2015, 2017) are stated by Swedish grades 4–6 technology teachers teaching computer programming. The data analysis also reveals that three additional pedagogical strategies are used. In Table 3, the pedagogical strategy computational thinking is divided into three parts, as Brennan and Resnick (2012) describe them. However, when summarizing each column, all three parts of computational thinking are counted as one. As can be seen, the number of pedagogical strategies each teacher describes (5–7) varies, as well as how often a pedagogical strategies is mentioned (2–14).

Table 3 Pedagogical strategies mentioned by the teachers
Full size table

Collaborative working

The teachers stress two things concerning collaborative working: communication and different forms of collaboration. As pupils work in pairs or larger groups, they communicate to solve the tasks, and pair programming, for instance, supports language development and the pupils’ ability to communicate. Grace explains the importance of collaboration: ‘They have worked two and two because I think communication is important. It is easier to come up with a solution when discussing something together’.

Collaborative work is described in two ways: first as an easy form of collaboration, for instance a group task where pupils work together to solve a problem. The task ends when the problem is solved and does not evolve further. However, in the second way, pupils are engaged in more advanced collaborative work where the task evolves and in some cases engages the whole class or the entire school. Camilla explains that a pupil uses the BBC micro:bit to create a single-sided dice, compares the code with other pupils, and then several pupils work together to create a fully functional dice. The task begins with a single pupil programming their micro:bit, and it ends with collaboration between many classmates. Another advanced collaborative working task is described by Irene. She talks about how a group of pupils collaborate and create games for another group. For the other pupils to play the game, instructions must be given. These instructions are written in Scratch, and the instructions are communicated by running the program. This, says Irene, make the pupils aware of how accurate the instructions must be for another person to play the game. Collaboration between the groups, in this case, takes place digitally.

However, advanced collaboration also means collaboration on tasks by the entire school. When Jack first started programming with pupils, they built robots and programmed them with a VPL. Then, the robots fought each other in ‘death battles’, and the robot who managed to stay ‘alive’ was the winner. The whole school participated in this activity.

Unplugged activities

Unplugged coding, or analogue coding (a more commonly used label in Sweden) is used to introduce computer programming. It can be defined as activities used to learn coding without using a computer or digital device (Bell & Vahrenhold, 2018).

When Camilla talks about unplugged coding, she notes that it is important to be accurate and clear in computer programming. She also emphasizes that the programmer must understand how a loop, commands that are iterated, facilitate programming and make it easier when that bit of code just has to be written once. Liam believes that every grade in his school uses both analogue and digital coding: ‘Well, we probably do that in all grades. But we run coding digitally in almost every grade, too’.

A common task at the beginning of programming education is also to program the teacher or a fellow pupil to do something. This is often carried out with laminated cards with symbols (e.g. arrows indicating in which direction the cardholder should walk). One arrow is equal to one step, two arrows to two steps and so on. Bella describes analogue coding as a beginner activity where the pupils have to program the teacher to make a sandwich. Nora makes it clear that deep understanding of how programming works is essential: ‘And then we have done a lot of practical and concrete that is not just about the digital but the basics, so you understand how programming actually works’.

Scaffolding programming tasks

To give the pupils erroneous code that needs to be corrected is a strategy that Camilla and Nora use. Emma emphasizes that this strategy is useful: ‘In programming, you will learn so much the times that it does not turn out as you intended, bugs you know …’.

Also, within a task, pupils code together in the whole class and write the same code that the teacher does. As a novice Scratch programmer, Anna explains that she taught herself first and then told the pupils how they could complete the task: ‘I learnt almost at the same pace as the pupils’.

Other teachers also mention their inexperience. Camilla explains that she and the pupils learn simultaneously: ‘You learn on the way’. Nora observes how pupils understand programming quite well: ‘At the end, the pupils were even better than us’. However, there is a difference between these three teachers and examples. Camilla and Nora are novice computer programmers whereas Anna programmed in both C++ and Java during her teacher training.

Another way to scaffold programming tasks is to give the pupils code to complete. For instance, Henric suggests how the program can be extended, whereas Irene gives the pupils more freedom, with no hint of how to expand the program’s function. She explains: ‘And so they can choose to be creative and extend the program, if they come up with other ideas’.

Furthermore, Henric remarks that boys are especially enthusiastic and speak about what they will program. He has to be quite clear and tell them that they will not be able to achieve something in the style of ‘Call of Duty’.

Contextualisation of learning

Although Jack teaches only technology, he tries to relate programming to a large part of the core content in that school subject and describes how he has worked with other teachers and used programming in crafts, for example. Cross-curricular work, where the teacher combines core content from many subjects in a theme, is common. In maths and technology, where programming is part of the core content, cross-curricular work is facilitated. Henric explains when technology and maths are combined: ‘Sometimes when we have worked on projects, I have used maths lessons too, but I do not think the pupils think “now we are doing math”. I often teach in a cross-curricular way’. Dora explains how LEGO windmills can ease cross-curricular work with technology and physics, and Liam mentioned that his school has at least three cross-curricular themes in every school year that combine several different school subjects. Emma suggests that the teachers can use photo algorithms to introduce ‘Thinking like a computer’ in physical education and health, while Jack mentions that programming does not belong in every school subject.

The Swedish curriculum is quite extensive, and Bella therefore use cross-curricular work to find time to manage the core content. Kate uses contextualization in many ways. She describes both the use of Scratch and ScratchJr (a simpler version of Scratch) and how to connect each software to the subjects of Swedish, maths and technology. She also explains how you can use other technologies, like a robot, to teach in a cross-curricular way: ‘Not only do I use Scratch in maths and technology; last year, we programmed in Swedish. We wrote stories and then programmed them in ScratchJr and Scratch. We have also used Scratch when we work on language development. Then they were programming stories to explain words in Scratch, such as what a square looks like and so on. In Sphero, they have had to work with maths assignments linked to the technology, for example, geometric figures or multiplications’.

Emma points out that it is important to work with programming in a context and connect it to a well-known area and gives an example: ‘What would it look like if we had lunch right in the morning? It has to come in a special order.’

Computational thinking

In the computational thinking strategy, the analysis stems from the three dimensions of computational thinking presented by Brennan and Resnick (2012): concepts, practices and perspectives. Regarding computational concepts, the pupils learn to use common computer program concepts, for example, loops, conditionals and variables, where ‘loop’ is the most common concept the teachers talk about. Camilla explains that her pupils have some trouble with a mathematical block in micro:bit, but she uses a dice to clarify the misconception: ‘There is a part in micro:bit that is difficult: mathematical blocks, for example, when choosing from 0–4 – that zero is also a number. The pupils have trouble understanding that zero is a number, as zero stands for nil and zero is “nothing”. It’s hard to understand. If you have a dice, then zero is a side of the dice’.

Computational practices like remix, test and debug, are commonly mentioned by the teachers. After the pupils have tried some of the things you can do in, for example, Scratch, they often get to test the blocks freely, in other words, to play. Anna explains: ‘… then the pupils got to test themselves, what can be done to get acquainted with the program…’.

Irene remarks that remix is useful. When her pupils find a piece of a program they want to use, she encourages them to ‘look inside’ so that they can see the code and use the part that they want: ‘They may not remix the entire program, but they can go into the code and see how it looks. They can take what they think they can use so it is usable’.

In contrast to the other perspectives in computational thinking, computational perspectives are only been expressed by Jack. His pupils, who do not use Scratch, can find help by remixing, but it is not as easy as remix in Scratch. His pupils have to struggle a bit more to find the appropriate code to insert in their program, in other words, search the Internet and connect to other users.

Do-it-yourself (DIY)

Do it yourself (DIY) can be done anytime during the teaching process. On the one hand, Camilla explains that she first lets the whole class program together and then the pupils program on their own. ‘Programming alone’ is a pedagogical strategy where every pupil goes on a keyboard and tries. This is to ensure that every pupil tries programming at least once. After Camilla’s pupils have programmed on their own, she pairs them and lets them program together. On the other hand, Kate lets the pupils program on their own after they have been programming in pairs. She emphasizes that this happens when the pupils have worked in pairs for a very long time. In fact, she affirms they have been working in pairs for ‘several months’, and the pupils are ‘very comfortable with programming’. Henric argues that the pupils working in pairs are the ones that can work in pairs. He makes it clear that not every pupil can handle collaborative working, and only the pupils who are able to distribute the tasks between themselves so that they are balanced are allowed to work in groups. In other words, in Henric’s case, DIY seems to be the solution to a problem: pupils work on their own because they cannot collaborate with others.

However, the two full-time teacher-trainers Emma and Maria do not recommend DIY. Emma advocates that pupils should always work in pairs, and Maria believes that pupils should be grouped in groups of at least two. Maria explains how good teamwork with two pupils can be achieved, as one pupil is obliged to use the keyboard, and the other pupil is responsible for verifying that they have completed the assignment. Emma, on the other hand, emphasizes how pair programming is important to improve the skill of problem-solving, when two minds exchange ideas with each other. She explains a task: ‘Give the pupils a Blue-Bot®, a transparent card mat with a grid, small pictures with a target and some obstacles. Let them place the target and the obstacles under the mat in a square of their choice. And then the pupils have to construct a program so that the Blue-Bot®, moves on the mat, reaches the target and, of course, avoids the obstacles. There are many different ways to reach the target, and it becomes so clear that there are many ways to complete the task, but no route is more correct than the other’.

The possibility to use DIY depends on how many digital devices are available. All Jack’s and Dora’s pupils have a digital device; hence, DIY is available as a pedagogical strategy. However, when digital devices are few, Henric, for instance, cannot choose what to do. He has to organize the pupils in larger groups even though ‘if they are four in a group, two of them are always sitting in the background and are passive’. He continues: ‘and that is a problem if they are in pairs too; one is the doer and the other is just looking and follows quite uninspired’. Still, he ensures that every pupil gets a chance to work on their own. Equipment also makes DIY context-dependent. For instance, Grace lets pupils work in pairs while working with LEGO Mindstorms due to lack of equipment. However, when working with micro:bit, there are enough digital devices for every pupil to have one each.

Gamification

When Jack began teaching programming in technology he started a contest, a robot war death battle, inspired by the TV series ‘Robot Wars’. His pupils built robots and programmed them with a block-based programming language. Finally, they gathered in the main hall, and the robots battled each other. With respect to gamification, with his older pupils Jack employs a system with rewards: every time a pupil finishes a task, they get a reward. According to Jack, this makes them try harder to complete a task. However, gamification is also described as an aid to individualise the teaching process: ‘I have introduced a small system now in grade 4. Next week, I have them help each other, because if they help others they learn to repeat and think about how to explain; and they should wear different hats. It will look really ridiculous, and they will have different stickers on what each one can do, so you can walk around to each one and ask, “Can you help me with this because I see that you can … You’ve got the sticker for this”. Then all the little teachers become one another. I believe in teaching and helping each other’.

Jack also recalls when he had a pupil who hated everything but horses. During game programming lessons in technology, he managed to inspire her, and finally she programmed a really good horse game.

Although Jack makes the most explicit references to gamification, Liam also talks about a contest between two pupils and their Blue-Bots®. The pupils had to cover their eyes while a third pupil placed laminated papers with geometric figures under a checked transparent mat. When the pupil was done, the two competing pupils turned to look at the mat, and the task was to quickly program their robots to ‘catch’ the figures. The winner was the pupil who had ‘collected’ most pictures by running over them.

Progression

Both Irene and Henric stress the necessity of learning from scratch to understand the basics in programming before proceeding with harder things. Irene emphasizes that the pupils need thorough instructions, because they think it is difficult to program, i.e. to arrange the pre-programmed buttons in the correct order. She recalls that she talks a lot about ‘sequence’. According to Bella, starting with something easy and slowly progressing to harder tasks in programming is a winning concept. She emphasizes that mindset is important and that playfulness gives knowledge. To start simply, Dora uses pictures, PowerPoints and movies. This pedagogical approach also helps pupils understand new words in programming.

Slow progress from easy to hard is described by Grace. In the beginning, Grace often starts with a mind map to find out what her pupils already know about computer programming. As her pupils move on to unplugged programming, Grace explains that it makes the pupils aware that every action has a result. Her pupils then continue with Scratch. Nora uses a similar approach but begins by telling her pupils how things in our daily lives are controlled by programming.

Progression also depends on the available software. Dora is the only teacher who once had the budget to buy textual programming software that slowly increases in difficulty. According to her, the pupils loved it. One of her pupils completed the tasks so fast that she did not get a chance to help him due to her not having completed the task yet. In Dora’s case, she admits that she did not understand programming that well and that this pupil used the suggestions from the teacher’s guide when he was unable to complete a level. Dora now uses the common block programming language Scratch. Kate explains that due to the available budget progression depends on available freeware.

Five teachers describe detailed plans of how pupils should progress in computer awareness increase their understanding of computer programming. Three of them, Kate, Liam and Grace, are advanced teachers in computer programming and have created the local curricula for their schools or, in Kate’s case, for the whole municipality. Maria is one of the full-time teacher trainers and therefore has an understanding of teaching programming in different grades. As Jack teaches technology for the whole school, i.e. grades 3 to 9, he has an overview of the Swedish compulsory school system.

All teachers, except Jack, use block programming languages for pupils in grades 4–6. Jack uses a TPL from grade 3, arguing that the TPL is easy to learn: ‘It is so simple that pupils can easily find information to find the bits and pieces that could be used in their codes. I notice that the older the pupils get, the easier they find codes and can test and so on’. Following this, Jack’s pupils progress in computer programming by switching to more complicated TPLs, and the tasks gradually become more difficult.

Discussion

Within this sample of teachers, the five original pedagogical strategies, together with the three new ones, form an outcome space of which pedagogical strategies Swedish grades 4–6 technology teachers use as they teach computer programming. As all these strategies are scrutinized, different choices seem to guide the teachers. Below, we elaborate on these choices concerning the progression strategy that seems to permeate the others. The discussion then continues concerning gamification and digital leaders. This section ends with a methodological discussion in which computational thinking is problematized.

Unplugged to plugged activities

At first it seems like there are two different domains concerning unplugged and plugged. The first domain concerns the content (what), while the second domain is the form (how). Within progression and the second domain (how), one active choice is between unplugged and plugged activities. This choice is situated within the pedagogical domain of PCK (Grossman, 1990; Sentance & Csizmadia, 2017; Van Driel et al., 1998). This choice is also always present in a teacher’s mind` (e.g. to include a device to teach something). However, the difference between a general choice, for instance to include a calculator in a maths classroom, and this choice is the content itself. Here, programming is the content, i.e. what the pupils are expected to learn about. In, for instance, Swedish grades 4–6 maths classrooms, programming is used as a method (how) to learn maths. However, in Swedish grades 4–6 technology classrooms, what and how merge, thus manifesting an active choice. As learning computer programming is difficult (Gomes & Mendes, 2007; Jenkins, 2002), unplugged activities can facilitate learning. Several teachers in the sample use unplugged activities to familiarize pupils and introduce them to computer programming. Unplugged and practical activities are also common in Sentance and Csizmadia (2017), who explain that the teachers who participated in their study assumed that physical participation was helpful. This is affirmed in the current study: for instance, Nora explains that lots of ‘practical and concrete’ activities make the pupils understand programming. However, the choice to begin with unplugged activities also includes a step towards plugged activities. This step also includes different choices, and the teachers in this sample describe a move to Blue Bot®, easy visual programming languages (VPL) like ScratchJr, more complicated VPLs like Scratch,or the BBC micro:bit, which also can be coded with several TPLs. However, in contrast, Jack, the teacher with a game programming background, uses plugged activities and TPL from the beginning. We cannot state whether these general steps from unplugged to plugged and VPL to TPL are the most appropriate steps to take when teaching programming, since it is not the purpose of this study to draw such conclusions. However, no consensus exists in the research literature on whether pupils should start with VPL or TPL (Meerbaum-Salant et al., 2011). There is a risk of confusion when comparing the progression strategy with the computational thinking strategy. The strategies might seem similar, but computational thinking represents a problem-solving process for describing, analysing and solving problems with a computer (Csizmadia et al., 2015).

Learning and teaching as a social and individual process

Our starting point is that we all agree that learning is a social or individual process that takes place in a formal or informal setting. The formal setting is the classroom in which the teachers’ described teaching takes place. The settings are affected by different situational factors and each teacher’s beliefs (Doyle et al., 2019). When moving on from focusing on the content (e.g. VPL or TPL) towards strategies with different choices concerning progression and variation, different general pedagogical strategies are found. To us, this is strictly rooted in the pedagogical domain of PCK (Doyle et al., 2019; Grossman, 1990), where teachers use all their knowledge, skills and experience to facilitate a learning environment.

In general, the teacher is the person with the most content knowledge who can therefore support the pupils in the best way. However, our data suggest, that these teachers most often describe themselves in terms of being regressed experts, being confident teaching the technology subject but insecure teaching the new core content programming (Liberman et al., 2012). Due to the change in the Swedish curriculum, most grades 4–6 technology teachers may be viewed as regressed experts, since they lack training in programming (Statens Skolverk, 2019). This is also true within the sample; the level of formal programming education is low, although these teachers have many years of teaching experience. This fact may in itself mean that teachers do not have their usual ability to decide when each strategy or a mix of strategies is most useful and/or effective.

What the teachers describe in terms of progression or variation is a move back and forth between scaffolding programming tasks (whole class), collaboration (in pairs or groups) and DIY. The teachers emphasize that each pupil has to be able to program on their own and that every pupil must have individual access to the program or a computer/device to gain an understanding of coding.

On the one hand this makes sense, since being able to program a computer includes developing a set of skills (Gomes & Mendes, 2007). The outcome, for instance, of the skill of thinking in the abstract, is individual. Research also shows that pupils who work on their own computer complete exercises more quickly than those using pair programming (Lewis, 2011). We also hypothesize that one underlying factor here is the Swedish grading system. From grade 6, it is mandatory to grade each pupil individually. The teachers must know what each pupil can or cannot do to grade them. However, that is not why teachers stress the individual part. Instead, they refer to other values within a pedagogical process, for instance the importance of trying, doing something on one’s own, stepping up and using a keyboard or device.

On the other hand, working alone does not result in a higher understanding of programming compared to pair programming (Denner et al., 2014). Pair programming has been recommended as an effective method (Adams et al., 2004), and all the teachers in our sample use it. In contrast to the individual perspective, the teachers stress communication, which can only be facilitated by collaboration. One task with two or more minds arguing for different ideas, approaching one or several solutions and discussing programming are key to understanding the importance of communication. Situational factors (Doyle et al., 2019) also come in play, such as a lack of devices forcing teachers to make specific pedagogical choices. However, a recent review shows that collaborative activities are not a superior approach for teaching computer programming (Scherer et al., 2020). This move back and forth between the whole class and the individual can also be viewed in a larger perspective. In Sweden, 93% of households have a computer (Internetstiftelsen, 2019), and digital knowledge is a skill emphasized by the European Union (EU, 2006). However, is it possible to imagine citizens’ digital knowledge as a shared skill?

Gamification and digital leaders

Besides a few examples from one teacher, every comment concerning gamification comes from Jack, the teacher with a game programming background. His background enables him to give feedback on how pupils have designed the code. His contacts with the gaming industry allow him to sometimes engage an outside industry jury with games reviewers who can assess the pupils’ programming projects. In his descriptions, gamification is used to raise motivation, but by using medals, prizes and new levels it is possible that not all pupils are encouraged by competition-like elements (Buckley & Doyle, 2016). However, in light of what is known, for instance, that pupils are interested to learn programming (e.g. Wong & Jiang 2018) and that negative attitudes are passed from pupil to pupil (Gomes & Mendes, 2007), the fact that Jack is an expert teacher (Liberman et al., 2012) needs to be highlighted, and Jack thinks that this strategy works.

Jack’s description of gamification does not completely correlate with the definition of gamification in the literature (Kapp, 2012), in which medals, prizes and new levels are not enough to gamify a learning environment. For instance, Hamari et al. (2014) acknowledge that gamification is defined as ‘a process of enhancing services with (motivational) affordances in order to invoke gameful experiences and further behavioral outcomes’ (ibid., p. 3026). Does this matter? Or is the fact that game-based learning is not a superior approach for teaching computer programming important (Scherer et al., 2020)? It seems that the main concern the school system has currently is to get the pupils interested in computer programming, so perhaps more Jacks are needed.

It is apparent that this kind of gamification makes it possible to foster digital leaders. They exist in Swedish classrooms, and, according to our teachers, are most often pupils who complete the programming task quickly and correctly (Sentance & Csizmadia, 2017), gain programming knowledge swiftly, finish their code and then help their classmates. Consequently, these pupils soon have more content knowledge than the teacher. Although our sample includes teachers who are interested in computer programming, digital leaders may still be those who have the most knowledge about programming in the classroom. Jack encourages his pupils to become digital leaders. A sticker on the pupil’s hat confirms that they are a master in that special area and makes the pupil proud of what they have accomplished. Additionally, this means that the pupils can share their experience and help their classmates. However, some pupils may never get a sticker, and thus, the stickers become a way to assess the pupils. Sentance and Csizmadia (2017) describe digital leaders as pupils who complete a task fast, but by adding Jack’s type of gamification, each pupil can be proud of what they have accomplished.

Methodological discussion

From a methodological perspective, we acknowledge that the sample is biased. However, it was neither our intention to have a representative sample, since the inclusion process took place prior to the curriculum change, nor to statistically generalize the results (cf. Bryman, 2014; Robson & McCartan, 2016). The sampling process took time, and it was impossible to strictly follow all the inclusion criteria. Thus, the sample included 14 interested technology teachers, of which 2 did not have a teaching certificate, although one was close to completing it. Also, five of the certified teachers were teacher-trainers. Hence, they help educate their colleagues. However, the participants’ teaching experience and formal programming education differs. We acknowledge that this sample does not represent the population of Swedish technology teachers who teach programming in grades 4–6. They belong to a group of technology teachers amongst the first to teach programming, and they began their teaching prior to it being mandatory.

A possible concern is the deductive analytical framework. At first it seemed straightforward, but as the analytical process progressed, different aspects needed clarification, as highlighted in the methodology section. One issue concerned computational thinking. In line with Sentance and Csizmadia (2015, 2017) we also turned to the framework by Brennan and Resnick (2012). These clarifications during the analytical process resulted in an analytical framework that was possible to use but at the same time impacted on the deductive analysis. The choices we made for the analytical framework affected the outcome within the original themes (Sentance & Csizmadia, 2015, 2017). One particular choice concerning debugging became an integral part of this clarification due to debugging being included in two different themes. A critical issue that emerged simultaneously was how to regard computational thinking: was it a pedagogical strategy or a learning outcome? In addition, we should keep in mind, when discussing aspects of the computational thinking pedagogical strategy, that Sentance and Csizmadia (2015, 2017) have, like us, a teacher’s perspective. This is not the case with Brennan and Resnick (2012), who researched pupils’ development of computational thinking. What is more noteworthy is that computational thinking is not mentioned at all in the Swedish curriculum (Statens Skolverk, 2018a), in comparison to the English curriculum where parts of computational thinking can be found as a learning goal (Funke et al., 2016).

A pedagogical strategy can be exemplified by how teachers facilitate learning something (what) (Grossman, 1990); sometimes it is a general pedagogical strategy and sometimes a content-specific pedagogical strategy (Shulman, 1987, 2013). However, the difference is sometimes difficult to determine. For instance, collaborative work is a pedagogical strategy within the PK domain of PCK; it is not by its nature content-specific, and the presented themes are general pedagogical strategies within the PK domain rather than examples of PCK in computer programming. However, if we return to the similarity between how and what, one theme, computational thinking, is highlighted. Concerning computational thinking as a pedagogical strategy, care had to be taken regarding how and what with respect to the deductive analytical matrix. However, as the data were scrutinized, no evidence of what emerged, and the teachers were consistent in their descriptions. The deductive analyses show that they refer to computational thinking as a pedagogical strategy. This firmly places the pedagogical strategy within the PCK domain. However, compared to the other seven themes, we consider the label computational thinking somewhat misleading, since it also is an intended outcome during the teaching/learning processes. For instance, no one would describe a pedagogical strategy in biology as photosynthesis if the intended learning outcome is to learn something about photosynthesis. Instead, different pedagogical strategies are used, for instance collaborative work and balancing chemical equations.

Furthermore, as the data were scrutinized, expressions that could be coded as scaffolding programming tasks were few. In Sentance and Csizmadia (2017), 125 text excerpts were coded as scaffolding programming tasks, almost a quarter of the analysed sample. In our 10 h of interview data, 15 scaffolding statements were found. Different methodological approaches may cause this difference, but another possible explanation is the ambiguity of boundaries between the themes of scaffolding programming tasks and computational thinking, which Sentance and Csizmadia (2015, 2017) admit are closely related. The scarce text excerpts and the unclear description of how these two themes are separated in Sentance and Csizmadia (2015, 2017) made them difficult to analyse. However, during the analytical process, including both the deductive and the inductive parts, two separate researchers validated the analytical process with satisfactory results.

Concluding remarks and implications

The 14 Swedish grades 4–6 technology teachers included in this study describe eight strategies they use when teaching programming. Five of these were reported by Sentance and Csizmadia (2015, 2017), and three additional strategies are formulated here. Most pedagogical strategies used are general, thus providing evidence that the teachers are familiar with them (PK domain) and use them as they teach this, to them, new content. However, in light of the new task of teaching computer programming in Swedish schools, most of the included teachers are viewed as regressed experts, thus showing lower PCK regarding programming than in other areas. This means that, although they may be able to use general strategies, they may have difficulties seeing when and how these strategies are best used. This, of course, is expected, as they only recently had begun to teach programming. However, this study again addresses the importance of general pedagogical strategies, as well as topic-specific ones, as content is to be taught and learnt.

With that said, practice addresses much of this new content, which is also taking place in Sweden as in-service teacher training to increase content knowledge (CK domain). This study also implies that, for practising teachers, it is important to discuss not only if a loop is important but how to teach how to create a loop (PCK domain). Regarding the research implications, this study implies that the different pedagogical strategies used within this field of research can be considered as different levels (general vs. content specific). This reflects ambiguity and the fact that a comparison to the existing body of research literature reveals that there are multiple sources discussing these issues. Providing a more complete picture of these different levels and what they entail both in general and concerning particular content, would be fruitful. In such a process, it would also be useful to understand the actual teaching taking place, considering what happens in classroom practice and taking all the systemic and situational factors into consideration.