Finally I got some time to read the opinion paper "What is Programming" [1]. The authors Nicolajsen and Brabrand conducted a survey on educators perspectives on the programming discipline and compare them with definitions from pillars of Computer (Computing) Science. The paper argues that it is necessary to communicate the intangible qualities of programming [1] to programming students in the "age of AI".
When I was asked to lecture Introductory Programming to freshmen of Industrial Engineering at UNAM, I remember asking myself this question and reflecting on it for quite some time. The task was exciting to me because Industrial Engineering has "nothing" to do with programming. The students asked: "why is such a course mandatory?" and this question alone reflected the state of mind of the students. Indeed I won't argue in favor or against making an Introductory Programming in C a mandatory course for Industrial Engineering first semester students. It is what it is and the question was: "are you, Alfredo, up to the task?" Obviously I was, it was a challenge, and I had the tools for it.
I was familiar about the diverse and extensive literature on Introductory Programming, reports about how "difficult" a language is for first-time students, about engagement and performance of students, about the development of the so-called "Computational Thinking" in students, even studies about demographic or gender distribution and its relation with performance. On the other hand, I was also familiar with literature on education that surprisingly doesn't seem to have made a dent in CS education. One really good piece of that literature is [2]. If you are interested in education, I will not spoil the fun you will have reading this book, (and the others) but, for this I will only pick the fundamental piece that helped me crack the problem: There is a good deal of evidence that learning is enhanced when teachers pay attention to the knowledge and beliefs that learners bring to a learning task, use this knowledge as a starting point for new instruction, and monitor students' changing conceptions as instruction proceeds.[2]
The problem then, may seem to become even more difficult: Teach students
with little to no interest in programming to program in a language that is
widely regarded as really difficult for novices and do so, in a way to
link to the pre-existing knowledge.
It was highly unlikely that students were familiar with C.
I may be naive, but I'm not that naive.
However, contrary to popular belief students do have a lot of experience
with Programming and a developed Computational Thinking.
And this does not come from their constant use of technology, it is all
around them (us).
It turns out that if you try to link pre-existing knowledge into the
formal programming learning task, then programming becomes just
doing-making a recipe.
I will let this sink for a moment.
A recipe has a goal, and it is composed of steps that must be performed
in certain order if you wish to achieve that goal.
In theory, a recipe is reproducible, follow it and you will get the same
result always.
A less abstract example is programming a washing machine, a microwave,
a doctor's appointment or even programming the alarm on an analog clock.
We are constantly surrounded by the concept of a program as: the set of steps
required to achieve a goal.
And obviously we are quite successful at it.
In the examples I just described, the goal and the steps exist, and
programming becomes the action of realizing all the steps in the established
order.
The recipe becomes the equivalent of an algorithm.
But it is much more than that.
When we follow a cooking recipe, sometimes we don't have the same kitchenware,
perhaps our stove is less powerful than the stove available to the author
of the recipe, and so on.
So, we must adapt the steps of the recipe to our "hardware".
This adaptation happens all the time when you implement an algorithm and
even more so when the implementation takes place on a programming language
of a different paradigm than the used to express the algorithm.
But many times we also create on the fly we follow the recipe for
certain dish and we wonder: "what would happen if I add this ingredient?".
Then, if it works, we can add the steps we performed to the pre-existent
recipe to remember them. This is the equivalent of modifying a program
and later formalize those changes.
The most important element in doing-making a recipe is the actor, the one
who performs the action, i.e. the programmer.
Nicolajsen and Brabrand [1] identify two categories for the definitions of
programming: one is called narrow and I will name the
other broader.
The narrow category includes all definitions that define programming as
the act of writing instructions for a computer.
The broader category includes the definitions introduced by Knuth, Dijkstra,
Naur, etc. in which programming is enriched with axes like
... aesthetics, ingenuity, and inherent creativity" as well as
understanding of the "problem domain" [1].
Interestingly enough, when educators are asked what programming is, Nicolajsen
and Brabrand observe the educators definitions fall within the narrow class.
However, when asked what a good programmer is, then elements from the authors'
broader definition of programming surface.
I have a simplistic explanation for this in order to explain why
... the educators neglected to emphasize the broader
programming context discussed previously
instead of the first one offered by the authors It is plausible
that respondents responded with impulse rather than well-considered
reflection [1].
Who can better define a discipline than a practitioner? If you ask a Chef, who has raised its practice to an art form, what cooking is, the answer most likely will include all the elements of Nicolajsen and Brabrand broad definition of programming. On the other hand, if you ask a fast-food minimum wage Cook what cooking is, the most likely scenario is that the definition would not include the word art. Even when fast cooking a multitude of dishes is an art in itself. However, both prepare food, both are edible (to some degree) and both serve the same basic goal, to feed. I think it is erroneous to label the definition of a consummated practitioner who has made a name in the field to be a more complete definition. It is a definition biased by personal success. After all, when you are top notch in your discipline you will not define it as something simple, right?
The difference in the definitions given by educators observed by Nicolajsen and Brabrand about programming and what a good programmer is, can be explained as: "My job is to turn non-programmers into programmers, that is, to make them able to write computer programs in a finite, one semester course. But I recognize good programmers when they (insert all the qualities here)". Just as my parent's job was to teach me how to cook so I can sustain myself, not to turn me into a Chef.
When you have a strict study plan to follow dictated by school councils, it is challenging to aim to make Chefs out of mere mortals when you believe your students are on the "clean slate" state when they reach you ... half of the students immatriculate without prior programming experience [1]. I had a month, that is, 12 hours before my students were asked to write their first lines of C successfully (to comply with school standards). Students informal computational thinking and informal programming experience is extensive when they reach the classroom. So, I could built on top of this experience and gently formalize the pre-existent knowledge into knowledge suitable to allow them write simple C programs. At the end of the 12 hours of instruction, the students are handed out a simple syntactical and semantical manual of basic C and are tasked to implement algorithms they have developed, studied and refined in a "class created" language with no advice from the instructor (me).
During the course students continue to develop their own programming language in parallel with their C programming skills. Programming in C becomes just a simple translation between their own computer and programming language model and the C programming language. I aim for Chefs, and the students in a great extend deliver to this expectation: near the end of the course they are able to create, justify and manipulate two's compliment to represent negative numbers as well to explain different bits of the Linux Kernel. On school-wide Introductory Programming final tests, designed by the School of Engineering, my classes have been placed on Top 5, outperforming the vast majority of classes composed of students in which the computer is a paramount component, e.g. Computer Engineer.
Does AI poses a learning risk?
It certainly does, but I think the arguments discussed so far by the community
are far from the underlying, fundamental argument: purpose.
My students with all their candor (and the trust to express it) ask the
question with real concern "why is such a course mandatory?".
It is a reasonable question to be asked from a student of Mine Engineering.
If we, as educators are unable to make a case for why it is relevant,
then we are probably dooming our students to fall for AI, or any other technological
edge they can get.
After all, when something is not relevant, we as humans, tend to follow the
least-effort principle.
So, if we as educators have this focused, narrow, and pedestal worthy
view of programming as something difficult and artful that just a selected
few can perform and combine it with a view from the students of something
unexceptional, we are asking for unneeded trouble.
All of us need to cook, but not all of us want or need to be Chefs, many of
us just need to cook to sustain ourselves and perhaps spoil us from time to
time with some culinary treats.
[1] Nicolajsen, S., Brabrand, C., "What is Programming?",2025
https://cacm.acm.org/opinion/what-is-programming/
(last accessed: May 17, 2025)
[2] Bransford, J.D., et al. (Eds) "How People Learn", Expanded edition,
National Academy Press, USA, 2000.
Copyright Alfredo Cruz-Carlon, 2025