One of the best use cases is implementing abstract data types and hiding the memory management and other potentially unsafe optimization tricks behind a clean and high level abstraction.
Also since it's a logical/mathematical construct and not attempting to model the real world (like business logic), it's one case where inheritance hierarchies will remain stable.
I feel a lot of advice here is trying to push the learning envelope without considering fun & the learning experience. This is for an 8 yr old, and I'm seeing suggestions that would seriously challenge high schoolers, college students, and even some software engineers in industry I've encountered.
For the software aspects of programming, I would suggest looking at programming(-esque) games and web browser programming environments. Here's a solid short list, vaguely sorted from "proramming-esque" to "actual programming":
Suggestions to go physical tinkering with electronics is good, but I'm unable to make good suggestions there.
A real computer and coding environment/shell could be good for system admin skills, but the learning curve is steep. You'll also have to be okay with letting him accidentally brick the computer (best way to learn!).
Disagree with Docker and git at this stage of learning. This is an 8yr old playing with scratch, Minecraft, and early levels of CodeAcademy.
The answer to "not dealing with environment" isn't Docker, it's a programming(-esque) game or an in-browser environment.
IMO okay advice for specific types of issues, but way too prescriptive to work well generally.
Steps 3-4-5 are good, and breaking it down like that could be helpful to readers, but in my mind, it should be so well practiced and executed so naturally that it feels like a single step. I also think there ought to have been a mention of the fast iterative experimentation where 3-4-5 is repeated.
Break the build (and block other devs)? Is this a 1-team company?
Write a test first? Maybe, if you've already got a well isolated, somewhat understood problem whose solution won't require deeper restructuring.
Immediately "Brainstorm as many hypotheses ... as you can think of"? Inefficient if you already have a good idea of what's wrong (wasting time guessing), and also inefficient if you have absolutely no idea what's wrong (wasting time with uneducated guesses).
Ooh yeah PR as patches, persistent despite rebases, would be nice.
Many git operations fundamentally have three SHAs as parameters (tree operations after all), and GitHub's model simplifies it down to two.
Unfortunately it's uncommon now that GitHub's PR workflow dominates, so people think in terms of (often squashed) PRs and talk about "stacking PRs". At least GitHub supports viewing PRs commit by commit.
If PRs are just how it's going to be, I wish GitHub could auto cut stacked PRs from a linear branch of commits.
Oh, interesting
Hell of a frame budget to work by, but I don't know much about game programming
You can, once you find a game that runs at 1k fps
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.
Pretty spiteful of you
In the long run, nearly the same effect as 100% inheritance tax anyways.
The government won't know the cash has been removed from the economy, but it'll have been removed all the same.
I think people are being lazy, in a selfish, tragedy of the commons sort of way.
When standing in line, they all watch the customer stand there doing nothing as the cashier checks out items. If only they'd bag their own things, we'd all be able to get on with our lives that much sooner. Instead, they continue standing there doing nothing, as the cashier now bags their items.
Then the next person in line moves up and also just stands there, also unwilling to do anything to help speed things along.