Separation Of Concerns
It has long been at the back of my mind that learning how to write software programs should be compulsory in schools.
Leaving aside any economic benefits to the individual, GDP or to Society in the large, it teaches you how to analyse complex phenomena in the abstract, and how to break them down into functional components, the nature of which may be understood independantly of their actual make-up.
You do not need to know how to make a fire-alarm in the real world to program a software alarm that responds to a button in the real world … you just need to understand that a sequence of relationships exists between an event (a fire), its consequences (one of which may be that a fire-alarm button is pressed) and the subsequent events that must follow (a signal being sent to the appropriate people, such as the Fire Brigade).
In fact, what you learn is that … in the real world … the sequence of relationships does not actually start with a fire but with an entirely separate event — namely, the pressing of a fire-alarm button, which could be pressed at any time.
In fact, what you learn is that you needn’t concern yourself with the reason why the button was pressed but simply with the fact that a button was pressed — it could be a button that someone presses in a bank to alert the Police that a robbery is taking place.
In fact, it needn’t even be a button — it could be a lever … or a voice … or an iris scan … anything.
In fact, what you learn is that … in the real world … there are entities (such as people or buttons) and events (such as the pressing of a button or the scan of an iris).
Equally, you do not necessarily need to worry, when constructing the program, how any of these things occur (someone else might write those bits of code for you), just to ensure that the right component elements of the necessary functions are implemented, such that, the emergent behaviour of the whole, when all the program code is included, is that a software alarm system achieves exactly the same result as a physical system.
What you learn is how to decompose a phenomenon into its most basic set of fundamental relationships … what makes it an example of one class of phenomenon, rather than another … what makes it the way it is … independently of its constituent elements’ real-world instantiation.
You don’t need to know any Chemistry to write down the instructions for making a cup of three-minute tea, for instance … you just need to know what order to put the cup, tea, water and any other elements in.
In fact, you don’t even need to know that tea exists to determine the correct sequence of events; you just need to know how to make a hot drink … any hot drink … and substitute for ‘X’ whatever it is that you want to drink and leave it for three minutes before performing the next step (which might, or might not, involve removing or straining one substance, such as tea, from a hot liquid).
What you learn is the Separation of Concerns.
Add in Recursion (see here and here) / Self-Reference and a lot of stuff that appears to have … and, actually really does have … nothing whatsoever to do with computers begins to fall into place — because it’s not programming/coding or computers that are the issue, but the mind-set they engender and the thinking tools they provide to manipulate abstract concepts.
You learn how to analyse.
The thing about real learning is that the brain quite literally learns by doing … by both physically and functionally re-creating itself as something that is capable of doing what it wishes to learn.
And programming requires you to actually do something about your ideas … to program and test them.
Computers only do what you tell them, so the best way to find out if your ideas are sound is to model them computationally … because, if your logic is wrong, the model you built does not behave the same way as the thing you are modelling and your analysis, therefore, evidently flawed — so you are faced with no alternative to changing your mind about how accurate your perception was to start with.
Learning to program is one of the most brutal ways you will learn to question your own assumptions about things … because there’s no clearer indication that they were wrong than when your model of how birds fly has them crashing into each other — there’s no more in-your-face example of “You’re wrong” than something that doesn’t work when you finish making it.