It's not about code. When you, as a programmer, consider the purpose of programming, and how computer-illiterate people view it, things are different. A programmer's job is not to type code. It's to find out what is holding other people back from achieving what they want and find a way to remove that barrier. It's to solve problems and help people make more valuable use of their time.<p>It could be the analyst that spends hours of drudgery printing out things from one system and retyping them into another (then going back to fix the typos) when what they want to be doing, what would enable them to provide value, is analyzing the output from the second system. It could be the junior exec that spends countless hours manually collating data to build spreadsheets and presentations about their projects, when they want to be doing is trying out new ideas and refining their projects.<p>Many people were raised to "write each vocabulary word 30 times" and see drudgery as a necessary, albeit frustrating, part of their jobs. Programmers automate that away so those people can do more important and useful things and produce more value. It's not just drudgery though. People have hard problems, often vaguely defined, and programmers help them understand, specify, clarify, and solve those problems.<p>Younger generations are more computer literate, but still often just use computers and don't realize how much control they could have over them. They may use programs that don't do quite what they need, not realizing how easy that would be to fix. Even if they're not the ones doing the programming, just recognizing that a programmer could help solve their problems is valuable.<p>At the same time, many non-programmers don't realize how hard some things are to program, or how clear, precise, and unambiguous things need to be defined in order for computers to produce the desired result. They assume something must be simple when they can't even define what the something is. Or they assume that because a program exists, any programmer could make an equivalent but slightly different program quickly and easily.<p>We don't need to teach everyone to code, we certainly don't need to teach everyone the syntax of some specific language. But we really do need to teach them to think in these terms. What problems do you face? Which of those could be automated or streamlined? How would you specify it clearly and unambiguously? What edge cases and special conditions do you need to deal with? etc. Given that line of thinking, those who are interested will learn to program and those who aren't will at least understand it. Some hypothetical pictocode/vocalcode/AIcode doesn't really matter. People need to understand the basic concepts of problem-solving and automation, how they can be useful, and what makes them relatively easy or difficult.