problems only have one answer and often one strategy to get to the answer
Totally disagree
You're thinking of equations, which only have one answer. There are often many possible ways to solve and tackle problems.
If you'll permit an analogy, even though there's "only one way" to use a hammer and nail, the overall problem of joining wood can be solved in a variety of ways.
I think this is common in scientists and researchers. They operate at the edge of knowledge with one foot in the unverifiable and their eyes peering further still into the murky unknown. There is no map nor direction where they're going, and that extension out into the darkness is often much like superstitious belief.
What makes them different from followers of the occult that remain lost in the fog is that science returns from explorations with verifiable proof. Research extends it's own foundations with new findings in order to venture yet another step further outwards.
IMO mathematical/logical/abstract thinking is critical for programming well, but IMO that's different from "math degree" math.
Software as a means to an end can be used in almost every domain, so proficiency within that applicable domain is often either useful or necessary. That is to say, "math degree" math is likely needed for 3d rendering (certain games), scientific computation (incl machine learning), etc, but maybe not, otherwise. It depends on what software you're trying to build.
To be more specific, general programming is definitely and specifically different from trig and calc. However, because math is also broad, "mathy" concepts like type theory, relational algebra, set theory are considered important for programming, even if only informally or indirectly so.
How does playing the game bring revenue? Ads?
Also, I would think that the business would be in a tougher situation if game popularity increased while tech workers weren't around to maintain it
I think your ideas are too non-practical/specialized/advanced/low-level for your stated goal of 'digital literacy". They read more like college intro/followup course material and are too esoteric to be readily absorbed, esp by generic teenagers, even if they've self-selected to be "lightly interested".
If you were reviewing a "non-trivial" PR from me, I'd recommend not squashing because I would've broken it up into readable atomic commits.
You're getting a lot of conceptual definitions, but mechanically, it's just:
keeping state (data) and behavior (functions) that operate on that state, together
At minimum, that's it. All the other things (encapsulation, message passing, inheritance, etc) are for solidifying that concept further or for extending the paradigm with features.
For example, you can express OOP semantics without OOP syntax:
foo_dict.add(key, val) # OOP syntax
dict_add(foo_dict, key, val) # OOP semantics
But surely there's a practical middle between "shoot first, ask later" and "sit and wait an hour"
A title as uninformative as the single . commit messages he suggests writing.
Bare minimums of typo, refactor, whitespace, comments are barely any effort -- less than the thought it takes to name variables and functions.
I really can't agree with completely meaningless messages like minor and .
That route already exists today as "the web", where the "latest" JavaScript source is downloaded and JIT-ed by browsers. That ecosystem is also not the greatest example of stable and secure software.
I've never seen these "express code/tests in natural language" ever work well. Your non-coders need lawyer-like skills to wield English very precisely, or it falls to coders that would be better off using code directly.