Can everybody learn to code? Computer science community perceptions about learning the fundamentals

of programming Rebecca Vivian Katrina Falkner Claudia Szabo

School of Computer Science The University of Adelaide South Australia, Australia

firstname.lastname@adelaide.edu.au

ABSTRACT Recently, we have seen a wave of initiatives that encourage everybody (from children to adults) to learn to code and many countries implement new K-12 computing curricula. However, research has identified the numerous challenges experienced by students learning to code. With much of the literature focused on student perceptions and capabilities, what insight might the computer science (CS) community offer about learning to code that may guide future directions in K-12 practice and research?

We invited the CS community to respond to an online survey about learning to code. This survey forms a pilot to determine whether the topic warrants further exploration. We explore the responses in light of the introductory programming literature and Mindset Theories to identify perceived capabilities required, the challenges and potential barriers to learning to code.

Our results were based on a small sample, mostly from Australian academics and IT professionals. A majority perceived that anybody could learn to code, with effort and motivation, however, that more advanced levels of programming require mathematical logic, a desire and ability for problem-solving and abstract thinking. A variety of challenges were identified, which may have implications for CS education and research. The findings warrant further exploration into the area of CS community perceptions, particularly with educators of introductory programming courses.

Categories and Subject Descriptors K.3.2 [Computers and Education]: Computer and Information Science Education – computer science education.

General Terms Computer Science Education and learning.

Keywords Introductory programming, university students, perceptions.

1. INTRODUCTION The ‘learn to code’ movement has emerged with initiatives targeted at women and girls (She++, Girls Who Code, She.Codes), children (Scratch, Code Clubs, Code.org, Code Avengers) and adults (edX, Khan Academy, Code School, Code Academy), founded on inspirational videos, celebrity endorsements, idols in digital technologies development, gamification and competitions, among others. The intention is to empower individuals to be more than consumers and users of digital technologies, by providing them with the opportunity to develop skills to be creators of digital technologies and software. Additionally, we have seen a wave of reports urging the introduction of computing curriculum into schools along with some countries implementing new computing curriculum [1, 4, 17, 36, 38, 39, 44]. However, it is known that introductory programming courses at university are challenging for many and that while some students excel, others struggle with mastering programming skills and development processes [19, 20, 22, 25, 31]. First year students in introductory programming courses reportedly drop-out for a number of reasons, including difficulties in understanding course topics, a lack of motivation, poor time management, course arrangements and a preference for other courses [19, 20]. Teachers of introductory courses also recognise the difficulties that students face, citing theory and computer science concepts as well as the ability to apply knowledge to be most challenging for students [19].

With a global movement that encourages everybody to learn to code, what can we learn from the challenges identified in introductory programming literature and how might this drive future research and practice? Currently much of the existing literature is based on students’ experiences and perceptions, but can the CS community offer insight, in terms of learning to code in the scope of a learn to code movement? In order to explore the topic, we conducted an online open-ended survey and sought CS community participation. We asked the participants to share their perceptions about the ease of learning to code and what they perceive to be the required capabilities and challenges of learning the fundamentals of programming. We drew on the literature about introductory programming and applied a lens of Mindset Theories, such as Attribution Theory [42, 43] and implicit theories of intelligence [5, 11] as a guide to interpret participant responses.

To begin, we provide an overview of the ‘learn to code’ movement and new computing curricula. We review findings about learning to code from existing introductory programming research. Following, we present the literature on mindset theories and how they assist us to understand learning new subject areas, before moving on to present the findings obtained through our pilot survey into CS community perceptions of learning to code.

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 Permissions@acm.org.

Koli Calling '14, November 20 - 23 2014, Koli, Finland Copyright 2014 ACM 978-1-4503-3065-7/14/11…$15.00 http://dx.doi.org/10.1145/2674683.2674695

41

2. LITERATURE 2.1 The ‘learn to code’ movement New computing curricula are being introduced around the world, with a number of countries in Europe considering their adoption or already implementing curriculum into schools. Two examples include UK [4] and Australia [1], which have introduced computer science concepts and programming to children in the primary and high school year levels. From Stage 1 in the UK curriculum (5 years of age), students learn about algorithms and are expected to apply logical reasoning to create and debug simple programs. In Australia, students begin by developing the fundamentals of computational thinking (CT) and an understanding of algorithms and start to apply their skills to visual programming from Year 3 (8 years of age). From Year 7 onwards, children start using general-purpose programming languages. In these contexts, as will be the case for many others, countries face the challenge of preparing teachers in terms of new discipline knowledge, skills in programming, the availability of resources and the ability to confidently implement learning activities [7].

Currently, a number of tablet and browser-based applications are available to teach 5-7 year olds the fundamentals of programming. These programs typically involve the use of colourful pre-literate symbols that children drag and drop (e.g. ScratchJr, Tynker) as well as tangible programmable robots such as the Beebot. The goal of using such tools is to develop skills in navigational language, following and providing instructions, and logical thinking. In the primary years (7- 12 years old) students begin to use applications and software that involve combining colourful text-blocks by drag and drop. The blocks represent programming statements and children use the blocks in ways that involve iteration, branching, input and output to create digital solutions (e.g. Scratch, Alice, Pencil Code) or to solve problems (e.g. Blockly, Lightbot). In the middle primary to high school years, students can begin to use general-purpose programming languages that involve writing and de-bugging programs. There are still child-friendly environments where youth undertake tasks or challenges while learning a programming language or by applying knowledge to create their own solutions. For example, students can learn the basics of JavaScript while creating digital drawings (Khan Academy) or by creating a game (Code Avengers), or moving a character (Karel the Dog). For the adult years, face-to-face programming courses may exist, or individuals can participate in free (or paid) online or face-to-face courses, such as those offered through edX, Coursera, Khan Academy, among others. Of course, adults can still learn the fundamentals of computer science concepts and programming statements through children’s visual programming environments such as Blockly and Scratch. While these are just a few suggestions, numerous applications and instruction-led courses are emerging.

While there are a number of visual and general-programming opportunities available, little is known about how students experience programming in the K-12 year levels, as a majority of the existing research across K-12 is based on the impact of outreach initiatives on student and engagement and interest in computer science career pathways [7]. Further, as the coding movement is new, little research is available that explains how adults undertaking online self-paced or instructional-based introductory courses experience learning code and outcomes.

2.2 Introductory programming research While we know little about the K-12 experience of programming, we can learn from what is known about introductory programming

experiences at the university level as a guiding point. While such courses are starkly different to early years and primary years’ visual programming applications, such findings may be applicable to the middle and upper year levels when students encounter general-purpose programming environments as well as for the teachers implementing learning activities. However, CT and programming in the early years is a new area and so it cannot be ruled out that young children, although using a different context, do not experience the same challenges or require similar skills.

In university-level introductory programs, a number of students struggle with mastering programming skills and development processes [19, 20, 22, 25, 31, 33]. It is unusual for learners to write robust and perfect code on their first attempt in introductory programming, however, some students seem determined to persist longer than others and while some learners become quickly frustrated and lose confidence, others persist without complaint. The reason as to why some are more determined than others is relatively unknown [33]. Some argue that how learners cognitively approach and experience learning tasks influence motivation toward the task and persistence [5].

Studies have found that prior programming experience plays a part in a student’s learning experience and that as students progress through computing degrees self-efficacy in programming increases [29]. Ultimately, an experience of poor performance in introductory programming may have a negative influence on a student’s emotional state and desire to persist at learning to code. A negative attitude towards programming was something experienced by students at the University of Cape Town. The Information Systems (IS) department developed a course where students, not majoring in computer science, were introduced to problem-solving, coding, and testing issues through an action learning cycle and that, by third year, required students to develop a project from conception to readiness to implement [31]. Through a phenomenological approach of interview data, the researchers identified that the mention of programming evoked a strong sense of fear, anxiety, apprehension and stress and this was projected through dialogue when the students spoke about programming. The fear invoked by learning to program and the challenge of the act reportedly affected the participants’ enjoyment and created feelings of self-doubt, apprehension, and lack of confidence.

It is suggested that negative experiences, where students attribute failure to ability can potentially cause students to perceive that programming is attributed to innate abilities beyond their control [33]. Perceptions of performance and the causes for success and failure may impact on future performance and decisions to continue with programming. Emotions and perceptions play a role in learning to program, as it was found that students who demonstrated optimistic attributions to learning were found to perform better than those with less optimistic views and, further, students who reasoned that positive events were attributed to the self (internal factors) and unchangeable (e.g. ability) had better grades than students with pessimistic attributions [14].

The transition from novice to expert programmer is said to be assisted by reflecting on previous success and failures and finding ways to improve performance [32].When reflecting on strategies for success, programming students have been found to focus on describing non-discipline specific strategies [12] such as those focused around self-regulation. This is similar to a study of students’ self-reflection on their learning process where many voluntarily attributed causes of success and failure to non-discipline specific strategies such as time management, effort and

42

planning [41]. However, discipline-specific strategies were also identified by students as causes for success or failure, such as the adoption (or lack of) design strategies, pre-assessment of programming tasks and understanding of concepts. Further, some notable challenges mentioned by students that impact on the success of their performance are lack of study, the difficulty in tasks, the teaching approach as well as lack of effort, exam anxiety, cheating, and lack of time [13]. Whilst effort, attitude and other internal factors are recognised by participants, persistence – although not unique to programming – is a quality that is recommended if students are to succeed at programming [31].

Research ought to investigate whether students working with visual programming environments and online self-paced courses encounter similar emotions, challenges and difficulties as learners operating in introductory programming courses at university. While research has reported students identify a range of discipline and non-discipline specific strategies that are perceived to influence learning to program, the follow section considers the extent that thinking skills play a role in learning to code.

2.3 Thinking skills An early overview of the literature about learning to program and learning to think by Mayer et al. [24] identified that many studies, such as work by Papert [27] and Nickerson [26], discussed the link between the two, but that originally much of this conversation was founded on anecdotal evidence, self-reflection or thought. While particular disciplines are said to require the development of particular skills and some philosophers, such as Gardener [40] argue that some people have a tendency toward particular ‘intelligences’, what skills and thinking are required for successful performance in programming? Are there some capabilities that successful programmers demonstrate over less successful programmers? Mayer et al. [24] began investigating this area and found that through their work with non-computing majors, pre-training in comprehension skills, problem representation and procedural comprehension were factors likely to influence success. However, they also cautioned that required skills are likely to be particular to the programming language, which was Basic in their studies.

Although previous authors had began discussing the links between thinking and programming, it was in Wing’s 2006 article, that thinking, applicable to computing, was labelled as computational thinking [45]. Wing provides examples of CT represented as everyday activities as a way to convey the concepts, the relevance and application of this thinking to the everyday activities of everyday people. However, are some people naturally better at CT and the application of thinking skills to perform introductory programming, or is it that CT skills require specific development?

When participants talk about the nature of programming in interviews, they refer to having to think or learn differently in this discipline [31]. This type of thinking was described as being logical and sequential, similar to findings by Mayer et al. [24] and were described as there being ‘a logical step-by-step process which enables programmers to translate goals into code, until this process is mastered, students are faced with a challenge which some find very hard to meet’ (p. 156). Such findings have implications for how children are taught to program as in Piaget’s work, he theorised that young children struggle with logical thinking and abstract thought [28].

In studies of programming learners, those who trace code successfully are said to enhance their ability to write and explain code [22] and problem-solving and programming skills [2].

Students who are weak at tracing and/or explaining cannot write systematically and it is suggested that code writing ability can be improved through extensive practice until tracing and explaining skills are strong enough to support a systematic approach [22]. Further, understanding the conceptual framework of algorithms and the ability to construct and debug a program has been identified as playing a role in successful programming [2]. Many concerns arise about students frantically experimenting with their code [22] by ‘hacking a solution’ and these findings suggest that focusing learning activities in introductory programming to hone thinking skills and translating why this skill development is necessary to learners is important. Such findings have implications for instruction-based online introductory programming courses – to what extent do they provide opportunities for developing thinking skills as opposed to practice in writing code, and further, is skill development important to learning the fundamentals?

While the purpose of integrating CT into learning activities and curriculum is to develop individuals’ skills to systematically and efficiently process information and tasks, some express concerns over the pedagogical challenges and the role programming has to play [23] as well as call for more empirical research, theoretical and practical understanding of CT competencies [9], particularly in K-12. The inclusion of CT into schooling and tertiary computing curriculum provides opportunities to assess and monitor development and impact on programming performance.

2.4 Mindset Theories 2.4.1 Attribution Theory The literature so far identifies that students reported a range of factors that contribute to success and failure in learning to program, such as effort, ability, time management, planning and task difficulty [12, 13, 29, 41]. These can be referred to as causal attributions [42, 43] and can be sorted into factors pertaining to the causal locus (internal or external), which are factors associated with the self (e.g. ability, effort or time management) or external factors to the person (e.g. task difficulty, teaching method, or luck). The attributions can be further defined according to the causal stability (stable or unstable) that identifies whether a causal attribution can change with time or is fixed. For example, effort can be improved and is therefore unstable. On the other hand, task difficulty is perceived as fixed and something that is unchangeable. The table below (Table 1) is adapted from Weiner’s [43] work and presents the causal attributions: local of causal locus and causal stability as a quadrant.

Table 1: Weiner's [43] representation of the four main causal attributions of behaviour

Causal locus: interval VS external

Causal stability: stable VS unstable

Internal – Stable (e.g. ability)

External – Stable (e.g. task difficulty)

Internal – Unstable (e.g. effort)

External – Unstable (e.g. luck)

Perceptions by students learning to program perceived as internal and stable factors, such as ‘ability’, may be problematic because if a student feels they have a low ability, this is perceived as being something unchangeable and therefore they may perceive their

43

performance in programming can never improve. Whereas causal attributions to internal and unstable factors, such as effort, are perceived as being something one can change and improve on in the future. External factors on the other hand are perceived as being out of one’s control and instil feelings of helplessness, in the present moment and for future events. Causal attributions may influence an individual’s motivation toward future tasks. Weiner [43] developed his initial theory (table 1) to include influence on motivation, yet encountered many variables and contrasting findings in the literature; suggesting this area is in need of further exploration. Ideally, one would hope that students learning to program perceive they have control over their situation and responsibility over learning, and attribute causations toward internal and unstable factors. But is it that internal and stable factors, such as one’s ability, have greater precedence over learning to code than we would like and how do educator or learner perceptions about intelligence influence how one perceives learning to code?

2.4.2 Implicit Theories of Intelligence One way of understanding why some may have a tendency to attribute causes of failure or success to ‘ability’ or ‘intelligence’ is through the lens of implicit theories of intelligence [5, 6]. This theory puts individuals as having one of two worldviews when it comes to intelligence and that individuals hold a particular mindset, which is fixed or malleable. Someone who perceives intelligence (or ability) as a fixed trait and innate are said to hold an entity theory of intelligence. This view perceives intelligence as something that cannot change within us, which is similar to attributions that are stable and internal. Students who hold this viewpoint often worry about the level of intelligence they have and have a preference toward easy, low-effort tasks and outperforming others [5]. Whereas, someone who believes intelligence is expandable and developed through effort holds an incremental theory view. Someone with this view perceives intelligence, not to be a fixed trait, but something that they can develop through learning experiences. Students with this trait will select challenging tasks, which they are motivated to complete, that enable them to develop toward mastery [5].

The perceptions of those who are learning introductory programming may impact firstly, on the way that they approach learning tasks, but also in the way that they react to failure or challenges in learning to code. People who hold an entity theory view failure as beyond their control – a catastrophe – and ultimately feel helpless, as they believe they have no control over improving in the area [5]. Those holding an incremental theory have a resilient approach to failure, believe that setbacks are ways to improve and so they engage in mastery-oriented behaviour patterns to achieve master the skill or task. In Dweck’s [5, 6] substantial work in this area, the authors found that even the most skilled people can fall apart at the face of failure and often question their own intelligence when challenged. As a result such feelings can impact on student well-being and overall school experience [18]. Such theories are important for guiding introductory programming because, as a review of the literature has found, many students struggle with mastering programming skills, while some are determined to persist and excel.

Too often learners encountering introductory programming believe that an inherent aptitude is required to be a programmer [33] and it is not uncommon to hear whispers about a ‘programmer gene’ whereby someone requires a natural ability in order to be a successful programmer. It may not be uncommon for students to share this perception, with research reporting that

students reflect on their successful programming peers as ‘[t]hey think in code” or ‘[it’s] [s]omething internalized. They just knew how to figure all that stuff out’ [31]. Scott and Ghinea [33–35] have undertaken work in the area of self-theories and undergraduate programming students and discovered that, students’ (n=94) beliefs toward aptitude are distinct to that of beliefs about intelligence among the cohort [34]. As a result they suggest that when self-theories are applied in specific domains alternate self-traits, to intelligence, should be considered and that a mindset based on intelligence as a single trait may not be appropriate for computer programming [35]. In their survey, programming students who had a fixed mindset for programming aptitude had an incremental view of intelligence, suggesting that students may not associate programming aptitude with intelligence and that aptitude may have a greater influence over programming practice [35]. We have seen this as in studies that apply attribution theory perspectives where ability is commonly a trait students express as the reason they enrol in computer science [21] or as a factor contributing toward performance [14, 41]. Although based on a single context and two classes, a concerning finding was that over the course of a semester, while programming students’ perception of intelligence had not changed, nearly one third of respondents came to believe more strongly that programming aptitude was a fixed trait [35]. This is somewhat at odds with findings that suggest self-efficacy improves over time when learning to program [29].

It is known that computer science lack females studying in the discipline and that computing courses fail to retain female students who pursue IT careers. In an example of gender differences, and although computing engineers only made up some of the total sample (n=238 total), 72% of females held a fixed entity view of engineering aptitude compared to 46% of males. Of those females who reported dropping a class due to difficulties, 100% held a fixed entity view, compared with 61% who did not drop out [15]. This finding, although conducted in 2002, warrants further exploration into perceptions held by males and females and the impact on learning programming. Is it that female adults or children learning to program in school or through self-paced courses will share similar perceptions that influence persistence?

There is promise that perceptions can be changed or influenced. In a PhD study, Bergen (1991, cited in [6], p. 279), induced students to adopt one of the two implicit theories of intelligence by presenting a ‘scientific paper’ with an argument in favour of one or the other. Participants who read the entity article displayed more of a helpless reaction to failure. Such findings demonstrate that by manipulating perceptions of implicit theories may influence judgements and reactions and it is suggested that through pedagogies that reinforce incremental thinking students can change their perceptions about programming requiring a fixed trait [33]. Scott and Ghinea suggest that simply using grades may convince some that programming is based on aptitude, whereas the integration of detailed informative feedback that helps learners overcome weaknesses may instil an incremental perception.

2.4.3 Impact of educator perceptions Perceptions of intelligence are not only relevant to understanding learners, but the way that educators perceive intelligence can potentially impact on a student’s experience and the learning and teaching context. It is recommended that understanding the behaviours and contexts that form the links between adults’ and children’s gendered math attitudes is critical for understanding how to minimise negative influences and enhance positive

44

attitudes [10]. There are limited research in terms of the role of teachers’ theories of students’ intelligence and its impact on practice and student learning [37], and further studies that do exist focus primarily in the discipline of mathematics [3, 10, 30].

In a three-stage study of undergraduate math courses, teachers with an entity theory view were more likely to diagnose students as having low ability, comfort students on their low ability and engage in pedagogical practices that could reduce engagement with the subject, than people with incremental view. For example a line such as ‘It’s okay, not everybody can be good at math’ would be a comforting statement. Further, teachers who held an entity theory view of students’ performance based on low ability, reported that they did not expect to see further improvement in the student [30]. The type of feedback that educators provide can impact on students; students who received comforting feedback were less motivated and expected lower final grades. Further, a study of in-service teacher perceptions of their students, researchers found that the beliefs that teachers hold about students’ potential intellectual development are also likely to impact on the predominant goal structures within a classroom [37]. Mathematics and computing are often banded in the same area (e.g. ‘STEM’) and findings that teacher perceptions and feedback influence learners [3, 10, 30], suggests this is an important area to be explored in K-12 and tertiary computing.

2.5 Motivation for the study The studies presented in the literature review suggest that learning to program is a complex experience, which is unique to many, and that perceptions about causes for performance and theories of intelligence do play a role to some extent. This is a review of introductory programming learners at the tertiary level and it is expected that learners engaging in learn to code courses and software are also encountering a range of experiences.

While, rightly so, much of the literature focuses on the student experience and their perceptions, we have seen that in disciplines such as mathematics, that educators can influence the classroom experience of learners [3, 10, 30], warranting further investigation into how educators of computer science perceive learning to program. Those in the CS community, with experience in learning and/or teaching programming, may offer valuable insight into the challenges of learning to code and the perceived capabilities required to learn to program and how this translates to the global ‘learn to code movement’. The purpose of this paper was to pilot a survey to determine if the topic attracted a response from those in the CS community and to identify some key viewpoints to determine if the topic warrants further exploration.

3. RESEARCH METHODOLOGY 3.1 The survey instrument A survey was developed, using Google Forms, with three open-ended questions, which asked:

1. Can everybody learn to code? Consider someone with no previous experience in coding - can they master the fundamentals of programming? Why might some learners be more successful than others?

2. List three characteristics or qualities that might describe someone who succeeds at learning to code.

3. What do you think might be some key challenges or barriers for someone learning to code?

Open-ended questions, with probes, were used as a way to invite participants to share their experience and perceptions [16]. By inviting text responses, we were able to apply content analysis.

Additionally, a section invited participants to respond to questions about their gender, location, birth year, profession, programming confidence and programming education. These details allowed for comparisons between perceptions and background.

The survey was shared at the end of July via a number of different avenues to attract interest from the CS education community locally and internationally. The survey was shared across the researchers’ and research group’s social media, as well sent to two computer science education conference mailing lists. The survey was open for 1 week. Participants had to be 18 years of age or over to respond. The survey was approved by the university survey committee and was exempt from human research ethics approval, as it did not contain personally identifiable information.

3.2 Analysis The survey data were imported into NVivo 10 and automatic coding was used to code the demographic details to each of the responses. Conventional content analysis [16] was applied to the open-text responses based on researcher deductions and interpretation of the responses [8]. The researcher began by coding each participant’s response as either being in agreement, disagreement or conditional about whether anyone can learn the fundamentals of programming. Following, the researcher coded fragments of the text to nodes pertaining to attributes or traits, which were sorted into categories. The theory of multiple intelligences and attribution theory was used as a guide to sort the nodes and interpret the community responses. The following section presents the results of the participant demographic details and experience with programming.

3.3 Sample A total of 35 responses to the survey were received, however, two were removed because one participant was under the age of 18 and another was a duplicated response. The mean age was 34.2. 12 participants were over 50, 11 were between 30 and 49 years of age and 6 were 18-29 years old (3 data missing).

Table 2: Location and gender

Location Female Male Total Australia 9 11 20 Romania

3 3

Netherlands

2 2 Singapore 1 1 2 Guyana

1 1

Italy

1 1 Sweden

1 1

Turkey

1 1 United Kingdom

1 1

Total 10 22 32 Most participants were from Australia (n= 20), where the researchers are located (Table 2). Table 2 demonstrates there were more males but a reasonable number of females responded (n=10) according to the total number of respondents. Additionally, most were academics or IT Professionals (or were previously), but we also received responses from high school educators, computing researchers and students (Table 3).

45

Table 3: Participant professions and gender

Profession Female Male Total University Educator 2 9 11 IT Industry/ Professional 2 7 9 Researcher (IT/CS specialisation) 1 3 4 High School (secondary) Teacher 2 2 Student (non-IT related degree) 1 1 2 Manager 1 1 PhD student (IS and Education) 1 1 Researcher (other specialisation) 1 1 Total 10 22 32

A majority of the participants received formal qualifications and reported a level of experience around 5-7 on the scale (with 0 being no experience and 7 ‘expert’; Table 4). Table 4: Learning experience of programming and confidence

Learning Experience 0 1 2 3 4 5 6 7 Total Formal qualification

1

6 11 7 25

Self-taught

1

1

1

3 Units at university 1 1 2 Have not learnt 1 1 2 Total 1 2 3

1 6 12 7 32

The demographics and levels of experience were used to explore the various responses to determine how different people perceived about the ease of learning to code, traits and the challenges.

4. RESULTS The first question asked respondents if they thought anybody could learn the fundamentals of programming. We present the findings below, acknowledging that people have different perspectives and interpretations of programming ‘fundamentals’.

4.1 Can everybody learn to code? Respondents held one of three different perceptions. These were those who strongly agreed (yes), those who thought people could learn the basics to some extent and people who thought not everybody could learn to code. Such perceptions align with implicit theories of intelligence; that learning to program is based on fixed ability or is malleable, however, we also noticed a belief that was ‘dependent’ on the level of programming skill in question. Each participant response was coded to one of three categories based on their perception. Firstly, we explore participants’ demographics and experience in relation to this question and follow with the reasons for these perceptions.

Table 5: Perception of learning to code by gender

Gender No To an extent Yes Male 4 8 10 Female 1 5 4

Most believed that everyone could learn the fundamentals (n=14), with some people believing that people could learn to program to a certain extent (n=13). Some thought that not everyone has what it takes to be a programmer (n=5). There was a similar divide among gender within this sample (Table 5). University educators and IT professionals held similar views (Table 6) and high school teachers perceived that everyone could learn the basics of programming, to some extent.

Table 6: Perception of learning to code by profession

Profession No To an extent Yes Student (non-IT related degree) 0 1 1 IT Industry/ Professional 1 4 4 Manager 1 0 0 High School (secondary) Teacher 0 2 0 Researcher (other specialisation) 0 0 1 Researcher (IT/CS specialisation) 0 1 3 University Educator 2 5 4 PhD student (IS and Education) 0 0 1

Those holding formal qualifications or undertook a university unit had a stronger preference toward the idea that anyone can learn to program (Table 7). Some participants within this cohort nevertheless thought that not everyone could learn to program.

Table 7: Perception of learning to code by primary training

Training No To an extent Yes Formal qualification 3 11 11 Not learnt 1 1 0 Self-taught 1 1 1 University unit 0 0 2

Table 8: Factors identified in participants’ reasoning about whether anybody can learn to code

Factors No An extent

extent

Yes Unstable Motivation 0 1 4 Effort 1 1 0 Fear 0 1 0 Persistence 0 1 1 Problem-solving 1 2 0 Stable Interest/Passion 0 1 3 Logical/Systematic Thinking 4 2 3 Abstract Thinking 0 3 1 Attention to detail 1 1 1 Patience 0 0 1 Prior knowledge 0 0 1 Ability 1 1 0 Attitude 1 0 0 Mathematical Intelligence 0 1 0 Total 9 15 15

46

When examining the reasons as to why people thought anyone could learn to code or not, we were able to divide these into stable (fixed) and unstable (or malleable factors) [43]. The range of reasons presented in Table 8 demonstrate the complexity of factors that may contribute to reasons why people may or may not be able to achieve a basic level of understanding of programming.

4.1.1 Anyone can learn to code … definitely It was identified that factors such as interest, passion, motivation and a desire to learn played a large role in people’s reasoning for why people could learn to code if they wanted to. Participants who fell into this category believed that with these internally driven factors, people could achieve the fundamentals. ‘.. they can if they want to, have the interest, or have the drive to learn and create something. Some people like me have totally no interest in programming but forced to do a unit on it’ (Male, CS Student, Australia).

Interestingly motivation was perceived as something that could be someone’s downfall in learning to code, for example: ‘I think the key is motivation. Without it students easily fail to learn. With it, even if they find it very hard, they can be successful’ (Female, CS Researcher, Australia).

Three people also likened learning to code to learning other subject areas or skills, such as learning to cook for example: ‘Everyone should be able to learn coding, as much as everyone should be able to learn basic engineering or embroidery’ (Male, IT Professional, Romania). People believed that anyone could learn to code with the right type of thinking skills, with persistence and patience. However, while some people said that anyone could learn the fundamentals of programming due to the mentioned reasons, there were different levels of understanding and skill involved.

4.1.2 Anyone can learn to code… to an extent ‘Yes, everybody can learn a bit, but not everybody will succeed. Some might get stuck at "drawing lines" and others will go all the way to object-oriented programming and other complex concepts’ (Male, University Educator, Australia).

These participants made a distinction between the ‘fundamentals’ of programming and achieving mastery or the capability to abstract and apply what was learned to solve different problems or to create valuable programs that met particular needs.

I don't think that everyone can learn to code, but I do think that the great majority of people can learn to use the fundamentals of programming, the basic ideas of sequence, iteration and decision. That said, that is not the same as mastering the fundamentals, mastery to my mind includes being able to take the concepts and be able to apply them in completely different situations to new problems (Male, University Educator, Australia).

This perception was often reasoned with people being driven, interested or motivated to learn at a level beyond the fundamentals.

‘Everybody can learn how to do basic coding in at least one simple language. Me and my friends in university learnt programming starting from zero knowledge, this shows anyone can code. But not everyone can achieve mastery. Mastery in any subject requires keen interest that makes you want to study it deeper’. (Female, IT Industry, Singapore).

The above response is an example of how participants perceived mastery of programming required a different depth of study,

spurred by motivation. This was also sometimes explained in a way that people who achieved mastery and moved beyond the fundamentals were people with particular personal traits, such as being pedantic, patient, or an effective problem-solver.

‘Everyone can learn the basics. Not everyone can learn to be an expert programmer. Pedantic people are likely to be more successful, as you need to be precise... The major obstacle …. is fear. People who are afraid of making a mistake and breaking something...’ (Female, HS teacher, Australia).

In the above example, the teacher discusses how something such as fear can be a barrier to advanced programming. A lack of motivation or persistence was also attributed as a factor toward being a beginner and someone who moves toward mastery.

‘Like every subject area, newbies can learn to master a new area if they are sufficiently motivated. Mastering the fundamentals of programming is easy. However, mastering the development of complex solutions to problems might take longer. Motivation is a big factor’ (Male, University Educator, Guyana).

Interestingly, many commented ‘thinking’ as being a crucial factor that distinguishes between a learner being at the beginner level and moving toward mastery. ‘Everybody can learn basics, but cannot master, i think being coder and being good about it requires mathematical intelligence’. (Male, IT Industry, Turkey).

While some thought that beginners could achieve the fundamentals without these certain capabilities, others felt that they were crucial to learning the fundamentals of programming and that without them, people would not necessarily be able to pass the basic level.

4.1.3 Not everyone can learn to code Primary reasons for a perception that not all could learn to code were attributed to thinking skills and problem solving ability.

‘…not everyone can learn to code. It is a way of thinking, but more than that it has to do with whether you like to solve/find problems.’ (Female, University Educator, Australia)

While some describe this as a ‘way of thinking’, others specifically refer to a level of mathematical intelligence, systematic thinking and ability that allows one to be able to apply the concepts of programming to successfully code.

No… The key attribute required is to think methodically, logically and systematically, with great attention to detail. Not everyone can do this. And note that there is no shame in not being able to do this - it is just that different people have different attributes. (Male, University Educator, Australia)

It was perceived that individuals able to identify and decompose problems and the required functions to solve problems and write code was what differentiated those who passed and could not pass the basic levels of coding. Interestingly, effort, was also a factor described that people who pass have that kept them persisting at the task when others were struggling.

‘…to be able to translate a goal from the real world into code and to split different functionality into different code parts is something that one person can do without effort and others keep having troubles with it’. (Male, Previous IT Professional, Netherlands)

When explaining reasons as to whether everybody can learn to code, participants alluded to traits that made people successful or unable to grasp the fundamentals of programming. In the

47

following section we describe the specific traits that participants listed in response to the second survey question.

4.2 Characteristics for success Participants were asked to list three characteristics that they believe successful programmers hold. Participants identified a number of characteristics that were perceived as being required to be successful at mastering programming fundamentals. In table 9 we present the full list of traits that were identified in the survey responses to explore common traits. Although these can be reduced to a smaller number of categories, we appreciate the rich range of traits that the respondents perceive are required to be successful at programming.

Table 9: Perceived traits/skills for successful programming

Trait Freq Trait Freq Logical Thinking 8 Efficient 2 Methodical 7 Linguistic skills 2 Persistent 7 Open-minded 2 Abstract Thinking 6 Passionate 2 Creative 6 Grasps concepts 2 Interest 6 Gifted 1 Problem-solver 6 Intelligent 1 Patient 5 Positive 1 Focused/Goal oriented 5 Analytical 1 Mathematical skills 4 Decomposition 1 Pedantic 4 Effort/ hard working 1 Motivated 3 Experimental 1 Ability 2 Iterative approach 1 Design-oriented 2

These traits in Table 9 also presented in Figure 1 as a word cloud, where the researcher did not have any influence over the words that emerged. Using a text frequency query in NVivo 10, the top 100 most frequents words that were featured in the response to question two are presented. The larger the word, the more frequently that word (or synonyms) occurred in text. ‘Thinking’ and ‘logical’ emerged quite strongly, as did the mention of being abstract, persistent, design-oriented, and mathematical and having a drive or patience. These reflect many of the identified traits in Table 9. Interestingly, many of these traits can be identified as ‘internal and stable’ according to Attribution Theory.

Some participants mentioned ‘problem-solving’ as a required trait and the authors believe problem-solving skills can be developed through practice. For example: ‘programming really is about problem solving… problem solving is about organising one's thoughts, and their ability to use the right processes and techniques to do so’ (Male, University Educator, Australia). We have put problem solving in ‘changeable’ but recognise this is subject to interpretation. Unfortunately, the researchers could not check if participants perceived these abilities as being malleable, but this is an aspect that could be investigated in future research.

As at times it appeared ‘thinking skills’ were perceived as innate and fixed and at other times something that could be developed through practice, as was suggested: ‘.. programming requires a very ordered mind-set, which doesn't come very naturally to many people, so there is a hurdle to get over for those people’ (Male, University Educator, Australia).

Figure 1: Frequency of words in response for required traits to be a successful programmer

4.3 Perceived challenges of learning to code Although having a lack of the traits and qualities may influence whether one succeeds in learning to code, in this section the results are presented for the challenges that participants specifically identified. Table 10 provides a frequency summary of the various challenges that were perceived to influence one’s capability of learning the fundamentals of programming. These were identified as being challenges influenced by ‘internal’ factors and were separated into being relatively stable or unstable.

Table 10: Perceived challenges of learning to program (freq.)

Stable Changeable Motivation/interest 9 Lacking confidence 6 Lacking patience 6 Lacking literacy 2 Struggle with 'language' 6 Time 2 Difficulty in thinking 5 Debugging 1 Problem solving issues 3 Ability 1 Follow/provide instructions 2 Mathematical background 2

Ability 1 Age 1 Lacking analytical skills 1

Total 35 Total 13

In addition, to the items identified in Table 10, some participants mentioned challenges relating to external factors, such as the content that was provided to students (n=1), the ‘image’ of being a programmer (n=2), an awareness of the benefits of coding (n=4) and age to which people are exposed to programming. These were considered to be ‘changeable’ factors, as with time these challenges may be overcome. However some other external factors are somewhat stable were the teaching style and resources made available to the learner (n=5) and the interface of the programming software (n=1).

5. DISCUSSION This paper presents an analysis of survey responses addressing questions related to anybody’s capability of learning how to code,

48

and personal characteristics and associated challenges. We use mindset theories as a lens to explore the survey responses. Our findings show that of the 34 responses by IT professionals, university educators and high-school teachers, 12% thought that not everybody can learn how to code, 38% thought that everybody can learn how to code to a certain extent, and 50% thought that everybody can learn how to code. The majority of respondents that held formal education thought that everybody could learn how to code, either completely or to a certain extent. The participants also identified a wide range of dynamic and complex challenges, with the vast majority of challenges (72% of 48 challenges) being stable, and thus un-changeable. In alignment with other literature, many of the traits, justifications and challenges identified by the respondents relate to factors identified by students in previous studies [19-20], [22], [25], [31]. Regardless of whether people agreed anyone can learn to code or not, most in this sample generally believed that mastering programming skills and developmental processes requires thinking skills, motivation, persistence and a level of problem solving. Building on previous work [33-34] that suggested that there seemed to be more than factors of intelligence and that programming specific aptitudes may play a role, these findings suggest that there is also more to learning to program than only ability or intelligence – many individuals discussed various thinking skills, abstraction, mathematical ability, and an innate sense of passion and motivation as playing a role in learning to program. The mention of motivation featured prominently suggesting that exploring ways to increase learner motivation in K-12 and online may be important for curriculum developers and educators to consider.

Persistence has been found to play a role in learning to program [5] and similarly teachers also mentioned this as having an influence on whether one can achieve fundamentals or progress to a level of mastery. Whether it was described as ‘drive’, or ‘focus’ there seemed to be some common perceptions that this may play a role in overcoming the challenges of learning to program. This idea rests closely with having an incremental theory view [5, 6] and perhaps it is that those who are able to perceive challenges as ‘learning’ points and focus on mastery-oriented programming strategies will be able to overcome early barriers. Perceptions of intelligence can be changed [33], [36] and developing learning tasks that encourage incremental thinking and strategies in learning to program to overcome the fear of learning to code [31] appears to be an important avenue for CS education research.

Mayer [24] suggested that thinking skills were useful for learning programming and many of the factors expressed by participants in this sample related to various thinking skills, whether it be problem-solving, systematic thinking, abstract thinking, logical or mathematical. While some expressed that they perceived these thinking skills are fixed traits, others alluded that these could be developed with experience and persistence. Either way, both has implications for young learners as children are said to struggle with logical thinking and understanding abstract ideas until adolescence [28]. Computational thinking [44] is about teaching problem solving skills based upon logical thinking and concepts fundamental to programming such as iteration, sequencing, abstraction and decomposition and developing these skills play a large part in the Australian curriculum [1]. Is there something magical about learning to code – that certain individuals naturally are better at this type of thinking or can CT be taught and what impact does the development of CT have on learners when they encounter visual or general-programming environments? Although Mayer [24] believed that certain thinking skills were

particular to the programming language, is this still the case or can CT be developed and applied to any programming language?

This survey is based on a small sample and so generalisations cannot be made. A majority of the responses were from academics and IT professionals within Australia but future work will expand this reach. The purpose was to invite the CS community to respond to determine if there would be a range of reactions and a variation between perceptions. We invited participants to share their experiences and opinions about learning to code and perceived capabilities required, however, these are based on respondent opinions and cannot be said to be necessarily true. Nonetheless, respondents who have (mostly) had some form of experience in learning and teaching of programming can offer a perspective and contribute to initial understandings of this area. Previous research has found that educator perceptions and feedback influence learner experiences and self-perceptions in the discipline of mathematics [3], [10], [30] and it was evident that participants in the survey held different views that could be considered entity or incremental theory views – that programming is tied to an innate ability or something that can be developed with effort and skill development. This suggests that the influence of educator, peer and parent perceptions on learning to code could be an interesting area to explore further as well as the types of feedback people provide to learners (through online instruction or face to face) and the impact it has on learner experiences and persistence.

Content analysis requires that the researcher makes deductions and judgments [8] about participant perceptions and the anonymous nature of the survey meant that cross-checking interpretations with participants for accuracy was not possible. This offers opportunities for more in-depth discussions with educators, students and industry personnel to learn about their perceptions and experience, with an opportunity to follow-up and check researcher interpretations for accuracy. Nonetheless, this study forms the basis for more exploration in this area, in terms of educator perceptions and their impact on student self-efficacy.

6. CONCLUSION As new computing curricula are introduced over the world and are targeted at increasingly younger students, the question of CS community perception of the traits and characteristics required in order to learn how to code becomes crucial. This refers not only to the learner’s perception, but also to the educators, as educators, through their language, encouragement, and assessment have a drastic influence over the learner’s perception of various tasks. However, this survey is based on the responses of a small sample and therefore generalisations cannot be made. What is evident though is that there is a range of reactions and a large variation within identifying challenges in learning how to program. This warrants an in-depth exploration in this area, to include in-depth discussions with educators, IT professionals, and students to discuss their experiences and thoughts.

7. REFERENCES [1] ACARA 2013. Draft Australian Curriculum: Technologies.

ACARA, Canberra, Australia. [2] Affandy et al. 2011. A study of tracing and writing

performance of novice students in introductory programming. Communications in Computer and Information Science, 557–570.

49

[3] Beilock, S. et al. 2010. Female teachers’ math anxiety affects girls’ math achievement. Proceedings of the National Academy of Sciences. 107, 5, 1860–1863.

[4] Department for Education 2013. The National Curriculum in England: Framework Document. Crown.

[5] Dweck, C. et al. 1995. Implicit Theories and Their Role in Judgments and Reactions: A Word From Two Perspectives. Psychological Inquiry. 6, 4, 267–285.

[6] Dweck, C.S. 2000. Self-theories: Their role in motivation, personality, and development. Psychology Press, NY.

[7] Falkner, F., Vivian, R., & Falkner, N. 2014. The Australian Digital Technologies Curriculum: Challenge and Opportunity. In ACEC, Auckland, New Zealand.

[8] Forman, J. and Damschroder, L. 2007. Qualitative Content Analysis. Advances in Bioethics. Emerald Group. 39–62.

[9] Grover, S. and Pea, R. 2013. Computational Thinking in K-12: A Review of the State of the Field. Educational Researcher. 42, 1, 38–43.

[10] Gunderson, E.A. et al. 2011. The Role of Parents and Teachers in the Development of Gender-Related Math Attitudes. Sex Roles. 66, 3-4, 153–166.

[11] Haigler, V.F. et al. 1995. Parental Attachment and gender-role identity. Sex Roles. 33, 3-4, 203–220.

[12] Hanks, B. et al. 2009. Cs1 students speak: advice for students by students. SIGCSE’09, Chattanooga, 19–23.

[13] Hawi, N. 2010. Causal attributions of success and failure made by undergraduate students in an introductory-level computer programming course. Computers & Education. 54, 4, 1127–1136.

[14] Henry, J.W. et al. 1993. Attributional style as a predictor of success in a first computer science course. Computers in Human Behavior. 9, 4, 341–352.

[15] Heyman, G.D. et al. 2002. Gender and achievement-related beliefs among engineering students. Journal of Women and Minorities in Science and Engineering. 8, 1, 41–52.

[16] Hsieh, H.-F. and Shannon, S.E. 2005. Three approaches to qualitative content analysis. Qualitative health research. 15, 9, 1277–88.

[17] Informatics Education: Europe Cannot Afford to Miss the Boat: 2013. http://europe.acm.org/iereport/ie.html.

[18] King, R. et al. 2012. How you think about your intelligence determines how you feel in school: The role of theories of intelligence on academic emotions. Learning and Individual Differences. 22, 6, 814–819.

[19] Kinnunen, P. 2009. Challenges of teaching and studying programming at a university of technology - viewpoints of students, teachers and the university. Helsinki University of Technology.

[20] Kinnunen, P. and Malmi, L. 2006. Why students drop out CS1 course? ICER ’06, New York, USA.

[21] Lewis, C. et al. 2011. Deciding to Major in Computer Science: A Grounded Theory of Students’ Self-Assessment of Ability. ICER ’11, 3–10.

[22] Lister, R. et al. 2004. A multi-national study of reading and tracing skillls in novice programmers,”. SIGCSE Bulletin. 36, 4, 119–150.

[23] Lu, J. and Fletcher, G. 2009. Thinking about computational thinking. ACM SIGCSE Bulletin. 41, 1, 260.

[24] Mayer, R.E. et al. 1986. Learning to program and learning to think: what’s the connection? Communications of the ACM. 29, 7, 605–610.

[25] McCracken, M. et al. 2001. A multi-national, multi-institutional study of assessment of programming skills of firstyear cs students. SIGCSE Bulletin. 33, 4, 125–140.

[26] Nickerson, R.S. 1982. Computer programming as a vehicle for teaching thinking skills. Thinking: The Journal of Philosophy for Children. 4, 3/4, 42–48.

[27] Papert, S. 1972. Teaching Children Thinking. Innovations in Education & Training Teaching Children Thinking Teaching Children Thinking. 9, 5, 245–255.

[28] Piaget, J., & Cook, M.1952. The origin of intelligence in children. International University Press, NY.

[29] Ramalingam, V. et al. 2004. Self-efficacy and mental models in learning to program. ITICSE ’04, Leeds, United Kingdom, 171–175.

[30] Rattan, A. et al. 2012. “It’s ok — Not everyone can be good at math”: Instructors with an entity theory comfort (and demotivate) students. Journal of Experimental Social Psychology. 48, 3, 731–737.

[31] Rogerson, C. and Scott, E. 2010. The Fear Factor: How It Affects Students Learning to Program in a Tertiary Environment. Journal of Information Technology Education. 9 , 147–171.

[32] Salajan, F. et al. 2010. Student and faculty inter-generational digital divide: Fact or fiction? Computers & Education. 55, 3, 1393–1403.

[33] Scott, M. and Ghinea, G. 2013. Educating programmers: a reflection on barriers to deliberate practice. HEA Conference on Learning and Teaching in STEM Disciplines, Birmingham, UK.

[34] Scott, M. and Ghinea, G. 2013. Implicit theories of programming aptitude as a barrier to learning to code: are they distinct from intelligence? ITiCSE, Canterbury, 347– 347.

[35] Scott, M.J. and Ghinea, G. 2014. On the Domain-Specificity of Mindsets: The Relationship Between Aptitude Beliefs and Programming Practice. IEEE Transactions on Education. 57, 3, 169–174.

[36] Seehorn, D. et al. 2011. CSTA K-12 Computer Science Standards. CSTA, UK.

[37] Shim, S.S. et al. 2012. Goal Structures: The Role of Teachers’ Achievement Goals and Theories of Intelligence. The Journal of Experimental Education. 81, 1, 84–104.

[38] Royal Society. 2012. Shut down or restart? The way forward for computing in UK schools. https://royalsociety.org/education/policy/computing-in-schools/report/.

[39] The New Zealand Curriculum. 2014. http://nzcurriculum.tki.org.nz/.

[40] Tropman, J. and Gardner, H. 1985. Frames of the Mind: The Theory of Multiple Intelligences. Journal of Policy Analysis and Management. 4, 3, 476.

[41] Vivian, R., Falkner, K., & Falkner, N. (2013). Computer science students’ causal attributions for successful and unsuccessful outcomes in programming assignments. In Koli Calling, Koli, Finland.

[42] Weiner, B. 1985. Attribution Theory. Human Motivation. B. Weiner, ed. Springer New York. 275–326.

[43] Weiner, B. 2010. The Development of an Attribution-Based Theory of Motivation: A History of Ideas. Educational Psychologist. 45, 1, 28–36.

[44] Wilson, C. and Guzdial, M. 2010. How to make progress in computing education. Communications of the ACM. 53, 5, 35–37.

[45] Wing, J.M. 2006. Computational thinking. Communications of the ACM. 49, 3, 33.

[1]

50