Analysis of Students’ learning of computer programming in a computer laboratory context

ABSTRACT

Previous research shows that many students find it difficult to learn computer programming. To learn computer programming includes both gaining theoretical understanding and learning to develop programmes in practice. To this end, teachers commonly design programming exercises for the students in the computer laboratory. To be able to improve the process of designing such exercises, there is a need of a more detailed understanding of the interaction between learning of theory and learning of practice in laboratory sessions. In this paper, an approach for investigating this interaction is proposed. Theoretically, the approach is based on phenomenography and variation theory. To illustrate the approach, it is demonstrated in detail how it was applied to a small but rich case of empirical data from a computer laboratory session. The main result presented here is the new approach for analysing data. In addition, the results of the case study shed preliminary light on the interaction between learning of practice and learning of theory when students work with programming assignments in the laboratory.

KEYWORDS:

• Programming education
• laboratory work
• variation theory
• theory and practice

1. Introduction

To learn computer programming is part of many study programmes in higher education. A multitude of reports of high failure and dropout rates (Ben-Ari 1998; McCracken et al. 2001; Robins, Rountree, and Rountree 2003; Lister et al. 2004; Kinnunen and Malmi 2006; Kinnunen 2009; Sorva 2013) indicate that students experience computer programming to be difficult. Students need to learn, both the theoretical foundations and the practice required when programming a computer. This is reflected both in the research literature (Lahtinen, Ala-Mutka, and Järvinen 2005; Kaila et al. 2010; Höök and Eckerdal 2015) and in internationally influential documents like the ACM/IEEE Computer Science Curriculum (ACM/IEEE Computing Curricula Task Force 2013). A very important learning activity in computer programming courses is that students work with programming assignments in the computer laboratory. This is intended to help consolidate theoretical understanding of programming and to train the skills to solve programming problems in practice.

In previous research it has been observed that misalignment between the learning of theory and the learning of practice is a reason for unsatisfactory learning outcome in laboratory-based education. For example, Séré (2002) comments that the complex interaction between concepts and practice ‘explains to a certain extent why conceptual learning is not an automatic outcome of lab work’ (630). In Computer Science education Eckerdal et al. (2007) found that students may reach a theoretical understanding while still lacking sufficient practical knowledge, and vice versa. The authors specifically point to the problem that many students are ‘not being able to translate from an abstract understanding to concrete implementation or design’. 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 like ‘understanding how to design a program to solve a certain task’ and ‘dividing functionality into procedures, functions and/or classes’ (17) among programming students studying mainly C++ and Java. Eckerdal (2015) further reports on findings on the relationship between the learning of theory and the learning of practice for novice programming students learning Java.

The conclusion of these and similar previous results is that the interaction between learning of practice and learning of theory is crucial for the learning outcome in laboratory-based education. The purpose of this paper is to present our approach to investigating students’ learning of computer programming, to gain a more detailed understanding of this interaction. We collect empirical data in contexts where students work with computer programming exercises in a computer laboratory, using the programming language Java, and we then analyse these data qualitatively. The approach, based on phenomenography and variation theory (Marton and Booth 1997; Marton et al. 2004), is similar to the one presented by Ingerman, Linder, and Marshall (2009) but includes novel components to capture how the students shift between practice-oriented and theory-oriented actions during the laboratory session and how that affects the students’ learning.

The approach we present is qualitative. The objective of the analysis is to get detailed insight into the interaction between learning of theory and learning of practice in specific case studies where students work with computer programming exercises in a computer laboratory. If we are able to get a better understanding of this interaction in a pool of cases, then that can serve as a basis for further research, using qualitative or quantitative methods depending on the purpose of the study, with the ultimate aim to provide educators with guidelines for how to design learning sessions in order to support the simultaneous learning of theory and practice in the computer laboratory.

The main contributions of this paper are twofold. First, the approach in itself is novel. Traditionally, phenomenography and variation theory have been used to investigate conceptual understanding as expressed verbally by informants. Our approach extends this by including also understanding expressed non-verbally and by students engaged in practice-oriented activities. This approach is a combination of and extension of approaches presented by Ingerman, Linder, and Marshall (2009) and Anderberg et al. (2008). The new approach allows for analysis of the interaction between learning of theory and learning of practice that would not be possible with either of these previous approaches. Secondly, to assess the feasibility of the approach we demonstrate in detail how it is applied to a small but rich case of empirical data involving one pair of students. The results from this example are of interest per se, and shed some preliminary light on the interaction between learning of practice and learning of theory when students work with computer programming assignments in the computer laboratory.

We are currently analysing a much larger body of empirical data from such contexts using the same approach. The long-term aim is to provide results that could give clues about how to improve the learning outcome in laboratory-based computer programming education. Since laboratory-based computer programming education has many similarities with laboratory-based education in other subject areas, we envisage that the results will also be at least partially relevant for a broader range of subjects, in particular in the sciences.

2. Background

2.1. Learning in the Laboratory

Learning in the laboratory is seen as vital in many subject areas, including computer programming. Previous research has however shown that learning in the laboratory is problematic in that neither the learning of theory nor the learning of practice during laboratory work is satisfactory. Subject areas where this has been discussed are Computer Science (Eckerdal 2015), Science (Wickman and Östman 2002a; Hofstein and Lunetta 2003; Psillos and Niedderer 2003), Technology (McCormick 1997), and Physics (von Aufschnaiter and von Aufschnaiter 2007).

Previous research on learning in subjects with laboratory work has mainly focused on either the role of theory (Entwistle 2003) or the role of practice (Valentine 2004; Powers et al. 2006), whereas our focus will be on the interaction between them. There is very little, if any, previous research on the relation between students’ learning of theory and their learning of practice in Computer Science. Research from other subject areas with laboratory work has pointed to the problem, but still little is explored. For example, von Aufschnaiter and von Aufschnaiter (2007) write about physics students’ learning in the laboratory: ‘we do not yet know under exactly which circumstances students are more likely to connect theory to practice, which activities are more likely to result in a “better” understanding and which are not’.

In Computing Education Research, most studies concerning the role of theory in students’ learning of computer programming have focussed on students’ misconceptions, e.g. in Java programming (Fleury 2000; Thomasson, Ratcliffe, and Thomas 2006; Sanders and Thomas 2007; Kaczmarczyk et al. 2010). However, the majority of efforts in Computing Education have focused on the practical side of students’ learning of computer programming in a computer laboratory context (Valentine 2004; Gross and Powers 2005; Powers et al. 2006). Recent research involves, for example, students’ use of visualisation tools (Hundhausen, Douglas, and Stasko 2002; Sorva, Karavirta, and Malmi 2013), development environments to use when writing programmes (Allen et al. 2003; Kölling et al. 2003; Utting et al. 2010), and how to activate students through, e.g. pair programming (McDowell et al. 2003; Braught, Wahls, and Eby 2011). Another line of research is to investigate skills related to programming, such as students’ abilities to read and trace code (Lister et al. 2004), write code (McCracken et al. 2001; McCartney et al. 2013), debug code (Fitzgerald et al. 2008), and how these skills relate to each other (Venables, Tan, and Lister 2009; Clear et al. 2011). This line of research has revealed how difficult it is for students to acquire those skills.

In the phenomenographic tradition Ingerman, Linder, and Marshall (2009) video and audio recorded groups of students in the physics laboratory. Their aim was to describe the students’ learning process by ‘using the notion of experiencing variation as the basic mechanism for learning’. The authors explored ‘what variation, with respect to a particular object of learning, that students experience in their process of constituting understanding’ (273). Short passages of students’ conversation, ‘threads of learning’ were analysed on a microlevel illustrating two stages of the learning progress: (1) discernment of variation, and (2) constitution of meaning from the experience of variation (273).

Ingerman, Linder, and Marshall (2009) and Lidar, Lundqvist, and Östman (2006) as well as other recent research (Wickman and Östman 2002a, 2002b; Wickman 2004; Lindwall and Lymer 2008; Bernhard 2010; Bernhard and Carstensen 2015) study students’ learning process in the laboratory, as it takes place. This is in line with the approach we propose. In the present study we identify situations similar to ‘gaps’ as described by Lidar, Lundqvist, and Östman (2006), and with a similar ambition: ‘to gain a detailed description of what a person or persons do and do not do when they try to learn or accomplish something’ (151). Our approach has many similarities with Ingerman, Linder, and Marshall (2009) as it has its roots in the phenomenographic tradition and involves doing microanalysis on passages from the data, threads of learning. Our study aims however specifically to follow the learning in terms of shifts between theory-oriented and practice-oriented actions, and thus to study the role of this interaction in students’ learning process.

2.2. The Phenomenographic View on Learning

According to phenomenography and variation theory, to learn something about an object of learning is to discern a new aspect of this object or a new relation between aspects, in the sense that this aspect or relation comes into the learner’s focal awareness and is experienced as being significant (Marton and Booth 1997). In other words, the learner comes to ‘see’ this aspect or relation as important or ‘critical’ for the understanding of the object of learning (Marton et al. 2004).

In variation theory, it is said that each aspect of a phenomenon is related to a dimension of variation (Marton et al. 2004). This means that the aspect can take different ‘values’ for different instances of the phenomenon. A very concrete example is the aspect ‘diameter’ of the phenomenon ‘circle’. Different circles can have different sizes of diameter, so in that sense, there is a ‘diameter’ dimension, along which circles vary. In the diameter case, the size of the diameter is a numerical value. In more abstract cases the ‘value’ can be non-numerical. For example ‘application area’ is an aspect of the phenomenon ‘computer program’. Different computer programmes are intended for use in different application areas. So computer programmes can be thought of as varying along an ‘application area’ dimension with ‘values’ such as ‘banking’, ‘weather forecasting’, ‘gaming’, etc.

A key assumption in variation theory is that for a learner to come to see a new dimension or a new relation between dimensions, it is necessary for the learner to be exposed to some variation and invariance along those dimensions (Marton et al. 2004). The rationale for this assumption is straightforward: if all examples of circles have the same diameter, then it is unlikely that ‘diameter’ will come to the fore as a significant aspect of circles. Only when exposed to circles of different diameters will it be possible for the learner to discern ‘diameter’ as a critical aspect of ‘circle’. Invariance is also of importance. For example: when exposed to circles of different diameter, the learner may observe that the shape of the object is invariant between these examples, and thus come to see this particular shape as a characteristic aspect of ‘circle’.¹

In their analysis of threads of learning, as discussed above, Ingerman, Linder, and Marshall (2009) looked for episodes in their data material, where students could be seen to discern some variation with respect to some aspect(s) of an object of learning, and thus to ‘open’ a corresponding dimension of variation. Looking for such episodes is a key component in our analysis as well. It is the focus on the interaction between theory and practice that makes our microanalysis of an episode different from that of Ingerman et al.

2.3. About Theory and Practice

Research on learning has frequently been concerned with the concepts ‘theory’ and ‘practice’. The issue of theory and practice in education is particularly apparent in relation to training for professions (see, e.g. Dewey 1904; Corlett et al. 2003; Gallagher 2004; Morgan 2006; Shulman 1998). However, even when the goal for education is not towards a particular profession, students are in many cases expected to be able to carry out practical tasks in order to demonstrate that they have grasped some subject matter. This holds for Computer Programming, where you cannot be considered to master the subject unless you can actually develop computer programmes in practice.

In Western culture there is of old an accepted agreement that theory and practice are opposite parts of a dualistic opposition; knowledge is regarded as either theoretical or practical (Molander 1997; Gustavsson 2002). The dichotomy between the two concepts is reflected not only in the differentiation between practical and theoretical knowledge but also in the differentiation between theory-oriented and practice-oriented educational programmes. In vocational training, e.g. in teacher training, the placement part has been seen as practical and the university located part as theoretical (Bergem et al. 1997).

However, the traditional dichotomy between theoretical knowledge and practical experience has been challenged. For example, Dewey ([1925] 1988) points to the ‘instrumental nature of the objects of scientific knowing’. An everyday example could be weather forecasts. Our understanding of weather physics, formulated theoretically in mathematical terms, is used as a tool to predict how the weather will develop in the near future. The theory being a tool makes the distinction between theory and practice fuzzy. Jorgensen (2005) discusses a variety of perspectives on the relation between theory and practice that have been suggested by different authors since the mid 20th century. For our purpose, it is neither necessary nor fruitful to take a clear stance in that debate. Suffice it to say that we subscribe to a view that acknowledges the fuzzy distinction between theory and practice. Moreover, we will assume that theory is about general principles and relations (for example, how the weather evolves in principle) whereas practice concerns special cases (for example, predicting how the weather will evolve in the next few days from now).

2.4. Language, Action and Knowledge Formation

Given our stance that theory is about general principles, the only way for a learner to demonstrate knowledge of some theory is to use language (either ordinary language or some formal language, such as mathematical or graphical notation) to express the theory, completely or partially. Successful tacit application of practical measures in a special case will not show that the learner has seen the general properties and relations that constitute the theory. Consequently, when we want to study students’ theory-oriented learning, we need tools to understand the role of language in knowledge formation.

Rooted in the phenomenographic tradition, Anderberg et al. (2008) proposed a way of exploring the role of language in individual students’ formation of understanding. They summarise their ‘intentional-expressive approach’ in an illustration, referred to as the ‘broken triangle’, see Figure 1. The broken triangle models the relation between an individual’s conception of an ‘object’ (the object of learning in our setting), and how the individual uses language with the intention to express a meaning that reflects this understanding. The triangle is ‘broken’, in order to highlight that there is not a one-to-one mapping between expression, intended meaning, conception and object.

Figure 1. The intentional-expressive model of language use in learning. This illustration is based on Figure 2 in Anderberg et al. (2008) and is used here with the kind permission of Elsie Anderberg.

For our purpose, the broken triangle can be interpreted as an illustration of the process when a learner uses language to try to express an intended meaning in relation to an understanding/conception of a phenomenon/object of learning. In this process, trying different linguistic expressions serves as way for the learner to better grasp the object of learning. Thus, the learner’s conception of the object of learning may be subject to change in the process. The perspective in the broken triangle is ‘first person’. That is, the focus is on an individual learner’s use of language in the knowledge formation process.

The empirical examples presented by Anderberg et al. concern oral/verbal expressions of understanding. However, in our interpretation, their theory is also valid for other forms of language. In addition to verbal expressions, written expressions of various kinds are particularly relevant for our purpose. This includes not only expressions in natural language, but also various kinds of formal notation that are used in Computer Science, including mathematical notation and notation that combines pictorial and textual elements. Assuming this generalised notion of ‘language’ (and given the view on theory expressed at the beginning of this section) we will use the broken triangle in Figure 1 to model theory-oriented formation of knowledge.

For our analysis, we will need a similar model for practice-oriented formation of knowledge. To this end, we modify the model proposed by Anderberg et al. by replacing ‘language expression’ by ‘action’ and the ‘intended meaning’ by ‘intended end’. This leads to the modified broken triangle shown in Figure 2. From this perspective, practice-oriented formation of knowledge is about learning to act adequately towards an intended end. Figure 2 can be interpreted as describing a process, where the individual learner tries different actions in order to reach an intended end and this serves, consciously or unconsciously, as a way for the learner to better grasp the object of learning, so that the learner’s conception of the object may be altered as a result of the process.

Figure 2. Our practice-oriented modification of the model by Anderberg et al. (2008). In this version the focus is on practice (action) as a way of achieving an intended end that relates to an understanding/conception of an object of learning.

3. Approach

We have collected empirical data by video filming students working in pairs with computer programming assignments in a computer laboratory. For the analysis of these data, we use a method similar to that of Ingerman, Linder, and Marshall (2009). A first phase of analysis consists in studying the video recording in order to identify sequences of the laboratory session where the students seem to gain some new insight. In the following, we will refer to these sequences as ‘threads of learning’, using the terminology introduced by Ingerman et al.

At the end of the first phase of the analysis, each thread of learning that has been identified is transcribed. The transcription includes what the students write on the computer screen and what they say. In addition, we include comments in brackets to capture non-verbal actions. We have included all such actions that we think are relevant for the continued analysis, but this is a source of error since the transcription process involves an element of interpretation, where some relevant information may get lost.

As discussed above, variation theory says that to learn is to expand your way of experiencing the object of learning, in that you discern new dimensions of variation related to aspects of the object of learning or that you discern new relations between such dimensions. In a second phase of analysis, we consequently make a more detailed study of the transcript of each thread of learning, with the objective to identify which dimensions of variation, and/or relations between dimensions, the students discerned and that led to the insights observed in the first phase of analysis.

In a third phase of the analysis, we describe the variation that took place and by which the students came to ‘see’ the object of learning in a new way. This far our analysis is along the same lines as that by Ingerman, Linder, and Marshall (2009), although our focus in this phase is on the students’ practice-oriented and theory-oriented actions.

In a final phase, we go beyond the analysis by Ingerman et al. and make an interpretation of the transcript of the thread of learning where we use the model by Anderberg et al. (2008) in relation to theory-oriented knowledge formation (see Figure 1) and our own modification of that model in relation to practice-oriented knowledge formation (see Figure 2).

We use the approach presented above for analysing empirical data concerning students’ lived object of learning. According to Marton et al. (2004), the lived object of learning is ‘the object of learning as seen from the learner’s point of view, that is, the outcome or result of learning’. Primarily, we are interested in students’ learning during laboratory sessions in novice computer programming courses. However, we envisage the framework to be applicable in other contexts as well, where the focus is on the interaction between theory-oriented and practice-oriented learning.

4. Application to Empirical Data

To illustrate how the proposed approach can be applied, we will now demonstrate in detail how to apply it to a small but rich case of empirical data involving one pair of students. Appendix B provides a brief introduction to the concepts necessary for understanding the following discussion.

4.1. The Empirical Data in this Example

In the example considered here, data were collected during an ordinary laboratory session in an introductory computer programming course, where students in a Master Degree programme in Engineering at a Swedish university learned to write computer programmes in the programming language Java. The instructions for the laboratory session were contained in a text document intended to be completely self-documenting. It included short theoretical explanations and a few examples, followed by some exercises. All students were working in pairs and the students in each pair were discussing the laboratory examples and exercises with each other while working. We video filmed the work of one of the student pairs throughout a laboratory session lasting for 90 minutes. The video camera was focused on the computer screen during the whole laboratory session, to capture the documents the students were reading and the programme text that the students were writing. In addition, the sound track of the video film captured the discussion between the two students in the pair.

The object of learning in the laboratory session was ‘methods with return value’.² The students should learn both what methods with return value are and how they can be expressed and used in the programming language Java. They were expected to learn both the general rules for how to express methods with return value in Java (theory-oriented knowledge) and how to apply these rules in specific cases so that the Java programme behaved in the intended way when executed (practice-oriented knowledge). During the laboratory session, the students worked with a sequence of examples and exercises.

4.2. Analysis

As an illustration of the way of analysis presented in Section 3, we will now discuss in some detail how to analyse the data discussed above, using our approach.

Phase 1. In the first phase of analysis, we study the video film in order to identify sequences in the laboratory session where the students appear to gain some new insight. For the purpose of the present example, we identify one such sequence. Appendix A presents a transcript of this part of the video film. In this case, the students speak Swedish and the analysis is based on the original transcript in that language. For the purpose of presentation in this article, the transcript has been translated to English by the authors. In the sequence of the laboratory session identified here, the students realise that the type of return value in the method they are writing for an exercise should not be void but double. In addition, they come to grips with the part of a method header in Java where the type of return value is expressed. We interpret this sequence to be a thread of learning (cf. Ingerman, Linder, and Marshall 2009).

Phase 2. In the second phase of analysis we aim to identify which dimensions of variation, or relations between dimensions, the students came to see in this thread of learning. In a previous analysis of the self-documenting laboratory session instruction used in this lab, we identified some dimensions of variation related to the object of learning for the exercise in focus in the thread of learning considered here (Eckerdal and Thuné 2013). The variation theoretical analysis was based on dimensions of variation identified in two previous phenomenographic studies, one concerning students’ conceptions of ‘computer programming’ (Thuné and Eckerdal 2009), the other about students’ conceptions of ‘object’ and ‘class’ in object-oriented programming (Eckerdal and Thuné 2005). Among the dimensions of variation identified in those studies, two are relevant in the present context. One is the textual representation of a program (the ‘text’ dimension, for brevity), the other is the action of a program during execution (the ‘action’ dimension). Different programmes represent different ‘values’ along these dimensions. In addition, these two dimensions of variation relate to each other in that the textual representation of a programme is a prescription for the action that will take place when the programme is executed. In (Eckerdal and Thuné 2013) we furthermore identified sub-dimensions to the text and action dimension, respectively, that are of relevance in the laboratory exercise discussed here. The empirical data in Appendix A indicate that the students come to ‘see’ several critical aspects of the object of learning in this thread of learning. First: the method should return a value when it is invoked; second: there has to be a return value type declaration in the method header and since the method should return a value this type should not be void; and third: the return value type is connected to what is actually returned from the method.

In other words, according to this interpretation, the students come to ‘see’ two dimensions of variation (DoV1 and DoV2) and one relation (R1) in the thread of learning analysed here:

• DoV1: The type of the value returned by the method (which is a sub dimension of the action dimension of the method)

• DoV2: The return type annotation in the method header (which is a sub dimension of the text dimension of the method).

• R1: DoV1 and DoV2 are related in that the return type in the method header should be the same as the type of the value returned by the method.

Phase 3. In the third phase, we look more closely at the thread of learning in Appendix A, to analyse the variation that takes place in the thread of learning and by which the students come to ‘see’ the two dimensions of variation DoV1, DoV2 and relation R1 as discussed in Phase 2. The variation displayed in this thread of learning is threefold (line numbers from Appendix A in parentheses). First, the students create a variation of their own in DoV1: they write void (1), then discuss that the method should return ‘something’ (2 – 4) and finally, after more discussion (6 – 18), agree on double.

The second variation is in DoV2. Here, the students create variation by tentatively expressing the method header in different ways, see (1), (5), (29), (45).

The third variation occurs when the students are reading the examples and accompanying explanations given in the lecture notes and the laboratory session material. The examples show complete textual representations of different methods with different return types. Consequently, the lecture notes and the laboratory session material in combination create a simultaneous variation in DoV1 and DoV2. This variation can be assumed to open the possibility for students to discern the relation R1.

Phase 4. In the final phase of the analysis, we investigate the thread of learning in Appendix A in further detail, interpreting it in the light of the models summarised in Figures 1 and 2. The purpose of this microanalysis is to arrive at a more nuanced understanding of the interaction between theory-oriented and practice-oriented activities and how that interaction relates to the variation identified in Phase 3. Some key points of the analysis presented below are summarised in Table 1.

Table 1. The table summarises key points of the analysis regarding the interaction between theory-oriented and practice-oriented activities that occurred during the laboratory session in Appendix A. For a more detailed account of the analysis, see below.

Theory-oriented action	Practice-oriented action	Comment
	(1) public void
(2) S1: … and it will throw something back (3) S2: But void means that it shouldn’t …		Theory-oriented assessment of the action in (1)
	(5) public	Practice-oriented expression of insight from (2 – 3)
	(19 – 20) S1: But perhaps we could have void and then write this afterwards …	Practice-oriented verbal suggestion
(25) S2: Do you have nothing there or do you have public return or … ?		Theory-oriented problematisation of (19-20), involving variation along DoV2
(26) S1: You should have nothing		Theory-oriented expression of S1’s current understanding
	(39) S1: Could it maybe look like this?	Practice-oriented verbal suggestion
(40) S2: But I’m not sure, shouldn’t there be something more? Shouldn’t it be a return?		Theory-oriented problematisation
(43) [S1 reads aloud from the lecture notes.]		Reading theory-oriented explanation
	(45) public double	Practice-oriented expression of new insight
(46) S1: Because it will give a double		Theory-oriented expression of new insight

Action (1) in the thread of learning is that one of the students writes public void in the editor. In view of the model in Figure 2 this can be interpreted as an action by which the student tries to achieved an intended end (writing a correct method header in Java for the method to be created in this part of the lab session) based on his current conception of the object of learning (methods with return value, in Java).

Next, consider statements (2–4):

• S1: We should write  … and it will throw something back, and what would it be called?

• S2: But void means that it shouldn’t … 

• S1: Yes, no, that’s true

Here, student S1 uses the expression ‘throw something back’ (2), which we understand to be his own expression for what is meant by ‘returning a value’ from a method. Using the model by Anderberg et al. (see Figure 1) this can be interpreted as a way for S1 to try to express his understanding of what ‘returning a value’ means in relation to the object of learning in this lab session (i.e. ‘methods with return value’). By statement (3), S2 seems to express an understanding that given what S1 just said (2), the keyword void cannot be correct, since that keyword means that ‘it [the method] shouldn’t’ [return a value]. The expression S2 uses in (3) is extremely condensed, but from the context, it seems to be his way of trying to use language to express his understanding of what void means in relation to methods in Java. In (4), S1 agrees with S2’s conclusion. The expression ‘Yes, no, that’s true’ indicates that only when S2 pointed it out did S1 became focally aware that the keyword void should not appear in the method header if there is a return value. To summarise, in (2-4), S1 demonstrates a theory-oriented though not very deep understanding of what it means for a method to ‘return a value’. In the same activity, S2 indicates awareness of the meaning of void, also in a theory-oriented way, and by his comment helps S1 to ‘see’ the meaning of void in this context more clearly.

Statements (2-4) serve as a theory-oriented way for the students to assess the usefulness of action (1) as an expression of understanding of an aspect of Java methods with the return value. The conclusion drawn by the students is that (1) is not an adequate action to achieve the intended end in this case. Relating to the discussion in Phase 3, about variation, we can see that in action (1) the student writes the expression that was the standard way of starting a method header in the previous part of the course, where methods without return value were introduced. Now, through the theory-oriented assessment (2-4) the students gain the shared insight that void should not be used here. This is a starting point for beginning to see that there could be other values in DoV1 as well as in DoV2. However, they have not yet come to grips with what should be written instead of void, but they now begin to actively look for variation in both DoV1 and DoV2.

As a consequence, in the next action (5), S1 erases void, so that the text public remains in the editor. In our interpretation, the students know that the public is not sufficient, there should be a longer expression, but what?

They proceed to discuss what type of value the method should compute (6-18) and they agree on double. Relating to our discussion in Phase 3, this establishes variation in DoV1. The students have now discerned both void and double as possible values in DoV1, which means that they have a clearer view of DoV1 than before entering this thread of learning.

Subsequently, in (19-28) the students continue to discuss how to express in Java that the method should return a value of type double. Student S1 now launches a new suggestion for what action to take (19-20): to keep public void in the method header and to indicate the return type double in the call to the method. Although S1 is not writing anything in the editor, we still interpret (19-20) as a practice-oriented way of expression towards an intended end, reflecting a revised, tentative understanding of the object of learning.

In (21–28) the two students try to assess the usefulness of this new suggestion:

• [Silence when the students do nothing. One of them changes back to the editor.]

• S2: What did it say? [Changes back to the browser, reading from the written instructions for the laboratory session:] ‘The method should have a parameter that tells how wide the world is’

• [Going back to the editor.]

• S1: What’s the name of it?

• S2: Do you have nothing there or do you have public return or … ? [Going back to the browser.]

• S1: You should have nothing. You may then write it here so you will know sort of

• [Marks the same text again in the written instructions for the laboratory session, see line 20]

• S2: Hmm … 

The students seem to divide their attention between two aspects of the method header, the input parameter (22) and the first part of the method header (25). The latter is where the return type should be specified. However, the students appear not to be sure about this and in the new suggestion (19-20), S1 explicitly proposes that the return type should only be visible in the call to the method, not in the method header. In (25), S2 seems to find this confusing: ‘Do you have nothing there or do you have public return or … ?’. Here, S2 uses language to problematise his friend’s suggestion and presents further alternatives along DoV1. In particular, the expression ‘do you have’ can be understood as indicating the principle rather than the specific. Consequently, in our interpretation, S2 takes a theory-oriented approach in (25). Next (26), S1 says ‘You should have nothing’, apparently confident about his answer. Note, that this is in conflict with (19), where he suggested void instead of nothing at all. In summary, in (21-28) S1 and S2 try to assess the suggestion made by S1 in (19-20). In this process, S2 takes a theory-oriented approach, reflecting about alternatives from a principled point of view. In the same process, student S1 uses a theory-oriented expression of a revised understanding, in response to the alternatives proposed by S2, and appears for the time being to be satisfied with the solution he arrives at. Student S2, on the other hand, uses the expression ‘Hmm … ’ (28). We interpret this as a signal that he is not convinced.

Next, the students focus on how to write the remainder of the method header and to compute the required value (29; 30–38). The discussion about how to express that the method has return value double continues in actions (39-47):

• S1: Could it maybe look like this? [Points to the method header for distanceToRightWall] distanceToRightWall, that’s maybe how to do it.

• S2: But I’m not sure, shouldn’t there be something more? Shouldn’t it be a return?

• S1: Yes, it must, there should be a return. What did the papers say?

• S2: In the very method … 

• [The students now look at some lecture notes.]

  S1: public class Resistor. Methods. [Leafs through the papers.] A name, it should be public or private, so we have already public, number of parameters … primitive, it should be void, double, … 

• S2: Okay

• [One of the students now writes double and then the method header looks like this:]

  public double distanceToRightWall()

• S1: Because it will give a double

• S2: Okay.

Here, S1 starts by pointing at an example method header in the browser (39), asking, ‘Could it maybe look like this?’. In our interpretation, he suggests yet another alternative in a practice-oriented way. Again, S2 seems to be unconvinced (40), and expresses this in a way that can be interpreted as reflecting a more theory-oriented view, looking for what is correct in principle: ‘Shouldn’t there be something more? Shouldn’t it be a return?’. This triggers student S1 to remember something about ‘return’ that had been mentioned in the lecture notes (41). As a result, the two students begin to look at the lecture notes (43). Here, S1 reads aloud from the notes, a theory-oriented account of the elements of a method header in Java (43). This seems to lead to a new understanding that one of the students expresses in a practice-oriented way (45) by writing double after public in the method header in the editor. In (46), S1 gives a theory-oriented rationale for this action and by his ‘Okay’ (47), S2 signals that now he is convinced.

The key points of the fourth phase of the analysis are summarised in Table 1. This table is a concise description of our interpretation of the interaction between theory-oriented and practice-oriented activities that occurred in the thread of learning in Appendix A.

5. Results

The main result of the present article is the new approach for analysing data. We have presented a case study where we have shown in detail how to apply the approach to empirical data, thereby demonstrating that it serves the intended purpose of allowing for analysis of the interaction between learning of theory and learning of practice in a learning session in a computer laboratory.

In addition, the case study has generated results that show the kinds of results our approach will yield. The result of Phase 2 of the analysis was the identification of two dimensions of variation (DoV1 and DoV2) and one relation (R1) that the students came to ‘see’ in the thread of learning that we analysed. From a variation theoretical perspective, this is what the two students in the case study learned about the object of learning during this sequence. The result of Phase 3 of the analysis was a description of the variation that was displayed in this thread of learning and that, according to variation theory, opened the possibility for the students to discern DoV1, DoV2 and R1. Finally, the result of Phase 4 was a description of the interaction between the students’ theory-oriented and practice-oriented actions in this thread of learning. This description is summarised in Table 1.

The design of Table 1 can be regarded as a result in itself. The structure of the table is intended to provide a clear overview of the actions that took place in a thread of learning and to separate between theory-oriented and practice-oriented actions. This means that the table can be used as a tool to assess the dynamics of the interaction between theory-oriented and practice-oriented actions in the thread of learning.

It can be observed that the transcript of the thread of learning is the result of an interpretation of the ‘raw data’, the video film. In that sense, the transcript can be said to be a result of Phase 1.

6. Discussion

6.1. Variation through Interaction between Theory and Practice

According to variation theory, the educator should consciously create learning contexts where variation and invariance are exhibited in ways that help students to ‘see’ additional dimensions of variation related to a certain object of learning (Marton et al. 2004). In Phase 2 of the analysis above, we identified DoV1 (the type of the value returned by the method) and DoV2 (the return type annotation in the method header) to be the dimensions of variation of relevance for the exercise the students were working with. Variation to exhibit DoV1 and DoV2 was embedded in the written instructions for the computer laboratory session. This is described in more detail in (Eckerdal and Thuné 2013), where the self-documenting on-line material for the computer laboratory session is analysed. Judging from the dialogue in Appendix A, it seems that the students had seen these dimensions of variation already before the beginning of the analysed sequence. They had ‘seen’ them in the sense that they were focally aware of their existence and relevance for the task at hand. However, they had not seen them very clearly, but rather obtained a ‘glimpse’ of each. In particular, concerning DoV2, they seemed to have a vague understanding of what would be possible expressions in this dimension and how these expressions should be interpreted. Already in line (18), the students agree that the type of the value returned by the method should be double. However, it takes until line (45) before the two students can express this in the annotation of the method header.

The analysis presented above, Phase 3 and 4, shows that additional variation is created by the students themselves in the thread of learning (1 – 45). This variation occurs through a combination of practice-oriented and theory-oriented actions. For example, the different practice-oriented actions in Table 1 represent suggestions for textual expressions that constitute ‘values’ in DoV2. The same holds for the theory-oriented problematisation (25). Tentatively, our interpretation of these observations is that the written instructions for the laboratory session helped the students to ‘see’ the dimensions of variation DoV1 and DoV2, by including examples and exercises exhibiting variation in ‘values’ in these dimensions. Having obtained a first ‘glimpse’ of these dimensions of variation, the additional variation created by the students themselves in shifting between practice-oriented and theory-oriented actions helped them to get a clearer view of the two dimensions of variation. This is line with the observation by Kullberg (2012) that students’ ability to create additional variation themselves has a significant impact on the learning outcome. What we see in our data is that the interaction between practical and theoretical considerations in the laboratory context helps the students to create such variation.

6.2. Interaction between Theory-oriented and Practice-oriented Learning Activities

In the practice-oriented elements of Table 1, the students suggest different ways to write the method header in order to express the type of the return value. Interpreted according to the model in Figure 2, these suggestions can be seen as ‘hypotheses’ about how to write the method header so that each new suggestion is based on and reflects the students’ evolving understanding of method headers for methods with return value in Java. Likewise, the theory-oriented elements in Table 1 can be interpreted according to the model in Figure 1 to be based on and reflect the students’ evolving understanding of method headers for methods with return value in Java. This specific example from our empirical data highlights that the two models, Figures 1 and 2, share two of their four nodes, the object of learning and the conception so that they can be combined into a single model, see Figure 3. According to this model, the student has a certain conception of the object of learning. By theory-oriented actions (using language to express an intended meaning) the student gives a theory-oriented expression of this conception and by practice-oriented actions (taking action to achieve an intended end) the student gives a practice-oriented expression of that same conception. Both of these ways of expressing the conception serve as ways for the learner to better grasp the object of learning, so that both theory-oriented and practice-oriented actions can lead to a modification of the student’s conception of the object of learning. The example in Table 1 illustrates how the interaction between practice-oriented and theory-oriented ways of expression leads to a gradually evolving conception of the object of learning. In the example, the interaction is successful and at the end the conception has evolved to a point where both the practice-oriented and the theory-oriented expressions become adequate for the task the students are working with in the lab session. In other words, in this example, the theory-oriented and practice-oriented actions mutually support each other, so that the students learn both theory and practice related to the task at hand.

Figure 3. This figure combines the intentional-expressive model of language use in learning (Anderberg et al. 2008), see Figure 1 above, and our own practice-oriented modification of that model, see Figure 2. The combined model highlights that the two separate models share two of their nodes, namely the object of learning and the conception. This serves to illustrate how the interplay between theory-oriented actions and practice-oriented actions can lead to a gradually evolving conception of the object of learning.

The model in Figure 3 is a way of describing the interaction between theory-oriented and practice-oriented actions in knowledge formation. The model is in line with and goes beyond (Eckerdal 2015) where we found that practical activities as well as conceptual understandings relate to dimensions of variation and that practical activities and conceptual understandings can be related to each other through common dimensions of variation.

It is interesting to note that the interaction between the theory-oriented and practice-oriented actions in the thread of learning analysed here seems to be driven by the students’ sense of mismatch between their theory-oriented and practice-oriented expressions of their conception of the object of learning. This indicates that the conception is not sufficiently developed to address the task at hand. If the conception would include all aspects required for the task at hand, it is likely that the students’ theory-oriented and practice-oriented expressions of the conception in relation to the task would match each other. However, when the conception is incomplete with regard to the task, there is ‘fuzziness’, so that the students can sense a mismatch between their theory-oriented and their practice-oriented expression of the conception. This is very clearly illustrated in the thread of learning discussed here, where the students never come to a point where they have written a complete Java method that could be tested by running it on the computer. Instead, the students in our case assess their practice-oriented actions, i.e. different suggested ways of writing method headers in Java, by making them subject to theory-oriented discussion (2 – 3) and problematisation (25), (40). This leads to a gradual evolvement of the conception. The students continue until they experience that their practice-oriented expression of the conception matches their theory-oriented expression of the conception. Then, they seem convinced that they have found a correct solution.

7. Conclusions

In the present article, we have proposed an approach for collection and analysis of empirical data concerning students’ learning of computer programming in the computer laboratory, related to both theory-oriented and practice-oriented learning goals. In particular, we are interested in using this approach with the purpose to gain a nuanced understanding of the interaction between how students learn theory and how they learn practice in the computer laboratory. In this paper, the aim has been to illustrate how our proposed approach to analyse data can be applied. To this end we have used data from one pair of students. In future work, the approach will be used on a larger dataset from an ongoing study (Eckerdal 2011).

A first conclusion is that the approach is suitable for its purpose. By using variation theory we were able to identify the variation that took place in the analysed sequence of the laboratory session, the ‘thread of learning’ in Appendix A. By the subsequent microanalysis, we managed to give a detailed description of practice-oriented and theory-oriented actions as well as of the interaction between those in the interaction between the students in that particular thread of learning. The two models in Figures 1 and 2 turned out to be useful in establishing a frame of mind for the microanalysis. However, as discussed above, the actual interaction between practice-oriented and theory-oriented knowledge formation that was identified in the analysis went beyond these two separate models. Consequently, we propose the combined model in Figure 3 as a basis for reasoning about the interaction between these two kinds of knowledge formation.

Based on the results of the specific analysis of empirical data presented in this article we conclude that, in the case analysed here, the students’ shifting between practice-oriented and theory-oriented actions helped them to create an additional variation that had a significant impact on the learning outcome. Through variation exhibited in the written laboratory instructions, the students got a first ‘glimpse’ of the dimensions of variation DoV1 and DoV2. The additional variation created by the students themselves in shifting between practice-oriented and theory-oriented actions helped them to get a clearer view of the two dimensions of variation and to use them in a meaningful way.

Another conclusion from our empirical data is that the interaction between theory-oriented and practice-oriented knowledge formation can be driven by students’ sense of mismatch between their practice-oriented and theory-oriented expressions of their conception of the object of learning. This mismatch indicates incompleteness in the conception, in relation to the task at hand.

In this article, we have analysed one example of successful interaction between practice-oriented and theory-oriented knowledge formation. In the on-going project mentioned above, (Eckerdal 2011), analysis of larger sets of empirical data will hopefully allow for a more elaborate description of what characterises such useful interaction as opposed to lack of interaction or harmful interaction that hinders learning towards either kind of learning goal.

Notes on contributors

Michael Thuné is Professor of Scientific Computing at the Department of Information Technology, Uppsala University. He has long experience in undergraduate and graduate teaching in computer science and scientific computing. He is a member of the Uppsala Computing Education Research Group.

Anna Eckerdal is Associate Professor of Computer Science with specialisation in Computer Science Education Research at the Department of Information Technology, Uppsala University. She has long experience of teaching mathematics, physics and programming at high school, and programming at undergraduate level. She is a member of the Uppsala Computing Education Research Group.

Additional information

Funding

This work was supported by the Swedish Research Council under Grant 2011-5924 and by Uppsala University Forum för ämnesdidaktiska studier.

Notes

1 It is interesting to note that David Hume (1739) made a similar observation long before modern variation theory: ‘Thus when a globe of white marble is presented [we are not] able to separate and distinguish the colour from the form. But observing afterwards a globe of black marble and a cube of white […] we begin to distinguish the figure from the colour […]’.

2 In this article, we focus on the lived object of learning, i.e. the object of learning as experienced by the students (Marton et al. 2004). A description of the intended object of learning (according to the teacher) and of the enacted object of learning (according to our analysis) will be the subject of separate reports. For the enacted object of learning, see (Eckerdal and Thuné 2013).

3 The dialogue between the students was in Swedish and has been translated into English by the present authors. In the transcription from the video, our comments on what the students do etc. are in brackets []. The code the students write in the editor or mark in the browser is in italics. To preserve the anonymity of the students, they are labelled S1 and S2.

4 The task to be performed by the method is to compute the distance to a wall. Our interpretation is that S1 is thinking about that at this point and happens to say ‘distance to the computation’ instead of ‘distance to the wall’.

Appendices

Appendix 1

Learning event: The students come to ‘see’ that the return value in the method header they are writing for this exercise should not be void but double. In addition they come to grips with how to express the return value in a method header in Java.

Methods that return values differ in several aspects from the methods that students had encountered prior to the lab session. One of these aspects is that the return value in the method header is not void. The return value is directly connected to the last statement in the method, the return statement, and also to how the method is invoked. In the following clip from the video (clip 13, time 1.30–5.00) the students start to write the method header in the editor.³

1. [One of the students writes:]

   public void

   [This is how all methods they have previously seen start.]

2. S1: We should write … and it will throw something back, and what would it be called?

3. S2: But void means that it shouldn’t … 

4. S1: Yes, no, that’s true

5. [Erases the word void in the editor:]

6. S1: But then it shouldn’t … 

7. S2: … that there will be no piece of text or... something happens here after all. [Points to the screen]. But void is only, or... because we don’t really want … 

8. S1: Yes it must simply mean that it doesn’t return a value.

9. S2: Mm

10. S1: But then we shouldn’t have … If it will return a value

11. S2: Will it?

12. S1: We actually want … 

13. S2: Okay.

14. [Opens the browser where it shows how the method is invoked.]

15. S1: … what’s it called, the distance to the computation⁴

16. S2: Is that the only thing we want?

17. S1: Yes, double distance

18. S2: Yes, okay

19. S1: But perhaps we could have void and then write this afterwards

20. [Points to the screen and marks the following text in the browser:]

    double dist = t1.distanceToRightWall(b);

    System.out.println(”Distance = “ + dist);

21. [Silence when the students do nothing. One of them changes back to the editor.]

22. S2: What did it say? [Changes back to the browser, reading from the lab material:] ‘The method should have a parameter that tells how wide the world is’

23. [Going back to the editor.]

24. S1: What’s the name of it?

25. S2: Do you have nothing there or do you have public return or … ? [Going back to the browser.]

26. S1: You should have nothing. You may then write it here so you will know sort of

27. [Marks the same text in the lab material again, see line 20]

28. S2: Hmm … 

29. [Marks and copies distanceToRightWall(b) from the browser and returns to the editor, copying it, but removes the parameter b. The header now looks like this:]

    public distanceToRightWall ()

30. S1: Like that

31. [Silence]

32. S2: Yes, well, but scroll up and check [Scrolls up to look at the other methods in the class.] But these are methods and that’s other that … [Scrolls up and down.]

33. S1: Okay. We only want to know the distance to the right wall and that’s probably not difficult to calculate.

34. S2: No.

35. S1: You just take … and we only measure … how did it do it? We put it on top of the previous, h is equal to

36. S2: No, but wasn’t it here, getWidth or?

37. S1: Well, yes

38. S2: But which World then?

39. S1: Could it maybe look like this? [Points to the method header for distanceToRightWall] distanceToRightWall, that’s maybe how to do it.

40. S2: But I’m not sure, shouldn’t there be something more? Shouldn’t it be a return?

41. S1: Yes, it must, there should be a return. What did the papers say?

42. S2: In the very method … 

43. [The students now look at some lecture notes.]

    S1: public class Resistor. Methods. [Leafs through the papers.] A name, it should be public or private, so we have already public, number of parameters … primitive, it should be void, double, … 

44. S2: Okay

45. [One of the students now writes double and then the method header looks like this:]

    public double distanceToRightWall()

46. S1: Because it will give a double

47. S2: Okay.

Appendix 2

This appendix contains a very brief introduction to programming for readers not previously familiar with that topic. The aim is to include just enough information to allow the reader to understand the examples discussed in the article.

A computer programme is written for some purpose. For example, the programme may be intended to be a tool for handling staff administration in a company. We can then say that ‘staff administration’ is the problem domain addressed by the programme. In the object-oriented approach to programming, the programme can be regarded as an implementation of a model of the problem domain. Different entities in the problem domain are modelled as objects. In the example of staff administration, one possibility can be to model each employee as an object. Employees can be affiliated with different divisions within the company, so perhaps each division is also modelled as an object, etc.

Different kinds of objects can do different things. For example, the programme may be written so that each division object is able to do a number of things, one of which could be to generate a list of all employee objects affiliated with the division. The part of the programme that prescribes how this list should be generated is then said to be a method of the division object. When the programme is executed and some other object asks the division object for the list of employees, then the method will be executed and the generated list of employees will be returned to the other object that asked for it. To continue with the same example, each employee object might have a method that returns the current monthly salary of the employee. Both the list of employees and the monthly salary can be regarded as values, albeit of different types. We speak of methods with return value and in the specification of the method the type of the return value has to be prescribed.

There can also be methods without return value, i.e. methods that do something, but without sending a data value in return to the object that asked for the method to be executed. As an example, we may think of a method that prints information on the computer screen. In the programming language Java that the students in our example worked with, the key word void is used to indicate that a method does not return a value.

Finally, during the lab session our students had two different ‘windows’ open on the computer screen. They wrote their own programme text in the editor window and they read instructions and examples of programme text in the browser window.