Games from people like World of Goo are exciting. I wasn&#x27;t sure how I&#x27;d even imagine a game that could teach skills with good mapping to programming. They&#x27;re doing a good job. Prior to that, the best results we were getting were projects like the brilliant MIT Scratch that turned it into collaborative, creative, lego building (below). Should still invest in stuff like that, too, which is more direct but fun.<p><a href="https:&#x2F;&#x2F;scratch.mit.edu&#x2F;" rel="nofollow">https:&#x2F;&#x2F;scratch.mit.edu&#x2F;</a><p>On other hand, that programming is a fundamental skill is an assertion that&#x27;s being repeated by many without evidence. It&#x27;s a useful skill that will become more useful as we go along. Yet, something like 80-90% of America, including top 1%, know nothing about programming despite their job success or quality of life. There&#x27;s no direct tie in. Meanwhile, they use reading&#x2F;writing and mathematics on a regular basis. So, I think people should stop making this claim as most people will mentally tune out upon seeing something like that.<p>This brings to a bigger point where software isn&#x27;t engineered despite prior work showing how to do it. That started with Margaret Hamilton and Dijkstra in the 1960&#x27;s where both of them used modularity, layering, and interface checks to build flawless systems. By the 1980&#x27;s, Hansen had safe concurrency (Concurrent Pascal), Mill&#x27;s Cleanroom let teams hit almost no defects first try, LISP machines let you live-edit, incrementally-develop running systems w&#x2F; no compile phase, Schell had a NSA-resistant kernel (GEMSOS) that ran other things as processes&#x2F;containers on virtual CPU&#x27;s (sound familiar?), and Wirth&#x27;s simplicity + safe language approaches let ETH run on their students&#x27; OS&#x27;s. Each of these approaches led, with small teams, to systems that reached high levels of security, reliability, extensibility, and (for Lisp machines) productivity.<p>Yet, the techniques that built them are largely not used by mainstream. The negative results are predictable. So, we have two problems: (a) getting nonprogrammers into programming so they can solve problems with <i>some</i> approach and toolset; (b) getting programmers into <i>engineering</i> so they can build robust, maintainable systems using lessons learned from the past. Like other engineering fields do. So far, we&#x27;re doing better at (a). Some good news at least.