Learning programming practice and programming theory in the computer laboratory

ABSTRACT

Learning in the computer laboratory is an important component when students learn computer programming. In this article, we analyse empirical data on novice students working in pairs in the laboratory. Using an approach inspired by phenomenography and variation theory, we specifically focus on how students’ learning of theory and their learning of practice interact. We found that theory-oriented and practice-oriented actions play different, but complimentary and closely intertwined roles in students’ learning. In particular, we discuss that students’ frequent switches between practice-oriented and theory-oriented actions create a variation that is helpful for learning. This variation adds to the variation the teacher creates. Finally, we discuss how and why frequent switches are important for the successful learning process and we suggest a couple of ways to make it more likely that students make such switches when working with assignments at the computer.

KEYWORDS:

• Learning to program
• theory and practice
• phenomenography
• variation theory
• learning process

I. Introduction

This article investigates how novice programming students’ learning of theory and learning of practice interact during learning sessions in a computer laboratory. Many study programs in higher education include a mandatory introductory course in computer programming. These courses are experienced as difficult by many students, as reflected in high failure and dropout rates (Kinnunen and Malmi 2006; Kinnunen 2009; Sorva 2013; Luxton-Reilly et al. 2018; Robins 2019).

A common activity in computer programming courses is learning sessions in the computer laboratory, where students work with programming assignments intended to help consolidate their theoretical understanding of programming and to train the skills to solve programming problems in practice. The relation between theoretical understanding and practical knowledge is emphasised by Lahtinen, Ala-Mutka, and Järvinen (2005) who found a strong correlation between understanding of core concepts and practical knowledge among programming students.

Laboratory-based learning sessions are common in science education as well (Psillos and Niedderer 2002). However, both in programming education and science education it has been observed that the learning outcome of such sessions often is unsatisfactory and that a key reason is a misalignment between the learning of theory and the learning of practice (see e.g. von Aufschnaiter and von Aufschnaiter 2007; Eckerdal et al. 2007; Holmes et al. 2017; Séré 2002).

A conclusion of these results is that the interaction between learning of practice and learning of theory during the laboratory session is crucial for the learning outcome. The work presented in this article has its focus on that interaction in the context of programming education. The aim is to better understand the dynamic learning that takes place during students’ laboratory work, and thus to gain insights about what is required in order that learning of practice and learning of theory during laboratory work can support each other mutually. Results from the same study have previously been presented for example in (Eckerdal, Berglund, and Thuné 2022) where we focused on stages in the learning process and what characterised successful and less successful processes. In the current article, we have taken the analysis further to understand the relation between learning of practice and learning of theory, and the role of variation in this process.

We have investigated how students go about working with programming assignments in computer laboratory sessions in introductory programming courses. For the analysis of the data, we have used an approach based on phenomenography and variation theory (Marton and Booth 1997; Marton 2014; Marton et al. 2004). To that, we have added components of analysis of how the students shift between practice-oriented and theory-oriented actions when they work with laboratory assignments, and how that affects the students’ learning of both practice and theory. Our overall research question is: How do students’ learning of theory and learning of practice of computer programming interact during learning sessions in a computer laboratory?

II . Related work

Some studies from computing education research have investigated how different students approach their learning to program. In a statistical study, Umapathy, Ritzhaupt, and Xu (2020) found that undergraduate students ‘most favorably employ a deep strategy approach for learning computer science’ (662), while they at the same time are driven by surface motive to learn such as getting high grades, however not including rote learning. Several phenomenographic studies have investigated students’ experiences of what it means to learn to program (Booth 1993; Eckerdal, Thuné, and Berglund 2005; Stamouli and Huggard 2006; Chou, Tang, and Tsai 2021). Common findings between all the studies are that some students experience learning to program as being only about learning the programming language or the syntax, whereas for other students the experience of what it means to learn to program includes also more complex aspects, such as learning to solve problems. Different ways of experiencing what it means to learn to program might lead to different ways to approach the tasks (Chou, Tang, and Tsai 2021) thus affecting students’ learning outcome during learning sessions in the computer laboratory.

Große-Bölting, Schneider, and Mühling (2019) used surveys and interviews to investigate novice students’ views of what computer science means. The analyses gave five types of beginning students, from the ‘creator’ who views CS as a way to influence the real world, to the ‘mathematician’ who has a theoretical view of CS, to the ‘interpreter who regards computer science as a “translation activitly” between man and machine’, to students with no or differential picture of CS.

Previous research exploring students’ learning of theory has often focused on their understanding of concepts, as is the case with traditionally phenomenographic research (Pang 2003; Ingerman and Booth 2003). Several studies in this line of research have addressed concepts related to computer programming (e.g. Stamouli and Huggard 2006; Lönnberg 2009; Boustedt 2010; Cambazoglu and Thota 2013; Thota and Berglund 2016). In computing education research there is also literature on students’ conceptions and misconceptions (e.g. Ragonis and Ben-Ari 2005; Sanders and Thomas 2007; Qian and Lehman 2019). In contrast to the research where focus is on conceptual understanding, we take a broader view of what it means to learn theory.

In relation to learning and understanding of practice, the body of phenomenographic research is rather limited (Box 2009; Thomas et al. 2014; Eckerdal 2015). However, a main focus in computing education research, outside the phenomenographic tradition, has been on practice as means for learning both theory and practice (e.g. Gross and Powers 2005; Luxton-Reilly et al. 2018). Besides this line of research, a number of studies investigate students’ computing skills, e.g. designing software, debugging, and reading and writing code (e.g. Thomas et al. 2017; Whalley, Settle, and Luxton-Reilly 2021; Zhang et al. 2023). In contrast to previous studies, we do not focus on theory and practice separately, but on the interaction between learning of theory and learning of practice.

Many disciplines besides computer science have practical as well as theoretical learning goals. The concept WTP, ‘ways of thinking and practicing’ highlights the fact that competences in a subject area involve both the ability to master certain subject-specific ways of thinking and the ability to perform subject-specific practice (McCune and Hounsell 2005). This is for example relevant in the STEM area (Science, Technology, Engineering, and Mathematic) where a recurring observation is that students have difficulties to learn in the laboratory. For example, Séré (2002, 630) points to the complex interaction between concepts and practice in laboratory work in science education writing ‘[this] explains to a certain extent why conceptual learning is not an automatic outcome of lab work’. From mathematics education research Carpenter et al. (1980, 338) write: ‘the development of a skill is closely tied to understanding the concept underlying the skill’. The complex relationship between theory and practice when students learn in the physics lab made Smith and Holmes (2021, 662) argue that ‘it is more effective for labs to be explicitly and exclusively in service of experiment, rather than in service of theory’, while von Aufschnaiter and von Aufschnaiter (2007, 51) write ‘One aim of physics laboratory instruction is to help students connect theory to practice’ and further:

we do not yet know under exactly which circumstances students [in laboratory work] are more likely to connect theory to practice, which activities are more likely to result in a ‘better’ understanding. (52)

In a phenomenographic study, Eckerdal (2015) analysed the relationship between novice programming students’ learning of theory and their learning of practice and found that theory and practice can be related with, in a phenomenographic sense, dimensions of variation in common, see Section III.2. From the same area, du Boulay (2013, 284) discusses domains that programming students must learn to master including syntax and semantics of a programming language and different skills. du Boulay writes:

None of these issues are entirely separable from each other, and much of the ‘shock’ […] of the first few encounters between the learner and the system are compounded by the student’s attempt to deal with all these different kinds of difficulty at once.

Our study is in the tradition of studying students’ learning process in the laboratory by video and/or audio recordings (e.g. Lidar, Lundqvist, and Östman 2006; Lindwall and Lymer 2008; Wickman and Östman 2002; Bernhard and Carstensen 2015; Hardahl, Wickman, and Caiman 2019). In particular, our work is similar to that of Ingerman, Linder, and Marshall (2009) who report on a variation theoretical study in the phenomenographic tradition in a physics laboratory context. We use a similar approach for our study of learning in the computer laboratory, but in contrast to Ingerman, Linder, and Marshall we pay particular attention to the interaction between students’ learning of theory and their learning of practice.

III. Theoretical framing

III.1 Theory and practice

The interpretations of theory and practice tend to vary considerably between different theoretical assumptions, contexts, and particular projects, even within educational research.

In Western culture, there has of tradition been a dichotomy between theory and practice. However, this has been challenged, for example by Dewey (1925/1988). Jorgensen (2005) provides an overview of different perspectives on the relation between theory and practice that have been suggested by different authors since the mid-twentieth century and where the distinction between theory and practice is problematised.

One of the pioneers of Computer Science, Donald Knuth, expressed the close relationship between theory and practice as follows:

The main point I want to emphasize […] is that both theory and practice can and should be present simultaneously. Theory and practice are not mutually exclusive; they are intimately connected. They live together and support each other. (Knuth 1991, 3)

In this project, we subscribe to the view that the distinction between theory and practice is fuzzy. Even within the field of Computer Science, different definitions of these concepts may be relevant in different contexts. For the purpose of analysis in the present study, we use the term ‘theory’ as referring to general principles and relations while practice is oriented towards a specific case. For example, we will interpret a discussion about the semantics of a particular programming construct as being about ‘theory’, whereas a discussion about how to write an instance of this construct in a particular program will be interpreted as an example of ‘practice’. This is in line with how we understand that students and teachers of computer programming use these concepts.

As our data stem from naturalistic laboratory settings, where we analyse how students discuss and work at their computer, our data come in terms of students’ talk, their typing, their pointing to the screen, etc. In this project, we label what the students say and do as actions and use the two terms theory-oriented action and practice-oriented action to denote student actions that in our interpretations are expressing theory and practice respectively. For example, discussing what variable assignment means is a theory-oriented action (as it is about general principles), while changing the syntax of variable assignment in the code the students are working on is a practice-oriented action (as it applies to a specific case).

III.2. Phenomenography and variation theory

Our project is anchored in a research tradition where phenomenography and variation theory serve as the theoretical backbone (Marton and Booth 1997; Marton et al. 2004; Marton 2014).

Phenomenography is an empirically based, qualitative, interpretative research approach that is used to describe qualitatively different ways in which something (traditionally labelled a phenomenon in the phenomenographic literature) is experienced, or understood, in a cohort. Phenomenography is frequently used for research in higher education, where the phenomena are related to learning, for example, objects of learning within the disciplines that the students study.

In a phenomenographic analysis related to education, the aim is to reveal the variation in experiences of an object of learning in a cohort of students. The focus is on qualitative differences, for example, that some students discern an aspect of the object of learning that other students in the cohort have not yet become aware of. In this tradition, learning is understood as coming to understand something in a qualitatively different and more complex way, i.e. to become focally aware of a new aspect of the object of learning, or of a new relation between such aspects.

Variation theory (Marton et al. 2004) is a further development within the phenomenographic line of research. There, focus is not only on the variation in how students experience an object of learning. In addition, variation theoretical studies aim to explore how variation can be used in a systematic way by teachers to create possibilities for students to discern critical aspects (and relations between such aspects) of an object of learning. In variation theory, it is said that each aspect of a phenomenon is related to a dimension of variation (Marton et al. 2004). For example, one aspect of the phenomenon ‘circle’ is that each circle has a diameter. The aspect ‘diameter’ of the phenomenon ‘circle’ will take different values for different circles. In other words, there is a dimension ‘diameter’ along which circles vary, so that the aspect ‘diameter’ is said to correspond to a dimension of variation of ‘circle’. A key assumption in variation theory is that for a learner to come to see new aspects of a phenomenon or a new relation between such aspects, it is necessary for the learner to be exposed to some variation and invariance along the dimensions of variation corresponding to those aspects (Marton et al. 2004). In our work, variation theory serves as a framework to interpret and describe possibilities for learning that open while the students work independently in front of their computers, creating variation as they go. This is in contrast to when teachers control lectures and consciously in advance create variation in their teaching to support students’ learning.

IV. The empirical data

The aim of the project is to get a better understanding of the learning that takes place when students work with exercises in the computer laboratory, which is very common in programming education. In the following, we will refer to such learning sessions in the computer laboratory as ‘labs’. The study collected data at labs scheduled in introductory programming courses given in engineering master and bachelor programs at three universities in Sweden. The goals of the labs were similar at the three universities: to be able to write methods that return value in Java or functions in Python. However, the details on how the assignments for the lab were constructed, what had been taught previously in the course, the students’ general background, and the reasons why laboratory assignments were constructed in the way they were varied largely between the universities. This influenced which details the students focused on and where they faced problems during the labs. An example of such difference between the universities was that the students at the university from where our episodes below are taken had not been introduced to methods that return value previous to the lab. The pedagogical idea was to let the students first work hands-on in the lab with exercises illustrating this concept, which would make them prepared to grasp the concept in the subsequent lecture.

Data were collected in naturalistic settings, as the labs were a regular part of the courses. In total, we video filmed 29 students distributed over 13 teams, with each team consisting of two to three students collaborating in front of a computer. The students in the study were given a written consent form with information about the study. Participation was voluntary. Two of the researchers attended each lab and took notes with the purpose of collecting data to be used during the stimulated recall interviews (see below).

The student teams were filmed from behind in order for us to see what gestures or movements the students did (for example pointing to the screen) and to be able to distinguish between the students in the team. We also captured the screens and the students’ voices to be able to follow in detail how the students interacted between each other and with their computers. Each of our films was about one hour long.

After the labs, we made individual stimulated recall interviews with the students, where we mainly discussed particular episodes of the lab. These were selected by us as we judged that they illustrated occasions during which the students had gained new insights, and where these insights were related to the theory –practice interaction. During the stimulated recall interviews, we asked the interviewee to describe what happened during these occasions.

This means that for each team of students in a lab, we have four to five recordings: one interview per student in the team, and two films from the lab itself, one from behind plus the screen caption. For the analysis presented in this article, the screen films were the main data source. When more information was needed, data from the film from behind the students and the interviews were added to the pool of data.

The present article is based on an analysis of eight episodes from the films from one study program, a master's program in molecular biotechnology engineering. The data were gathered before the COVID pandemic. During the pandemic, new teaching models were developed, in the form of ‘virtual’ laboratory sessions, were students carried out computer laboratory assignments via distance work on-line. In this new setting, students were still working together as previously, with discussions taking place via video or audio call systems, but with the exception that students were now encouraged to each write the code, even though discussing with each other. Moreover, the assignments were basically the same as when the data were gathered. Consequently, we assume that the results of the present study apply also to such virtual laboratory sessions.

V. The analysis

We identified sequences in the screen captures and video films where we judged that the students reached some new insight concerning an object of learning. Inspired by Ingerman, Linder, and Marshall (2009), we use the term episode for such a thematic sequence that is not interrupted by a change of topic. The first author went through all the films and interviews and identified candidates for such episodes. All authors then discussed until reaching consensus whether the suggested sequences clearly showed new insights. We excluded the sequences we judged not to be clear, and sequences where the students merely recalled previously attained knowledge. By new insights, we thus mean discernment of new aspects of a phenomenon, or relationships between previously discerned aspects.

The students discussed in Swedish. The episodes were transcribed verbatim and analysed as described below. The episodes that are presented in the present article were translated into English by the authors. Material from the interviews was used as an additional source of information.

We used an approach proposed by Thuné and Eckerdal (2019) for investigating episodes where theory and practice interact in students’ learning. In short, for each episode, this investigation was divided into three phases. The objective of the first phase was to identify which dimensions of variation, and/or relations between such dimensions, the students discerned during the episode, and that led them to new insight. In the second phase, we identified and described the variation that took place in each episode that enabled the students to discern the dimensions and/or relations that were identified in the first phase. Finally, in the third phase, the aim was to investigate and describe in what way events during the episode helped the students to see these new dimensions and/or relations. The focus of this description was on the interaction between theory-oriented and practice-oriented actions during the episode.

VI. Results

We divide the presentation of results into two parts. In Section VI.1, we present results from the analysis of individual episodes of learning. In each episode, there is an interaction between theory-oriented and practice-oriented actions taken by the students. As a synthesis of the observations from the individual episodes, Section VI.2 presents our interpretation of the roles played by these different kinds of actions.

VI.1. Individual episodes of learning

We show results of the analysis described in Section V, for a selection of episodes, chosen so that they together cover the typical student interactions that we have observed in our data. For each episode, we will summarise the results of the analysis. To preserve anonymity, the student names in the excerpts are fictitious. Moreover, male and female names have been used randomly, regardless of the actual gender of each student.

The episodes presented below are all from a course where the students were introduced to new concepts in the lab before the teacher explained them in the lecture. The lab material included exercises and links to documents with short explanations and a few examples illustrating a new concept.

Episode A

When the episode begins, the students have written the following incorrect program text in the programming language Java on the computer screen:

if (getHeight()<getWidth());

   System.out.println(int getHeight());

    else

   System.out.println(int getWidth());

The episode then develops as follows:

• A.1. Bill: [While reading the lab instruction document where the “if”-statement is explained and examples are given] They have these [points to braces] after those. Should you then … [silence]. Where is it then? [Celia points to “{” and “}” at the keyboard]

• A.2. Celia: How often are you supposed to use them?

• A.3. Bill: Should we use it [referring to the braces] after “if” too?

• A.4. [Bill types “{“ directly after the keyword “if”]

• A.5. Adam: Hm. Let’s first try to figure that out.

• A.6. [Bill presses Enter after the first System.out.println and types “}” on the new line]

• A.7. Celia: I would have put it before the “if” so “if” kind of comes inside.

• A.8. Adam: They don’t do it like that there. [Referring to the examples in the document]

• A.9. Bill: Ops, it shouldn’t be there, it should be here.

• A.10. [Bill moves “{“ to the end of the first line “if(…);”]

• A.11. Celia: What, why did we put it there?

• A.12. [Bill types “{“ after “else”]

• A.13. Adam: Because they did it like that. [Adam refers to the examples in the supporting document]

• A.14. Celia: But why do you do like that? I imagine that it kind of does, what do those brackets do? I imagine that it should be like, well, parenthesis you kind of do first.

• A.15. [Bill types “}” after the final “System.out.println” statement.]

• A.16. Adam: No it’s not parenthesis, it has nothing to do with that. [Adam sounds very sure.]

• A.17. Celia: But why do you put, what is it really?

• A.18. Adam: I think it’s the end of the statement. This is the statement.

• A.19. Bill: Yes, it’s the part we are working on. This is the “if”-statement. [Bill points to the screen to the statement that is connected to “if”.] This is kind of the method that is included in “if”. This is what makes “if” work.

• A.20. Celia: Aha, I understand. Okay, I get it.

In this episode, the students seem to gain a partial insight into how braces are used to delimit blocks of code in if-statements in the programming language Java. According to the written lab instructions the object of learning for the part of the lab exercise addressed in Episode A is ‘if-statements’ and in particular such statements in Java. One aspect of if-statements is that different blocks of code will be executed depending on what conditions are at hand. In Java, each block of code in the if-statement has to be delimited by braces. The layout of the code for the if-statement can nevertheless vary considerably. Our interpretation is that the students come to see the aspect (of if-statements in Java) that braces are needed to delimit code blocks and that they begin to explore the dimension of variation related to this aspect, i.e. the possible forms of layout for code blocks in Java.

In Episode A, the students look at some examples in the document describing the ‘if’-statement. In addition, they themselves try different ways of placing the braces to delimit code blocks. Consequently, the examples and the students’ own attempts to place braces create a variation in the dimension related to the aspect ‘layout for code blocks in Java’ and this variation helps the students to get a clearer view of acceptable ‘values’ in this dimension (i.e. acceptable forms of layout for code blocks).

The interaction between practice-oriented and theory-oriented actions in the episode is summarised in Table 1. As was discussed in Section IV, the distinction between theory and practice is not clear-cut. We have interpreted actions as practice-oriented when they focus narrowly on the task at hand (for example, typing program text, suggesting what to write based on pattern-matching from examples, etc.) and as theory-oriented when they relate to general principles. For example, in Table 1, statement A.7 was interpreted as theory-oriented because it seems to reflect what Celia thinks would in principle be a correct placement of the left brace. This interpretation is supported by Celia’s later statement A.14. Adam’s subsequent comment A.8, on the other hand, is clearly referring to a concrete example in the document and was consequently interpreted as being practice-oriented. From the table, it is clear that there are both practice-oriented and theory-oriented actions in this episode. In this case, it seems that the practice-oriented actions serve as a means to explore the dimension of variation in focus here, whereas the theory-oriented actions serve to assess the various alternatives that the practice-oriented actions produce. In this interaction between practice-oriented and theory-oriented actions, we can follow a wave, or a movement forward, characterised by frequent switches between practice-oriented and theory-oriented actions.

Table 1. The table summarises key points of the analysis regarding the interaction between theory-oriented and practice-oriented actions that occurred in Episode A.

Theory-oriented action	Practice-oriented action
A.1 Bill reads the lab instruction document where the ‘if’-statement is explained and examples are given.
A.2-3 How often … ? Should we use it after ‘if’ too?
	A.4-6 Bill types ‘{‘ directly after ‘if’. Later he makes a new line after the first ‘System.out’ statement and types ‘}’ on the new line.
A.7 Celia: I would have put it before the ‘if’ so ‘if’ kind of comes inside.
	A.8 Adam: They don’t do it like that there.
	A.9-10 Bill: Ops, it shouldn’t be there, it should be here. [Moves ‘{‘ to the end of the first line ‘if(…);’]
A.11 Celia: Why did we put it there?
	A.12 Bill writes ‘{’ after ‘else’
	A.13 Adam: Because they did it like that.
A.14 Celia: But why do you do like that? […] I imagine that it should be like, well, parentheses you kind of do first.
	A.15 [Bill types ‘}’ after the final ‘System.out’ statement.]
A.16-19 No it’s not parenthesis […] what is it really? […] This is kind of the method that is included in ‘if’. […]

Episode B

In this episode, two students are working on an exercise in Java where the task is to write a method to draw a circle on the computer screen. According to the lab instruction, this should be a method without a return value. The only thing that should happen when the method is executed is that a circle should appear on the computer screen. The students struggle with how to express the type of value to be returned by the method. After the initial keyword ‘public’ there should follow another keyword, expressing the type of value to be returned by the method. The object of learning here is ‘methods in Java’ and the particular aspect is ‘type of return value’. The dimension of variation in focus is consequently the dimension that consists of the different types of values that a method in Java could return.

Episode B is described in Table 2.

Table 2. The table summarises key points of the analysis regarding the interaction between theory-oriented and practice-oriented actions that occurred in Episode B.

Theory-oriented action	Practice-oriented action
	B.1. [David writes ‘public’]
	B.2. David: Should we make an int?
B.3. Erica: But do we need to make an int? It won’t come out a number, it should, yes.
	B.4. David: Ehh, or?
B.5. Erica: We will let in a number. But then you perhaps don’t need an int before?
	B.6. David: Don’t know.
B.7. Erica: It should only run now.
	B.8. [David reads the description of the assignment in the lab instruction: ‘Write a method void drawCircle(int radius)’]
	B.9. David: It should be void, ok [types ‘void’. Now it says ‘public void’ on the screen.]
B.10. Erica: What does void mean again? I forget. B.11. David: [Sighs] Yes what is void now again. I think void means that it doesn’t … B.12. Erica: It doesn’t print anything [snaps her fingers] B.13. David: It doesn’t print anything …
B.14. Erica: Bang, it just do something, that’s it. B.15. David: Hm, right, it doesn’t expect anything … It shouldn’t be an answer. B.16. Erica: but it should just do something.
	B.17. David: And it should be called drawCircle [types and talks] B.18. [David types ‘drawCircle(int radius)’ which makes the method head ‘public void drawCircle(int radius)’]

In statement B.2, David makes a practice-oriented suggestion about what to write directly after ‘public’. At this point, David does not type the suggested word, but instead, he suggests verbally what to type. In our understanding, the suggestion is not based on any idea of principles but rather reflects that the two students had written a method beginning with the keywords ‘public int’ in the previous exercise. Consequently, we interpret B.2 to be a practice-oriented action. By suggesting ‘int’, David creates a value in the dimension of variation in focus here.

In statement B.3, Erica questions the suggestion from a position of principle: since the method is not supposed to return any value, it seems incorrect to use the keyword ‘int’ (which expresses that an integer value should be returned). In other words, Erica makes a theoretical assessment of David’s suggestion before it has been tested through the compilation and execution of the program. In statement B.5, Erica suggests that since no value should be returned, perhaps there is no need to write ‘int’ after ‘public’. In our interpretation, Erica expresses a hypothesis that it may not be necessary to write anything at all in this position.

Instead of testing Erica’s hypothesis, David makes the practice-oriented action to read the lab instructions more carefully, B.8. Reading a text could be seen as theory-oriented, but since the text David is reading here does not contain any explanations about principles, only a direct prescription for what to write in this particular case, we interpret action B.8 to be practice-oriented. The effect of this action is that David sees an additional value in the dimension of variation in focus, the value ‘void’. Since both action B.2 and action B.8 resulted in concrete values in the dimension of variation in focus, these two actions together help the students to get a clearer view of that dimension.

After action B.8-9, it is clear to the students that the right answer to the question of what to write after ‘public’ in this case is ‘void’. However, they do not leave it by that. Instead, they continue with a theory-oriented discussion, in statement B.10-16, where they try to make sense of ‘void’ being the correct answer. They do not leave the issue until they have recalled the meaning of ‘void’ (a concept that they had encountered in a previous part of the introductory course in programming) and they subsequently have established that this meaning agrees with their own understanding of what the method in the current exercise should do.

Episode C

The students David and Erica have written the following incorrect code involving the if-else-statement in Java.

   if (x < k) {

    int a = x},

   else {a = k};

   if (y < j) {;

The episode that now begins is described in Table 3.

Table 3. The table summarises key points of the analysis regarding the interaction between theory-oriented and practice-oriented actions that occurred in Episode C.

Theory-oriented action	Practice-oriented action
	C.1. [David presses enter after typing ‘if (y < j) {;’] C.2. [David types on the new line: ‘int a’]
C.3. Erica: Do you have to have a new line after ‘else’? C.4. David: How do you mean? C.5. Erica: Well we write ‘int’ beneath as we did for the ‘if’, kind of.
C.6 David: I guess it’s not necessary, or it should interpret that since, it should interpret everything inside the braces as one thing. C.7 Erica: Yes. C.8 David: I believe. It shouldn’t make any difference between that and that. C.9 Erica: No. C.10 David: Or maybe it does.

The code is not correct, but it is not the errors Erica discusses. She discerns a variation between the first, third, and fourth lines of code in the if-else-statement. In the first line, there is a line break after the ‘{‘ symbol, so that the next statement (‘int a = x’) comes on a separate line. In the third line, there is no line break after the ‘{‘ symbol, so the next statement (‘a = k’) comes on the same line as ‘else’. When David writes the fourth line, he once again inserts a line break before he writes the next statement. This is when Erica notices the variation and begins a discussion with David. The dimension of variation that Erica discerns is the same as the dimension that the students in Episode A became aware of, i.e. the variation in possible forms of layout for code blocks in Java

The object of learning in this case is the if-statement in Java. One aspect of the if-statement is the block of code that should be executed if a certain condition is fulfilled. In Java, line breaks inside braces do not generally change the syntactical correctness of the code but can be used to enhance readability. In the example above, David happens to insert a line break in one case and not in another. In this way, he unintentionally creates a variation in the way the code blocks are expressed. Erica discerns that variation and becomes aware that the layout of if statements is an aspect she does not fully understand.

This brief episode begins with David’s practice-oriented actions C.1-2. Next, C.3-5, Erica voices her concerns, based on the variation she has discerned. She is thinking about the layout of the if statement in principle, which makes us interpret this part of the episode as theory-oriented. Finally, C.6-10, David provides a theory-oriented explanation, expressing his understanding of the role of braces in the if statement. By his final statement, he signals that he is not completely sure. However, Erica accepts his explanation and, after this episode, the students continue with the exercise. The practice-oriented test of whether David’s understanding was correct comes at a later stage when the if statement is corrected so that they can compile and execute the program.

VI.2. Variation through interaction between practice and theory

Having analysed individual episodes of learning from a variation theoretical point of view, we found that in each episode the interaction between practice and theory created a variation that helped students to see some new aspect of the object of learning. In teacher-led education based on variation theoretical principles, the teacher actively creates variation by a deliberate choice of examples. In learning sessions in the computer lab, the students work mostly on their own, which gives the teacher a significantly lower degree of control over what variation will occur for each student group during the lab. Instead, the variation is largely created by the students themselves. In the three episodes used for illustration in Section∼VI.1, we see that switching between practice-oriented and theory-oriented actions creates the kind of variation that is helpful according to variation theory.

More precisely, we found that the variation occurred because practice-oriented and theory-oriented actions played complementary roles in the episodes. The following cases and subcases were identified. After each case, we provide an example by referring to parts of the episodes above.

Practice-oriented actions

• serve as a means to create different ‘values’ in the dimensions of variation that are in focus in the episode. See for example A.4-6

• serve to give the students a clearer view of possible values in those dimensions. See for example B.9

Theory-oriented actions

• serve as a means for the students to assess the results of their practice-oriented actions, see for example A.7

  • o before those results have been tested through compilation and execution of the program

  • o and after the students have seen the outcome of compiling and/or executing the program;

• serve to generate ideas about what would be suitable practice-oriented actions. See for example A.2-3

These different roles of practice-oriented and theory-oriented actions can support each other mutually, to create variation in a fruitful way. For example, when students have done some practice-oriented action that concretises a possible ‘value’ in a dimension of variation, then that often helps to initiate theory-oriented reflection. The theory-oriented reflection can then lead to some idea about what to do next that will lead to a new practice-oriented action creating another possible value in the dimension of variation in focus. This, in turn, will help the students to get a clearer view of possible values in that dimension, which will trigger new assessment and ideas, etc. This is precisely the pattern in Episode B.

However, the actions/roles do not necessarily come in that order within an episode. Episode A begins with theory-oriented actions A.2-3 generating an idea for practice-oriented action, A.4-6. As a result of the practice-oriented action A.4-6 the students concretely see one possible but incorrect way of placing the braces. They assess this alternative theoretically in statement A.7, which is consequently an example of theory-oriented action taken before testing. Statement A.7 is also an example of a theory-oriented action generating an idea for practice-oriented action since Celia’s rejection of the result of action A.4-6 is based on her idea that the braces should be used as parentheses around the entire if-statement (as she makes more explicit in statement A.14). In our interpretation, the remaining actions in Table 1 can also be described in terms of the different roles identified above.

VII. Discussion

An episode is defined as a sequence of the lab session where we interpret that the students manage to reach some new insight about the object of learning. However, in our data, we also have sequences where students become aware of a lack of clarity but don’t even try to resolve it but continue with the lab. Sometimes they try to resolve it but reach a misconception or they give up. In such cases, the students often took only either practice-oriented or theory-oriented actions. They might make a sequence of unsuccessful attempts to modify the program by practice-oriented trial and error, or they get stuck in theory-oriented discussions and give up without having tried any of their ideas in practice.

Our first finding is thus the indication that the interaction between practice-oriented and theory-oriented actions, with the different roles described above, is important for the creation of helpful variation, that actually leads to learning. In previous work (Eckerdal 2015) we showed that a dimension of variation can relate to knowledge of theory as well as knowledge of practice. This can to some extent explain the present finding that the interaction between the two is important and supports students’ learning. For a discussion on unsuccessful learning sequences, see (Eckerdal, Berglund, and Thuné 2022).

Our second finding is the different roles that theory-oriented and practice-oriented actions play in students’ learning. In summary, the practice-oriented actions help students to create and get a clearer view of different ‘values’ in the dimensions of variation, while the theory-oriented actions help the students to assess the results of their practice-oriented actions, and serve to generate ideas about what would be suitable new practice-oriented actions.

A deeper investigation of how theory and practice interact shows that variation plays different roles at the different stages of the learning process in the computer laboratory. Firstly, variation may initiate learning by making students aware of the lack of clarity. Here, Episode C can serve as an example. Secondly, variation can help students identify what is critical in the lack of clarity, and thirdly, variation helps them make meaning of it. In Episode B, David’s practice-oriented actions, interleaved with the theory-oriented discussions seem to help the students to discern the meaning of ‘void’ in a method head. For further discussion on stages in programming students’ learning in the laboratory, see (Eckerdal, Berglund, and Thuné 2022).

Our third finding is thus that such frequent switches add to the variation created by the teacher and increase the possibility for the students to discern a new aspect of the object of learning. This source of variation has not, to our knowledge, previously been discussed in the phenomenographic literature but seems to be central in programming education.

A final finding from our analysis indicates not only that, but also how and why frequent switches are important for the successful learning process: the two kinds of action play complementary roles, making them mutually support each other in students’ learning. When a practice-oriented action has created a new value in the dimension of variation and thus given the students a clearer view of possible values, students need to reflect and assess the suggested value so they can see beyond the concrete value and start to generalise towards the concept behind it. This in turn seems to help them to generate ideas about what would be a suitable next practice-oriented action, which in turn will give them a new value in the dimension of variation and an even clearer view of the concept.

VIII. Implications for teaching

Variation theory does not say that any variation is likely to promote learning. A haphazard collection of examples may contain lots of variation, but may nevertheless not help the students to become aware of new aspects of the object of learning. The key in education using variation-theoretical principles is that the teacher carefully chooses examples to expose variation and invariance in some dimension of variation related to the object of learning, identified by the teacher as critical. Marton et al. (2004) identify a number of ‘patterns of variation’ that can be used for this purpose. As Marton et al. point out, such variation opens a possibility for students to become aware of a new dimension of variation. Some students will benefit from this possibility and come to see a new aspect of the object of learning. Other students will not see the new aspect, despite the possibility opened by the variation.

Variation is commonly discussed in phenomenographic research as created by the teacher, usually in the context of teacher-led lessons, where the teacher can choose a sequence of examples and exercises to expose certain dimensions of variation by use of patterns of variation. The situation is more challenging when the students work on their own in the lab and the teacher does not control the workflow in detail. What the teacher can do in that context is to design the written lab instructions so that they expose dimensions of variation that the teacher wants the students to become aware of during the lab. In a previous paper, we discussed lab material from that point of view and gave examples of how the design of the material can both expose and obscure dimensions of variation (Eckerdal and Thuné 2013).

Our results in the present paper show that additional, helpful variation (in dimensions of variation) is created by the students themselves, if they switch frequently between practice-oriented and theory-oriented actions (see Section VI.2). In our data, we found examples of how too long focus either only on practice-oriented actions or only on theory-oriented actions was less beneficial, while frequent switches between the two kinds of action seemed to drive the learning process forward.

This implies that it would be good to give the students incentives to make such frequent switches. However, the distinction between theory-oriented and practice-oriented actions is probably very unclear to most novice programming students. The challenge for the teacher is thus to find ways to trigger the students to make these switches without referring to the concepts of theory (-oriented) and practice (-oriented). Obviously, a teacher who is acting as a tutor in the lab hall can intervene when noticing that a group of students is stuck in either practical trial and error or endless theory-oriented discussion. But what can be done if the students work completely on their own? In that case, the incentives to switch between theory-oriented and practice-oriented actions must be built into the lab material at hand. Some examples:

• As an attempt to avoid students getting stuck in theory-oriented discussions, the lab instructions could include interspersed reminders that the students should compile and run their code, even if it does not work as intended.

• A way to encourage theory-oriented actions is to make theoretical material easily available during laboratory sessions. At appropriate points in the lab material, there could be references to specific pages in the textbook and/or to relevant resources on the web. Moreover, since we consider novice programming students, the material referred to has to be expressed in a way that is relatively easy to understand, and clearly linked to the task at hand for the students.

• With inspiration from pair-programming, another way to encourage both practice-oriented action and theory-oriented discussion is to state (in the lab material) that the students should take turns to have the role of ‘driver’ and ‘navigator. The driver should be a ‘doer’ at the keyboard, writing code. The role of the navigator would be to act as a ‘thinker’, asking questions such as ‘why’, ‘what is the goal of this’, ‘what is the difference between this and that’, etc. As a further incentive for the students to really act according to these instructions, there could at the end of each exercise in the lab material be a requirement to write explicit arguments about why they wrote the code the way they did.

• Worked examples, i.e. examples that show a problem statement and a step-by-step leading to the solution (Renkl 2014) have proven to be specifically beneficial for novices in programming education (Muldner, Jennings, and Chiarelli 2022). We argue that worked examples can be used to encourage the switches between theory-oriented and practice-oriented actions. Renkl (2014) explains that the learners initially should study several problems where the solution is given, before working with exercises to solve similar problems. The learner should ‘acquire a basic understanding of domain principles while studying examples, which provides a basis for later meaningful problem solving.’ (Renkl 2014, 4). A way to implement this in programming labs is to provide the students with examples of code that involves the theory studied, and where the teacher may use guidelines from variation theory to highlight and explain the theory and its meaning in the examples, see the example below. This is in line with what Muldner et al. label code-generation examples. The authors write: ‘code-generation examples show the source code for a program … —they may also include additional information beyond just the code, such as explanations about the program components and/or program subgoals.’ (Muldner, Jennings, and Chiarelli 2022, 13:2) Figure 1 is from a lab where novice students were introduced to the relationship between return value and return type in Java. In the examples, the relevant code is highlighted, and below the code, the teacher has explained the relationship. If students read the code, a practice-oriented action, immediately followed by them reading the explanation ‘It is important that the type of the value in the return-statement aligns with the type in the method head!’, a theory-oriented action, this provides the switch that we argue is beneficial for learning. Here students could be asked to describe to each other what distinguishes the two examples and what the examples try to show. From a phenomenographic perspective this means to identify the dimension of variation highlighted by the examples.

Figure 1. The example has the following explanation: ‘It is important that the type of the value in the return-statement aligns with the type in the method head! Since the sqrt-method returns a value of type double, in the right method we have to explicitly convert the value to an int.’ (translated from Swedish).

IX. Trustworthiness and limitations

We follow Lincoln and Guba’s criteria for trustworthiness in qualitative research (Lincoln and Guba 1985). For credibility, our study uses triangulation in that we use more than one data source and multiple analysts as discussed above. For transferability, we have strived to give a ‘thick’ description of the full research study so the reader can decide the applicability of the results to his/her context. Regarding dependability, Lincoln and Guba argue that if reliability is fulfilled, so is dependability. Finally, confirmability, corresponding to objectivity in the conventional paradigm, can be met through triangulation.

A limitation of our study is the voluntary participation of students. More than 40% of the participants were women which does not mirror the gender distribution in the whole population of all the study programs. Further, video filming students while they were working might have influenced how they worked and communicated. We tried to lessen these effects by that none of the researchers were teaching the courses, and we informed the students that the teachers would not have access to the films and interviews.

X. Conclusions

In this article, we investigated the learning process when novice programming students were working in groups with exercises in the computer laboratory. The focus of our study was on the interaction between learning of theory and learning of practice in this context. The main conclusion is that when students’ learning process is successful, practice-oriented and theory-oriented actions are closely intertwined and play complementary roles in students’ learning which we have identified from our data (see Section VI.2 and examples in Section VI.1). The interaction between those roles in frequent switches between practice-oriented and theory-oriented actions seems to drive the learning process forward, while a one-sided focus on one type of action, theory – or practice-oriented, often seemed to arrest the learning process. This kind of variation seems to be central in programming education and we have analysed it to get a better understanding of its effect on students learning.

A successful learning process means that students discern and make relevant meaning of a new dimension of variation of the object of learning (or of a relation between such dimensions). This outcome of the learning process opens a possibility for the students to gain both a more complete theoretical understanding of programming and a more complete mastery of practical programming skills.

Acknowledgements

The authors want to thank our colleagues Lennart Rolandsson and Inga-Britt Skogh, and the students who participated in this study. The authors also thank the anonymous reviewers for thier valuable suggestions.

Disclosure statement

No potential conflict of interest was reported by the authors.

Additional information

Funding

This work was supported by The Swedish Research Council: [Grant Number Grant 2011-5924].

Notes on contributors

Anna Eckerdal

Anna Eckerdal is Associate Professor in computing education at Uppsala University. She has long experience of teaching programming at high school, and undergraduate level. Her research has mainly focused on how novice students learn in the computer laboratory. She is a member of the Uppsala Computing Education Research Group.

Anders Berglund

Anders Berglund is Assistant professor in computing education at Uppsala University. He has long experience in undergraduate and graduate teaching in computer science. His research interests include how students learn computer science and methodological rigour. He is a member of the Uppsala Computing Education Research Group.

Michael Thuné

Michael Thuné is Professor Emeritus of Scientific Computing at Uppsala University. He has long experience in undergraduate and graduate teaching in computer science and scientific computing. His research has mainly been in scientific computing, but also in computing education research. He is a member of the Uppsala Computing Education Research Group.