Identifying Computer Science Self-Regulated Learning Strategies Katrina Falkner, Rebecca Vivian and Nickolas J.G. Falkner School of Computer Science, University of Adelaide Adelaide, SA, Australia, 5005
[email protected],
[email protected],
[email protected] ABSTRACT
students continue to struggle with mastering these skills, both in terms of the development of programming skills and awareness and mastery of the software development process [8, 7]. In order to be successful, students need the required discipline knowledge as well as strategies for cognitive development and self-regulation [20]; Sheard et al [15] highlight the fact that development of deep learning strategies, self-regulation, abstract thinking and metacognitive strategies are vital in order to assist students in achieving success. A self-regulating student will set their goals, marshal their resources and then manage their time effectively [14] without this fundamental level of metacognition they cannot direct their knowledge in a useful and constructive manner. A significant aspect in the development of self-regulating learning (SRL) strategies is the ability to monitor and reflect upon those strategies within a discipline context, enabling the individual to identify their success or failure, identify strategies to apply in specific contexts and develop new strategies [3, 18]. Allwood [1] identifies that novices tend to use more general strategies rather than the more powerful specialised strategies employed by experts. The transition from novice to expert is assisted by reflection on prior successes and failures [13], followed by analysis of potential areas for improvement. Before we can assist our students in the process of reflection and self-regulation, we must identify and articulate successful SRL strategies for the CS context [6]. Therefore, we must develop an understanding of those discipline specific strategies that can be successfully learnt and adopted by students [10]. In this paper, we analyse students’ reflections on their SRL processes as applied to introductory software development. Using a grounded theory model of qualitative analysis, we are able to identify SRL strategies that are specific to CS, expressed in the students’ own words and relative to their own experiences. In our previous work, we establish that students who have a less developed understanding of software development and are less successful in their programming activities have a higher reliance upon generic self-regulatory mechanisms, and are unable to articulate discipline-specific techniques to improve their processes. In this paper, we extend this work through a detailed analysis of the nature of these discipline-specific SRL strategies and how these strategies contribute to their learning. We adopt a mixed methods approach to our study, combining qualitative and quantitative data collection, driven by grounded theory [19], using an open coding process to analyse and identify representative strategies within our case study. In our study, 85 students, who were enrolled in an
Computer Science students struggle to develop fundamental programming skills and software development processes. Crucial to successful mastery is the development of discipline specific cognitive and metacognitive skills, including self-regulation. We can assist our students in the process of reflection and self-regulation by identifying and articulating successful self-regulated learning strategies for specific discipline contexts. However, in order to do so, we must develop an understanding of those discipline-specific strategies that are successful and can be readily adopted by students. In this paper, we analyse student reflections from an introductory software development course, identifying the usage of self-regulated learning strategies that are either specific to the software development domain, or articulated in that context. This study assists in the understanding of how Computer Science students develop learning skill within the discipline, and provides examples to guide the development of scaffolding activities to assist learning development.
Categories and Subject Descriptors K.3.2 [Computing Milieux]: Computers and EducationComputer and Information Science Education
General Terms Human Factors
Keywords Computer Science Education, Self-regulation strategies
1.
INTRODUCTION
Introductory programming courses pose many challenges for students, as a large number enter Computer Science (CS) programs with little or no prior discipline experience. Students are required to master a wide range of discipline, cognitive and metacognitive skills and studies show that our Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from
[email protected]. ITiCSE’14, June 21–25, 2014, Uppsala, Sweden. Copyright 2014 ACM 978-1-4503-2833-3/14/06 ...$15.00. http://dx.doi.org/10.1145/2591708.2591715.
291
introductory software development course, participated in a multi-part reflection process, documenting their software development and learning processes and their perceived successes and failures. We identify that while some students are able to articulate mature SRL strategies that are embedded within their discipline, others struggle to understand how their learning may be adapted to the specific requirements of their discipline. In our conclusions, we propose the need for targeted scaffolding to address this issue.
2.
pleting a course on introductory programming were asked to provide advice for the next cohort. Hanks et al report a combination of general advice (63%), attitudinal advice (34%) and programming-specific advice (23%), identifying a relative dearth of work on discipline-specific strategy.
3.
METHODOLOGY
In this paper, we undertake a quantitative and qualitative analysis of student reflections on their software development processes and SRL strategies in order to identify those strategies that are specific to CS. We explore the identification of such strategies within a case study of an introductory software development course. The research question that we ask is: what SRL strategies do first-year programming students articulate as using in programming assignments and which are specific to CS?
RELATED WORK
Zimmerman [20] defines self-regulated learners as those that ‘plan, set goals, organise, self-monitor and self-evaluate’. Research suggests that the development of SRL strategies is a complex issue, associated with the perceived purpose of engagement with the activity, the student’s self-perception of their ability, and the situated context of the activity these three factors impact upon the self-regulation strategies that the student then considers relevant for application [9]. Lichtinger and Kaplan [6] call for the identification of domain and context-specific purposes of engagement, and the articulation of types of SRL strategies that would be desirable for students within that domain. Further, the development of effective domain-specific SRL strategies, such as domain-based design and planning, can assist in the application and development of other SRL strategies [16]. Novices in any area lack the detailed, well-organised domain knowledge that is necessary to produce effective problem solving processes - this may be seen in software development as opportunistic and arbitrary design and implementation [11]. Novice problem solvers struggle to understand conceptually difficult problems, due in part to their lack of deep discipline knowledge, and tend to approach the problem using known techniques from their knowledge of programming languages, and a process of ‘impasses and local repairs’ [16]. As they are unskilled in planning, novices also tend to delay planning relevant to the problem solving process itself until it is absolutely necessary, imposing further delays in their development of that skill set. There has been considerable work exploring mental models and learning strategies associated with introductory programming, although little explicitly addresses SRL strategies applicable to the software development process itself. Bergin et al [2] explore the relationship between SRL and introductory programming performance, specifically the use of metacognitive strategies, finding that students who perform well in programming tasks also exhibit frequent use of metacognitive behaviours. Violet [17] explores the cooperative development of metacognitive strategies for an introductory computer science course, involving students in both the development of the strategy and the identification of modelling and coaching procedures designed to guide students through the strategy. The strategy introduced builds upon theories of social constructivism and cognitive development, and follows a simple five-step process of software design. They found that this instructional approach resulted in significant changes in students’ cognitive learning outcomes. Caruso et al [4] explore a grounded theory analysis of students’ reflections on their software development process, identifying a focus on non-discipline aspects of self-regulation and an inability to develop appropriate plans for improving their SRL strategies. Hanks et al [5] identify similar results in a ‘saying is believing’ experiment where students com-
3.1
Research Method
An instrumental case study was a suitable approach for answering our research question as it allows us to use a particular case as an illustration to identify and elaborate SRL strategies within software development. Case studies capture the complexities of a phenomenon; such detailed observations cannot be captured in surveys or experimental designs [12]. Although still a small sample size, the number of participants in our study, 85, is sufficient, with samples sizes for qualitative research ranging from 1 to 99, with an average sample size of 22. This project has adopted a mixed-method case study design where both quantitative and qualitative data were collected. The data were subjected to grounded theory analysis, starting with a process of open coding, before proceeding to axial coding. Grounded theory involves the establishment of a coding framework and analysis environment derived from the data itself. Grounded theory differs from other types of qualitative analysis in that a specific, structured coding framework is not employed. The first stage in grounded theory development is open coding, where the data is broken down into distinct segments in order to obtain the full collection of ideas and concepts present in the data, without regard to how it will be used. Subsequently, axial coding is employed, where the coding framework developed during the open coding stage is refined and reorganised into specific categories, informed by theoretical frameworks and comparison within the data. There are significant advantages in the adoption of a grounded theory approach, in contrast to directed content analysis with an established coding framework, including removing the potential to force fit observations into existing categories and misclassification. However, we subsequently align our coding framework with that of Zimmerman [20] in order to aid comparison. The case considered in this research project is an introductory software development course at the University of X. Students within this course have completed 1-2 prior programming courses, providing them with competencies in the application and tracing of fundamental programming constructs, and design skills within small scale problem solving. The learning objectives for this course include awareness and application of simple data structures, related algorithms and algorithm complexity, and initial experiences in mediumscale problem solving and software engineering. Students are assessed on the functional outcome of their programming assignments, and their process, via design documents and
292
Table 1: CS-specific SRL strategies and their indicated frequency (total count = 255). Category
Table 2: General SRL strategies and their indicated frequency (total count = 455).
Freq
%Freq
Strategy
Freq
%Freq
255 119 45 22 20 18 15 9 4 3
54.5% 25.4% 9.6% 4.7% 4.3% 3.9% 3.2% 1.9% 0.9% 0.6%
Assess Difficulty Identify new knowledge that is needed Assess own ability Assess difficulty - no specific strategy Understand question Compare with previous Specification – length, assessment Ask friends
127 42 24 23 20 12 5 1
27.9% 9.2% 5.3% 5.1% 4.4% 2.6% 1.1% 0.2%
Decompose problem Use decomposition to develop testing strategy Create plan from design
53 53 20
16.24% 11.9% 4.49%
Time Management Prioritisation Design as aid to time management Allocate time for prototyping
72 63 8 1
15.4% 13.5% 1.7% 0.2%
Time Management Fixed timetable - sufficient Time Estimation Overestimate time Time management - no specific strategy
105 59 26 16 4
23.1% 13.0% 5.7% 3.5% 0.9%
Build Knowledge Talk to friends or lecturers Access resources
81 42 39
17.8% 9.2% 8.6%
Assess Difficulty Algorithm complexity Prototyping and experimentation Use design to assess difficulty Number of concepts, stages or components Need for design driven by complexity
54 23 12 10 7 2
11.5% 4.9% 2.6% 2.1% 1.5% 0.4%
Decompose problem Create plan from specification Decompose - no specific strategy Frequent accomplishment
72 58 12 2
15.8% 12.7% 2.6% 0.4%
Build Knowledge Practice writing code
10 10
2.2% 2.2%
Personal Management Reflection and changing stratagies Self assessment Avoid sources of anxiety Avoid working late Reduce distractions
70 49 10 8 2 1
15.4% 10.8% 2.2% 1.8% 0.4% 0.2%
Development Process Use diagrams to describe or explain design Use design to understand problem or code Develop design before coding Document design or code for future use Validate design Comprehensive test cases Develop design concurrently with coding Develop design after coding Use design principles or standards
! ! ! descriptions !
! ! ! !
of testing strategies. In addition, the course in! cludes two structured reflective exercises requiring students to describe their software development processes and how they have changed. These exercises provide a small contribution, less than 2% in total, to their final grade.
3.2 Coding Framework The basic unit of analysis in this project were coding units [19], including sections of text responses, of any size. Within the open coding stage, sections of text, such as a sentence, word or phrase, were coded while the selection represented a single idea or concept related to SRL strategy. In excess of 300 pages from 85 student reflections were coded using the qualitative software NVivo (version 10) defining an initial set of 78 distinct codes. The researcher methodically worked through the student reflections, coding their observations either to existing nodes within the framework or to a newly created node, identifying a description of the newly created node and exemplar. During the axial coding stage, the researcher worked in collaboration with the project team to iteratively refine the established codes into categories, merging codes where appropriate, informed by existing coding categories related to SRL as defined by Zimmerman [20] and identifying discipline-specific categories as derived from the data (see Table 1). The content analysis frequencies, combined with qualitative examples of student descriptions of their behaviours and strategies, are discussed further below.
4.
!
general strategies. Table 1 identifies a clear focus on software design processes, with a dominant use of diagrams to help describe or explain their software design, and the development of sub-goals based on their software designs (and subsequent software decomposition). Prioritisation is also indicated as a key strategy - in this case referring to the prioritisation of design activity over subsequent implementation and testing activities. Assessing problem difficulty is a crucial step in planning and goal-setting, with several CSspecific strategies identified within this category. Table 2 reports the identified general SRL strategies; these strategies were frequently articulated within the CS context, with contextual description added to illustrate how the strategy was employed or modified within the domain. Students also indicated strategies that led to unsuccessful behaviours. The majority of these strategies are general strategies, and are frequently in direct opposition to a contrasting strategy found to be successful. Table 3 presents those general strategies found to be unsuccessful by students, focusing primarily on poor time management, inadequate goal setting and insufficient planning strategies. Interestingly, students identified poor strategies associated with focusing their activity based on the assessment, i.e. directing their effort based on how many marks individual parts of the assignment were worth. As a smaller fraction of the marks was associated with design than implementation functionality, as a consequence, these students did not place a high priority on undertaking design activities, and typically developed a design document subsequent to the completion and testing of their code. Table 4 describes the CS-specific strategies associated with failure, reflecting this observation. We further analysed the successful SRL strategies (both general and CS-specific) in terms of their relationship with the coding framework established by Zimmerman [20] (see Table 5). Approximately 50% of the strategies identified correspond to those identified by Zimmerman, with the majority (28.9%) related to goal-setting and planning.
QUANTITATIVE ANALYSIS
Our analysis reveals that students utilise a range of SRL strategies, including general strategies, strategies that are adapted and articulated within the context of CS, and strategies that are specific and newly introduced to address the learning challenges of CS. Further, we are able to categorise these strategies as (a) those that were perceived to lead to success, and (b) those that led to failure. Tables 1 and 2 present the identified strategies associated with successful behaviour, classified as either CS-specific or
293
Table 3: General unsuccessful SRL strategies and ! their !indicated frequency (total count = 222).
Table 5: Reclassification of strategies according to Zimmerman
Freq
%Freq
Strategy
115 42 33 14 11 5 5 4 1
51.8% 18.9% 14.9% 6.3% 5.0% 2.3% 2.3% 1.8% 0.5%
Assess Difficulty Underestimated complexity Lack of fundamental skills Misunderstand requirements Did not assess difficulty
57 35 13 7 2
25.7% 15.8% 5.9% 3.2% 0.9%
Other Goal-setting and planning Organising and transforming Seeking information Seeking social assistance Reviewing records Environmental restructuring Self-Evaluation Self-consequences Keeping records and monitoring Rehearsing and memorising
Personal Management Assessment achievement focus No reflection leading to change
33 31 2
14.9% 14.0% 0.9%
Build Knowledge Did not seek help or ignored help Not attending class
10 8 2
4.5% 3.6% 0.9%
7 7
3.2% 3.2%
Strategy Time Management Poor prioritisation of competing demands Underestimated time Poor time management Fixed timetable - insufficient Procrastination Time management - no specific strategy Avoiding difficult tasks Assume nothing will go wrong
Decompose problem Did not decompose
!
5.
! ! ! QUALITATIVE
Freq
%Freq
70 40 29 1
100.0% 57.1% 41.4% 1.4%
49.7% 28.9% 6.9% 5.2% 5.1% 1.4% 1.3% 1.2% 0.2%
0 0
0.0% 0.0%
gesting the introduction of appropriate diagramming processes as an appropriate scaffolding technique. ‘This was the first time I used diagrams to aid in design. I initially did this as I was aware the tutors were expecting to see it but I actually found it very useful. Particularly for inheritance I found that using a diagram easily allowed for a visual representation of the relationships between classes and enabled me to mentally encapsulate the project to see where polymorphism could be used.’
Table 4: CS-specific unsuccessful SRL strategies and their indicated frequency (total count = 70). Development Process Coding before Design Incomplete design Insufficient testing
%Freq
418 243 58 44 43 12 11 10 2
!
!
Strategy
Freq
This typically resulted in increased awareness of the utility of these strategies for their adoption in future tasks, and a reconceptualisation of design as a strategy in itself to assist understanding of the problem. Some students expressed quite mature strategies for their development process, citing the use of formal design principles, design tools such as UML and comprehensive test case development.
! ANALYSIS
Our analysis so far indicates that students recognise and report both general and CS-specific SRL strategies. In this section, we explore further the key categories of CS-specific strategies that we have identified.
‘It was helpful to look back to the design while writing code to compare the initial design to the product in progress and record alterations and trace the repercussions of these alterations.’
5.1 Design as Strategy 5.2
Design is a challenging process for our students to learn as they transition from novice to expert programmers [11], with many of our students fixating on design as an artefact rather than a process or strategy in itself [Reference withheld]. The lack of understanding that design is a process means that students struggle to form consistent strategies to assist their process. Many students were able to articulate the importance of completing a design prior to initiating code implementation, represented as a positive tradeoff between spending time initially in the design phase to save time later in the code implementation and testing phases (prioritisation); however, they were less consistent in the adoption of strategies that reflected this understanding. A small number of students initially indicated that they completed their design (as an artefact) subsequent to the completion of their task - they indicated that this was successful in that they completed their task, but also indicated that they were not able to conceptualise any strategies to help them explore and develop an appropriate mental model for the design process. In these cases, teaching assistants would provide an initial set of strategies that students could try, such as creating class diagrams, flow charts of process, and algorithmic descriptions. Use of diagrams was clearly identified as the most useful strategy in our case study, sug-
Decomposition
Many students reported strategies to assist in decomposing a problem into sub-goals, including general strategies based on using available resources to guide their decomposition, or through the use of their design activity to produce a decomposition plan. Many students identified that setting sub-goals and problem decomposition was an appropriate strategy, but felt that they did not have the required skills to do this. As the assignments were described in a stepwise fashion, the students quickly identified that they could substitute the assignment specification for a plan even though this was not the intention of the lecturer and rarely suitable. This behaviour effectively interfered with a significant goal of the assignment - to establish design skills, and provides support for explicit scaffolding around design activities. ‘For a more systematic approach on an assignment, I usually chose to break an assignment into tasks according to the given tasks that has been listed out in the assignment question. Since they are listed out by an experienced programmer, the steps are always helpful in a way that they guide me in completing the assignment.’
294
As students developed more experience with software development, they were able to identify more mature strategies for setting sub-goals, as indicated below. This strategy exhibits an understanding of the crucial requirement of design activity as part of the planning process.
Students identified more mature goal-setting and time management strategies that were tightly linked to their software development process, identifying CS-specific strategies in assessing task difficulty that assisted in their planning.
‘At the start of the semester, I followed the ‘Stage’ system given in assignments. I would complete coding one stage at a time. This was an effective way to ensure I would get maximum marks for the work I did, even if I didn’t finish everything on time. Once I became more confident in my ability to always complete assignments on time, I decided that this was not the most efficient way to code. From then on I coded one class at a time. Once each class was working, I could treat it as a ‘black box’ and did not need to return to it for further modifications. Treating my assignments as a whole project rather than stages reduced the need to modify my design or code from earlier stages to adapt to requirements for later stages.’
A significant factor in students’ planning is the ability to accurately assess the difficulty of the required task. Again, the strategies identified varied in maturity, with some use of simplistic strategies for assessing task difficulty, such as being guided by the length of the question, the marking scheme or the deadline, and some CS-specific strategies, such as counting the number of functions or software objects to be developed.
5.4
‘Reading the question and searching for the number of functions required was generally a good indicator’ Students identified the need to analyse the complexity of the algorithms needed for the task, however, teaching assistants needed to demonstrate strategies for how they would do this, such as assessing their own familiarity with the concepts of algorithms required, comparison with previous work, or identification of new skills needed. Further, students identified that the activity of design forms a crucial part of this goal-setting process, rather than being solely part of the task itself. This distinction is crucial in establishing the purpose of design as a process rather than as an artefact for assessment. Prioritising design in their time management led to successful code implementation and testing, and ultimately, successful completion of the assignment.
The adoption of decomposition strategies reflected awareness of the relationship between software decomposition and testing strategies, i.e. performing unit-based testing or testdriven development as a natural result of decomposition. ‘This allowed me to test the code in small segments and to assess if my plan was really the best way handle the ‘lower’ classes before writing the ‘higher’ classes.’
5.3
Assessing Task Difficulty
Time-management and Planning
‘Once a proper design had been written up, the real scope of the project became clear and allowed me to assess the difficulty of it and to more accurately estimate the time that I would require to complete it.’
Students expressed a strong reliance on fundamental goalsetting and planning strategies as supporting their learning, with time management and prioritisation identified as key to success. We are able to identify both simplistic and mature strategies in relation to goal-setting and planning. A considerable number of students indicate a strategy based on fixed time management - always commencing their work on a fixed day, rather than varying their timetable according to the difficulty of the task.
At the more mature level, strategies that explored the use of prototyping and experimentation as a crucial aspect of understanding the task, and accordingly necessary for understanding both the design complexity and algorithmic complexity were also identified. Teaching assistants supported this through suggestions to compare and contrast design choices, leading to the need for small-scale prototyping and evaluation.
‘I often started to do my assignments on the day just before the due day.’ Students also identified a fixed timetable strategy as leading to failure, with the difference being the amount of time allocated. Students who initially worked to a fixed timetable but were not successful identified that the issue was one of insufficient time, and responded by increasing the time allotted to their work, although still retaining a fixed timetable.
‘I assessed the difficulty of an assignment, along with how I would approach the problem by researching, experimenting and prototyping.’
6.
‘After [practical X] I realised that I couldn’t just run head first into every practical two days before it was due.’
CONCLUSIONS
In our analysis, we identify examples of successful SRL strategies within the context of introductory software development, consisting of general strategies reconceptualised within the CS context, and CS-specific strategies. These strategies provide guidance in the development of scaffolding activities to assist in learning the process of software development, specifically:
‘I believe that if I set myself out to complete the assignment a day or two before the due date then even if I didn’t complete it but still got as far as I did normally, it would allow me the next two days to fix up and make sure maybe get the rest of the practical done.’
• The introduction of diagrams, i.e. class diagrams or flow charts, as an explicit, early design activity.
295
• Assessment of task difficulty, incorporating the identification of needed skills, leading to the development of time management and sub goal planning.
[5]
• Explicit conceptualisation of design as part of the software development process, linked to the above activities, and viewed as an iterative process.
[6]
• Explicit inclusion of experimentation as part of design, incorporating activities that require students to explore alternative designs, and their evaluation and comparison.
[7]
Caruso et al [4] identify that students must develop their own strategies in response to their own experiences. In our work, we have identified that explicitly scaffolding strategyrelated activities can assist in this process. We intend to explore explicit scaffolding related to the successful SRL strategies identified in this study, specifically the introduction of scaffolded design activities [17] to assist in understanding and assessing problems, prototyping and experimentation with design choices, design as decomposition, and creating informed time management plans. Allwood [1] identifies that novices tend to devote less time to understanding and exploring the problem, and instead try to move immediately to solving the problem using a known solution. It is apparent in our analysis that the process of understanding programming problems, involving assessing task difficulty, design choices and planning, is complex with many different, inter-related strategies employed by our students and requires explicit scaffolding for development. The frequent adoption of design-based decomposition as a planning strategy warrants further discussion. Although a successful strategy for many students, particularly through related adoption of frequent testing strategies, it was also evident that students were regularly completing each individual component, i.e. function or class, without necessarily thinking about how that component related to the whole. This supports previous studies, which found that novices did not consider how individual components would interact with other components, and did not have a clear holistic understanding of their solution, which is in contrast to behaviours exhibited by experts [1, 11]. Accordingly, there is motivation to explore appropriate scaffolding to help students visualise component interactions and to explicitly address integration concerns at early stages.
7.
[8]
[9]
[10]
[11]
[12] [13] [14]
[15]
[16]
REFERENCES
[1] C. Allwood. Novices on the computer: a review of the literature. International Journal of Man-Machine Studies, 25:633–658, 1986. [2] S. Bergin, R. Reilly, and D. Traynor. Examining the role of self-regulated learning on introductory programming performance. In Proceedings of ICER’05, pages 81–86, 2005. [3] R. Cantwell and P. Moore. The development of measures of individual differences in self-regulatory control and their relationship to academic performance. Contemporary Educational Psychology, 21:500–517, 1996. [4] T. Caruso, N. Hill, T. VanDeGrift, and B. Simon. Experience report: Getting novice programmers to think about improving their software development
[17]
[18] [19]
[20]
296
process. In Proceedings of SIGCSE’11, pages 493–498, 2011. B. Hanks, L. Murphy, B. Simon, R. McCauley, and C. Zander. Cs1 students speak: Advice for students by students. In Proceedings of SIGCSE’09, pages 19–23, 2009. E. Lichtinger and A. Kaplan. Self-Regulated Learning, chapter Purpose of engagement in academic self-regulation, pages 9–19. Jossey-Bass, 2011. R. Lister, E. Adams, S. Fitzgerald, W. Fone, J. Hamer, M. Lindholm, R. McCartney, E. Mostrom, K. Sanders, O. Seppala, B. Simon, and L. Thomas. A multi-national study of reading and tracing skillls in novice programmers. SIGCSE Bulletin, 36(4):119–150, December 2004. M. McCracken, V. Almstrum, D. Diaz, M. Guzdial, D. Hagen, Y. Kolikant, C. Laxer, L. Thomas, I. Utting, and T. Wiusz. A multi-national, multi-institutional study of assessment of programming skills of first-year cs students. SIGCSE Bulletin, 33(4):125–140, 2001. S. Paris and J. Turner. Student Motivation, Cognition and Learning: Essays in Honor of Wilbert J. McKeachie, chapter Situated Motivation, pages 213–237. Hillsdale, N.J.: Erlbaum, 1994. V. Ramalingam, D. LaBelle, and S. Wiedenbeck. Self-efficacy and mental models in learning to program. In Proceedings of ITiCSE’04, pages 171–175, 2004. P. N. Robillard. The role of knowledge in software development. Communications of the ACM, 42(1), January 1999. M. Sandelowski. Sample size in qualitative research. Research in Nursing & Health, 18(2):179–183, 1995. D. Schon. The Reflective Practitioner: How Professionals Think in Action. Basic Books, 1983. G. Schraw, K. Crippen, and K. Hartley. Promoting self-regulation in science education: Metacognition as part of a broader perspective on learning. Research in Science Education, 36(1-2):111–139, 2006. J. Sheard, Simon, M. Hamilton, and J. L¨ onnberg. Analysis of research into the teaching and learning of programming. In Proceedings of ICER’09, pages 93–104, 2009. M. Veenman, J. Elshout, and J. Meijer. The generality vs domain-specificity of metacognitive skills in novice learning across domains. Learning and Instruction, 7(2):187–209, 1997. S. Violet. Modelling and coaching of relevant metacognitive strategies for enhancing university students’ learning. Learning and Instruction, 1:319–336, 1991. P. Winne. Inherent details in self-regulated learning. Educational Psychologist, 80:284–290, 1995. Y. Zhang and B. Wildemuth. Application of social research methods to questions in information and library science. Westport Conn: Libraries Unlimited, 2009. B. Zimmerman. A social cognitive view of self-regulated academic learning. Journal of Educational Psychology, 81(3):329–339, 1989.
