Communications of the ACM
Home/Magazine Archive/August 2021 (Vol. 64, No. 8)/What Does Saying That 'Programming Is Hard' Really.../Full Text
Education
What Does Saying That 'Programming Is Hard' Really Say, and About Whom?
Credit: RedPixel.pl
The commonly held belief that programming is inherently hard lacks sufficient evidence. Stating this belief can send influential messages that can have serious unintended consequences including inequitable practices.4 Further, this position is most often based on incomplete knowledge of the world's learners. More studies need to include a greater diversity of all kinds including but not limited to ability, ethnicity, geographic region, gender identity, native language, race, and socioeconomic background.
Language is a powerful tool. Stating that programming is hard should raise several questions but rarely does. Why does it seem routinely acceptable—arguably fashionable—to make such a general and definitive statement? Why are these statements often not accompanied by supporting evidence? What is the empirical evidence that programming, broadly speaking, is inherently hard, or harder than possible analogs such as calculus in mathematics? Even if that evidence exists, what does it mean in practice? In what contexts does it hold? To whom does it, and does it not, apply?
Computer science has a reputation3 and this conversation is part of that. Is programming inherently hard? Although worthy of discussion, this Viewpoint is not concerned with explicitly answering this question. It is concerned with statements such as "programming is hard" and particularly the direct and indirect messages such statements can convey. It explores who says this, why and how it is said, and what the ramifications are. Consider the statement "computer programming could be made easier."7 Although this implies that programming is possibly more difficult than it needs to be, it clearly sends a different message than "programming is hard." This exemplifies how two fairly similar statements can convey very different messages and likely have different effects.
Who Says Programming Is Hard?
The belief that programming is hard seems to be widespread among teachers and researchers.4 Academic papers frequently state that programming is hard anecdotally, as if just stating the obvious. Yet it is rarely discussed outside of motivating and justifying research. Although this approach is rarely challenged, when it is, the stakes are high. One critique points out this stance can lead to uncritical teaching practices, poor student outcomes, and may impact negatively on diversity and equity.4 That work suggests the expectations of educators are unrealistic—not that programming is too hard.
The message of difficulty is also carried through more everyday mechanisms. It can be unknowingly or inadvertently perpetuated through our teaching habits, textbook language, terminology, the defensive climates in our classrooms,3 tools, and programming languages themselves. A case in point is programming error messages that, across almost all languages, are notorious for causing confusion, frustration, and intimidation, and have been described as mysterious and inscrutable.1
The belief that programming is hard is not confined to academia. The concept of the "10x developer"—the elusive developer that is 10 times more productive than others—serves to communicate that programming is hard and few can be good at it. Even professionals have referred to programming as a black art,8 a view that persists to present day for some. Hollywood typecasts embodying the hacker stereotype, staring at screens while 1s and 0s quickly stream by, present programming as a mystical, supernatural ability. It is possible that such portrayals have negative side effects in addition to their entertainment value.
Known Difficulties and Overlooked Successes
It is more accurate to say that certain aspects of programming are difficult or more challenging than others. This considerably dilutes the notion that programming is innately hard, as some aspects of many endeavors are more difficult than others. More pointed statements are also less likely to inflict collateral damage on general audiences and are less prone to misuse. Aspects of programming that are accepted to be challenging include knowledge transfer issues—including negative transfer—and developing a notional machine, among others.3 Programming has several candidate threshold concepts5 but so do aspects of many disciplines.
Programming is also the subject of many misconceptions.5 This might be because it is hard. On the other hand, saying it is hard might be a convenient way of explaining these misconceptions. Other (and generally older) disciplines also have challenges with misconceptions. Many physics students struggle with the fundamentals of mechanics such as force vs. acceleration, speed vs. velocity, weight vs. mass, and the concept of inertia. Such comparisons are not that indirect. These well-established concepts underpin a more formulaic approach in much practice, similar to how the conceptual underpinnings of programming are expressed ultimately in code. Engineering also can suffer from a hard image. The notion that mathematics is hard already exists in many school systems and is often echoed by parents and other stakeholders, leading to negative implications including working against broadening participation. However, computing casts a very wide net in modern society; it is intertwined with much of daily life and influences chances of success in many ways. Similar could be said for mathematics but computing may seem more visible and tangible to many. It is also a very attractive and in demand career path for tomorrow's graduates.
The belief that programming is hard seems to be widespread among teachers and researchers.
There are examples that support programming not being hard. Success has been found in pair programming, peer instruction, worked examples, games, and contextualized approaches such as media computation.3 These are often backed by empirical evidence5 but are frequently overlooked when convenient. Block-based programming has become extremely successful, particularly with younger children. New modalities also demonstrate that computing is relatively young and rapidly changing. This pace of change itself may be one of the leading factors contributing to the perceived difficulty of programming.
Hard For Whom?
Given how many people are affected by computing technologies, another problem with statements that programming is hard is that most research and media reports are based on very narrow samples of Earth's population—largely from American, Commonwealth, and European contexts. There are entire countries, nearly entire continents, and countless groups whose experiences have not been rigorously studied and contrasted with others. Even in more frequently researched locales, our current views are not representative of many. This is rarely acknowledged or acted upon. Many sub-populations in terms of all manners of diversity and identity including ability, culture and ethnicity, geography, gender, native language, race, socioeconomic background, and many others are still underrepresented, everywhere.
Additionally, most data and experience currently come from computing students, yet computing is quickly becoming a mainstream discipline embedded in school curricula and for an increasing range of academic disciplines in higher education.5 Declaring programming to be hard for relatively well-resourced Western computing students paints a bleak view for others. Even if programming was found to be uniquely hard for these students, this finding might only hold for the very limited, biased samples that have contributed to our current knowledge. Carelessly attempting to generalize such a finding would serve to shut the door on those who have not yet had their experiences counted. In effect, such practice is already happening when the message that programming is hard is perpetuated with little or no context.
Ramifications
There are several examples where explanations for observations in computing education have unintended negative consequences. For instance, to explain struggling students sitting next to high achievers, the "Geek Gene" hypothesis proved convenient. This states that programming is an innate ability. In other words, one generally cannot learn to be a great programmer; one is or is not, and most are not. There is evidence that computer scientists believe that innate ability is more important in computing than in other disciplines and this is known to be a barrier to broadening participation.3 Although the Geek Gene hypothesis has met resistance3,8 damage has already been done and might continue.
One need not look far for other contemporary examples of unintended messages having undesired effects. It was recently shown that competitive enrollment policies for university-level computing majors have a negative impact on student sense of belonging, self-efficacy, and perception of department.6 Of course, these were not intended outcomes. Competitive enrollments were largely a response to growing student numbers and demand that could not be met. Nonetheless, this mechanism sent an unintended signal to students, resulting in undesired negative consequences. It is likely the perpetuation of the message that programming is hard has similar effects.
A recent series of NSF workshops revealed one of the most-heard comments made by non-computing educators when discussing computing curricula was "stop making computing/programming look scary."2 Is that really the image that we intend to portray or is it just a byproduct of computing culture? If educators think that programming is scary, how can we expect students to think any differently? These messages may already have resulted in countless students abandoning computing, or not considering it in the first place. We will never know. It is likely that untold damage has already occurred and continues to accumulate.
The Future
The relatively short history of programming is filled with constant change, and what is taught can change often.3 Character-based high-level programming has, overall, led the battle for adoption particularly at university and in industry, but there are many examples of programming that do not fit this mold. From Logo and Hypertalk, to prototype spoken-language programming languages, to block-based programming, and domain- and task-specific programming, what exactly constitutes programming can depend on who is asked and when they are asked. Today, low-code and no-code are emerging programming modalities, another sign that what constitutes programming is in constant flux. The number of programmers in non-computing contexts is also rapidly increasing.1 Surely even if programming was deemed hard yesterday, that does not mean it will be tomorrow.
How can we change programming's notorious reputation? The answer is likely multifaceted and includes being aware of the true effects of the beliefs we hold and the messages we send. In addition, these should be based on evidence, informed by an appropriate diversity of people. We should have realistic expectations of students and focus on what we know is successful both in practice and in our messaging, including examining the intent of statements on the matter.
Conclusion
The notion that "programming is hard" is frequently reinforced in our classrooms, workplaces, academic literature, and the media. However, this position frequently reflects ideological views and lacks sufficient evidence. Statements that programming is hard can have obvious direct consequences. However, they can also convey more indirect messages—in effect sending signals that can have unintended consequences on students, educators, the community, and the discipline of computing itself. These are rarely considered.
Is programming hard or not? Current evidence is not compelling nor diverse enough to answer this question in general. More defensible (and likely honest) answers are: "it depends," and "both." Why then, is it so common to say that it is hard? Is it often said anecdotally because there is not that much evidence to support it? Because the evidence that does exist is difficult to understand? Could it be that it is just too convenient for motivating and justifying work? Is it that many want programming to seem hard, consciously, or unconsciously? Do tech companies and hiring managers depend on the image of programming being tough and elite? Is it too convenient for explaining phenomena whose true explanations remain elusive? Is it just an easy excuse for failure? Perpetuating this belief only serves to reinforce a shaky base of evidence that undermines any more rigorous evidence-based research. If we are going to make claims on the difficulty of programming, the community has a duty to provide robust empirical evidence from diverse contexts and state the findings responsibly.
Many current events and sociopolitical realities have caused us to question our educational practices recently. Considering the present global context, blanket messages that "programming is hard" seem outdated, unproductive, and likely unhelpful at best. At worst they could be truly harmful. We need to stop blaming programming for being hard and focus on making programming more accessible and enjoyable, for everyone.
References
1. Becker, B.A. et al. Compiler error messages considered unhelpful: The landscape of text-based programming error message research. In Proceedings of the Working Group Reports on Innovation and Technology in Computer Science Education (Aberdeen, Scotland UK) (ITiCSE-WGR '19). ACM, New York, NY, 2019, 177–210; https://bit.ly/2T97WUT
2. Birnbaum, L., Hambrusch, S. and Lewis, C. Report on the CUE.NEXT Workshops. Technical Report (2020); https://bit.ly/3x8ev8Q
3. Guzdial, M. Learner-centered design of computing education: Research on computing for everyone. Synthesis Lectures on Human-Centered Informatics 8, 6 (2015), 1–165.
4. Luxton-Reilly, A. Learning to program is easy. In Proceedings of the 2016 ACM Conference on Innovation and Technology in Computer Science Education (Arequipa, Peru) (ITiCSE '16). ACM, New York, NY, 2016, 284–289; https://bit.ly/3ivrKfM
5. Luxton-Reilly, A. et al. Introductory programming: A systematic literature review. In Proceedings Companion of the 23rd Annual ACM Conference on Innovation and Technology in Computer Science Education (Larnaca, Cyprus) (ITiCSE 2018 Companion). ACM, New York, NY, 2018, 55–106; https://bit.ly/3v1D9qh
6. Nguyen, A. and Lewis, C.M. Competitive enrollment policies in computing departments negatively predict first-year students' sense of belonging, self-efficacy, and perception of department. In Proceedings of the 51st ACM Technical Symposium on Computer Science Education (Portland, OR, USA) (SIGCSE '20). ACM, New York, NY, 2020, 685–691; https://bit.ly/2TTr3Tl
7. Sime, M.E., Arblaster, A.T., and Green, T.R.G. Structuring the programmer's task. Journal of Occupational Psychology 50, 3 (1977), 205–216; https://bit.ly/3w4NNxL
8. Tedre, M. From a black art to a school subject: Computing education's search for status. In Proceedings of the 2020 ACM Conference on Innovation and Technology in Computer Science Education (Trondheim, Norway) (ITiCSE '20). ACM, New York, NY, 2020, 3–4; https://bit.ly/3v436po
The Digital Library is published by the Association for Computing Machinery. Copyright © 2021 ACM, Inc.
Comments
Alexander Repenning
Dear Brett,
Thank you for the stimulating viewpoint. A question. You are concluding that We need to stop blaming programming for being hard and focus on making programming more accessible and enjoyable, for everyone Isnt that what the field of computer science education (e.g., Logo) has been doing for at least 50 years?
Why does programming need to be easy? Observe kids playing sometimes mind bogglingly hard video games. Not because they are easy, but because they are hard. Papert called this hard fun. One should look at different extremes of the cognitive easy/hard spectrum. There is the 1 hour, Hour of Code-type programming, experience focusing on broadening participation and fun. However, there are 9,999 more hours to make it to the 10,000 hour (popular science) mark of level of true expertise. Reaching the 1 hour mark may not be hard but it is not clear what that suggests regarding the 10,000 hour one.
One problem with the viewpoint is the focus on cognitive challenges. When I started our research interviewing a middle school girl about her perspective of programming she said that Programming is hard and boring. Notice, in addition to the cognitive challenge of programming to be hard there is the equally important affective challenge of programming to be boring. This is not a trade off. Students, teachers, parents, and citizens of the 21th century in general dont fully appreciate the return on investment of programming. Why would I want to write a program to compute boring prime numbers? More generally, what is the compelling instrumental motivation behind the skill of programming? Some people find an answer, but many dont. And that is OK.
While overall your viewpoint suggests a somewhat grim picture regarding the negative perception of programming in one aspect it may be overly optimistic when you suggest that Block-based programming has become extremely successful, particularly with younger children. Did block-based programming really make programming easy? Using programming is hard and boring as a two dimensional research space, over the last 25 years, we tried to transition from hard and boring to accessible and exciting by introducing block-based programming (e.g., AgentSheets) and crafting game-design based curricula (e.g., Scalable Game Design). While we did findempirically that programming has become more accessible and game design is broadly engaging, the impact of blocks-based programming is generally massively overestimated. Blocks-based programming has removed one important obstacle (syntax), which made programming hard. But just as spell checking is not turning automagically everybody into an accomplished author, syntax is probably the smallest challenge we were able to remove so far from programming. It is a little bit like wanting to climb Mount Everest. When you fly from your home town to Kathmandu you may have come a long way (just like syntax), but the true challenge of climbing the mountain is still ahead of you. Making programming more accessible and enjoyable is about beginning the actual climb. It is about creating a new generation of tools and didactic strategies to support semantics and even the pragmatics of programming.
All the best, Alex
Alexander Repenning
University of Colorado at Boulder and PH FHNW Switzerland
Dan Sutton
Programming isn't hard: it's either obvious or impossible, depending on who you are. My observations over the last forty years spent programming lead me to believe that the ability to program is inbuilt: you can't teach someone to have it - they either do or don't: it's a specific type of madness.
You can't teach a person to program: you can merely show them the syntax and how it works - past that point, they can either do it or not. Writing a program to generate prime numbers is either fascinating, leading to a sense of deep satisfaction, or it isn't. It's not possible to make that fascinating; it's not possible to make someone derive enjoyment from sitting in front of a screen, obsessing over the same, esoteric concept for hours at a time; it's not possible to make someone's brain operate with the peculiarly lateral-yet-rational type of proto-schizophrenia a programmer's brain employs: the art of lateral thinking fused with the science of rational thinking: programming is the only art form which has definite right and wrong answers: cast your mind out irrationally in order to latch onto rational ideas.
A programmer doesn't sit there, trying to get a machine to perform a task: he sits there, explaining to a friend what's on his mind - and that friend is partly the computer, but mostly himself (hence the schizophrenia), the computer being merely a mandala which allows him to concentrate his thoughts properly.
In short, past the point of writing ten-line test programs as class exercises, a person can either program or they can't: their brains either work that way or they don't - long before they ever encounter a computer or a programming language.
Brett Becker
Hi Alex,
Thanks for your comment. I do feel that the computing education community has been working for a long time towards making programming more accessible and enjoyable. Much work remains however, and the community should occasionally examine and question progress in order to continue as best as possible. Should programming be easy? Does it need to be easy? Should it be hard? Does it need to be hard? All of these questions can be used to investigate our progress and intentions. They may never have agreed answers, but they still have utility in helping us gauge where things stand and where we are going.
I do think that block-based programming is successful at engaging many younger students and lowering some entry barriers. Perhaps a good answer for the question: Is programming hard or not? is: It is both. There are many dedicated professionals who put a lot of effort, knowledge, and experience into constructing safe, reliable, efficient, secure, and often very complex code. That is not easy, and it takes a lot of learning to get there. There are many teachers, mentors and colleagues who have put in a lot of work on the education side. All of these people were once students of some description even if self-taught. This all takes community and it is great that there are so many passionate people in computing.
I agree that making programming more accessible and enjoyable is about beginning the climb. I want beginners to be able to start their journeys without being discouraged unnecessarily, and I certainly don't want them to be discouraged before they even begin. Of course, every journey is different, and everyone will start the climb a little differently.
Thanks again,
Brett Becker
University College Dublin
Displaying all 3 comments