What Is Programming?

Two years ago, when visiting research colleagues in Uppsala, Sweden, we were asked a deceptively simple question: “What does it mean to program?” For context, one of us had just completed academic education and training in computer science and was already deeply involved in actually teaching introductory programming (CS1). Arguably, he was (and still is) capable of programming. The other completed his Ph.D. degree in 2003 and has been teaching programming (in various forms) ever since. Yet, the question took us by surprise; after all: “What is programming?” To the reader, it may appear a ridiculous question to ask for two reasons. You may find yourself having a very clear and succinct definition and conceptualization of (the idea of) programming. Or, you may question what value it brings to discuss such a trivial question.

However, we believe the answers to this question may shed light on the future of programming in the age of generative artificial intelligence (AI). We approach an answer to the question by an exploration of the history of computing as well as opinions among contemporary introductory programming educators.

In Theory, Programming Is …

Alan Blackwell’s work takes us through the historical definitions of programming.¹ Initially, it is presented as the process of drawing up the “schedule” for the sequence of individual operations required to carry out a calculation. Later definitions expand this to the process of translating from a language convenient for humans to a language convenient for the computer. If we, as a community, adopt these narrow definitions, the entirety of programming may well be made redundant by the ceaselessly growing capabilities of generative AI. However, during the 1970s, Donald Knuth, and similarly Edsger Dijkstra, argued programming was something more.^2,4 They argued that programming was the “art” of composing programs, which requires awareness of aesthetics, use of ingenuity, and inherent creativity. From this perspective, programming is more about composing pieces of code to solve a problem rather than writing individual lines of instructions. In 1985, Peter Naur further nuanced the view of programming for problem solving.⁶ Specifically, he argued that a program’s “life” depends on its developers fostering an understanding of how it [the program they develop or maintain] supports the matters at hand; that is, an understanding of the “problem domain.” Thus, programming is not simply what is manifested as program code; it is also the knowledge of how the program interacts and develops alongside the domain of the problem. Recently, Amy Ko et al. have taken this further and argued for the need to also consider the societal impact of our programs, including limitations, biases, and ethical considerations embedded within the programs.⁵

Thus, one can reduce programming to the act of writing instructions, but when taking the art and context into consideration, it becomes more about the process of composing and constructing something that, in a sense, exists within a domain. Thus, current definitions both encapsulate the act of writing programs and the surrounding ingenuity of composing pieces to solve problems.

Research in computing education tells the same story: the obstacles of learning to program is about so much more than (just) writing individual instructions; the challenges are broader about reading code, composing code, planning structure, solving problems, and validating solutions.⁹

In Practice, Programming Is …

Let us change the perspective from theory to practice and consider what educators perceive programming to be. You may ask why we focus on educators. For a formal (practical) definition of ‘programming,’ surely one ought to turn to practitioners: developers, engineers, and programmers? Educators, however, are often the ones who, at least in the context of Denmark, facilitate a student’s first encounter with programming (in our CS1 course, half of the students immatriculate without prior programming experience). Consequently, educator perspectives will determine how novices will face the learning of programming (in the era of generative AI). Thus, we find it important to explore their viewpoints as they may make-or-break the next generations’ understanding of the topic.

Therefore, we recently conducted a survey wherein we questioned what introductory programming educators believed programming, and being a good programmer, was through two open-ended questions. We specifically focused on Danish higher education as course-, program-, and teacher-information (who is teaching what) is public. Further, computing classes are not mandatory in primary nor all of secondary education, meaning that higher education is the educational frontier where students first encounter programming. Combined with the limited size of the country, this allowed us to comprehensively investigate 1,169 programs^a and thereby aggregate responses from a broad and representative population of educators across disciplines.

By investigating the curricula of all mandatory courses on these programs, we identified educational programs that introduce programming. This constitutes a “snapshot” of how mandatory programming has emerged in higher education for an entire country of Denmark. The result includes 130 mandatory courses introducing programming shared across 175 programs. By distributing our survey to the 146 educators teaching these courses, we obtained 81 responses (55%): from teachers (26%), course assistants (67%), and others, such as heads of study program (7%). The respondents are involved in 61% of the identified program (106 of 175) spanning the majority of disciplinary areas (as defined by the governmental educational register). Thus, we, unsurprisingly, given the broad disciplinary coverage, see a more balanced gender diversity (in this case, around 2:1) than the 4:1 ratio associated with ICT in Europe.³ At last, we find that 40% of the respondents are originally from other countries than Denmark. Therefore, we conclude that the responses collected are indeed representative of a very diverse group of educators.

By categorizing the responses according to the use of keywords,^b we find that 36% define programming in terms of its ability to solve problems. 35% focus on writing lines of code/instructions in their definition of programming. While some answers did focus on other qualities of programming, the aforementioned appeared to be the dominant (narrow) attributions of programming. Other dimensions involved: the importance of the computer (28%), algorithms (10%), using a programming language (9%), execution of code (6%), or automation (5%).^c

According to introductory programming educators: the definition(s) of programming largely focused (narrowly) on the ability to instruct a computer. In other words, the educators neglected to emphasize the broader programming context discussed previously. It is plausible that respondents responded with impulse rather than well-considered reflection. We may also speculate that the responses simply articulate the “least common denominator,” more easily accessible to a less computing-informed audience; as in deliberately simplifying the act of programming to make it more easily understandable by an outside audience. However, the observation still stands: we tend to reflect upon programming as the ‘act of writing a program’ and do not consider the broader impalpable qualities. However, one thing is certain: there is no singular hegemon definition.

A Good Programmer Is …

The future of programming is not exclusively determined by our definition of programming; one must also consider the role of a programmer. Today, the concept of a ‘programmer’ has to be broader than the traditional office-dwelling professional developer, expanding to include end-user developers or vernacular/conversational programmers, not necessarily identifying as ‘programmers’ even though they may be doing exactly that: programming. In short, a cohort of ‘programmers,’ who, on a daily basis, develop and maintain programs, scripts, and software which drive crucial business functions, potentially in unconventional programming environments, and the group of individuals who must symbiotically collaborate with professional developers to develop and maintain software, require some degree of technical knowledge.¹⁰

Given the (now) broader definition of a programmer, it is important to acknowledge the potential differences between a good vernacular and professional programmer. Note that the respondents of our survey teach programming with various intentions; in particular, training both professional software engineers and conversational programmers. Without further context, we asked them what it means to be a good programmer. While there are differences between ‘doing programming,’ and ‘being a (good) programmer’ we find this a useful question to reflect further upon what we are teaching the next generation. Conducting the same categorization as with the previous open-ended question, educators argued problem-solving plays an important role (20%). However, and more interestingly, qualities such as the ability to abstract and decompose (20%), structure and create readable code (20%), reason and work logically (11%), and creativity (9%) appeared in their answers—something which we did not see when they defined programming. Further, there was little to no mention of the importance of writing the instructions for the computer.

Thus, when making educators consider the qualities of a good programmer, whether vernacular or professional, their responses, to a larger extent, incorporate the impalpable qualities associated with literature definitions of programming. Albeit the keywords mentioned have changed, there again seems to be no consensus regarding which ones are most important.

Programming in the Age of AI Is …

While the definitions in literature clearly emphasize the more impalpable qualities of programming, educators do not—at least not until we consider what it means to be a (good) programmer. Further, there does not appear to be consensus among educators. While this discrepancy is not necessarily problematic in a community where we are well versed in the intricacies of such definitions, it could well be problematic for those now learning programming. Are we simply telling students that programming is the act of writing instructions? Are we even explicating what ‘programming’ is? If not, it would be reasonable to expect students unfamiliar with the domain to attempt to outsource all their tasks to generative AI. As stated by Michael Caspersen, “… it will be a danger for undisciplined students who are seeking the easy way out.”⁸ We believe the lack of consensus among the perspectives gathered and presented here represent a testimony to the absence of such a conversation. With this, we do not intent to find a singular definition of programming, neither do we believe it to be productive. Instead, we hope that all will carefully consider what ‘programming’ is, and, in turn, make this explicit to those around us. We argue programming concerns the impalpable qualities described here, which are far less obvious to outsource to generative AI.

One way of achieving this is by incentivizing non-use of generative AI among students in early stages of programming education to develop an intricate understanding of programming; for example, by using proctored written or oral student assessment (to educate craftsmen). A different approach is to increase focus on teaching analytical program comprehension while applying generative AI to synthesize instructions, akin to Porter and Zingaro⁷ (to educate editors). While there exists a multitude of potential directions, it all starts with having the conversation with students and colleagues about what ‘programming’ is. Thus, we plea that educators and advocates communicate the intangible qualities of programming that will continue to be crucial—even in the age of AI.