"Computer programming is perhaps the best exampleof a class of problem-solving tasks that can be called 'procedure specification.' In these tasks a sequence of actions is specified in some language such that, when these tasks are executed by a designated agent, a particular goal can be accomplished. In procedure specification tasks other than computer programming, like the writing of trouble-shooting manuals or kitchen recipes, the language of specification is the writer’s natural language. Computer programming, however, is accomplished in unnatural (some would say 'unholy'), formally defined, and self-contained lan guages" (Miller, 1981)
We tend to think of programming as writing code. Stringing together symbols that a computer can interpret and turn into behavior. This puts code in a category with things like natural language programming and visual programming. The big category is "languages computers can understand" and the relevant measure is "how hard is it for people to speak that language".
But what if we expand that definition a little, to include all of the situations where we ask the world to do things for us. In other words, let's think of programming as a special kind of computational offloading. A unique kind of computational offloading that is really hard and really useful, but nonetheless, just computational offloading.
That means that programming is in a category with lots of things, including drawing diagrams, leaving reminders for yourself, giving people directions, and writing things down. The big category is "getting the world to do something for you" and the relevant measure is "is it less work than doing it myself".
People are gifted computational offloaders, and it's not hard to see examples of this everywhere. When someone needs to remember to bring a book with them to work in the morning, they lean it against the door so they don't forget it. When they need to give someone access to their building, they prop the door with a wastebasket. These interventions manipulate existing processes in some small way, modulating the outcome. The door would have swung anyway, the wastebasket just prevented it from making it to the jamb.
This differs from code in two ways. First, code must be fully realized before it can be run. You can't build an algorithm by starting a loop, watching data flow through it and slowly add lines of code in between. You can't pull lines of code out of running software. Second, even if you could, the results would probably be disastrous. Code is brittle. The removal of a single bracket is almost always catastrophic. It's difficult to break the natural world, and most objects are rather fault tolerant. You can pull the backseat out of a minivan and it still drives just fine. Snap a plastic fork in half and you have a fork and knife for small hands.
In this new category, code has some unexpected neighbors.
Lemmings
Miller, L.A. (1981) Natural language programming: Styles, strategies, and contrasts