Whiskey

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".

In my experience, LLMs aren't really that good at summarizing

It's more like they can "rewrite more concisely" which is a bit different

But surely there's a practical middle between "shoot first, ask later" and "sit and wait an hour"

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

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.

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.

If you used good objects, you'll only have to make the change in one place

IMO that's generally a retroactive statement because in practice have to be lucky for that to be true. An abstraction along one dimension -- even a good one, will limit flexibility in some other dimension.

Occasionally, everything comes into alignment and an opportunity appears to reliably-ish predict the correct abstraction the future will need.

Most every other time, you're better off avoiding the possibility of the really costly bad abstraction by resisting the urge to abstract preemptively.

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 .

Unfair how? It's paid by employers, so kinda makes sense to me, i.e. employer caused the loss of livelihood, so they pay for the benefit to the recently unemployed.

Must be proprietary, bc TOTP shouldn't be blocked by age of the device

I really dislike code like that. Code like that tends to lie about what it says it does and have non-explicit interactions/dependencies.

The only thing I can really be certain from that is:

  doAnything();
  if(doAnything2()) {
    doAnything3();
  }

I.e. almost nothing at all because the abstractions aren't useful.

This claim site's privacy policy seems to reserve their right to use your submitted data for marketing and promotional purposes...

to improve our marketing and promotional efforts

We want to provide you information that is valuable to you. If at any time you wish to be taken off our mailing lists ...

speed up certain types of applications as long as application providers don't have to pay for special treatment

Maybe they mean by doing things like giving slight priority to real-time application traffic like VOIP over streaming over websites vs file transfers, like how home routers can?

Don't think that should be something to charge people more for, though. They're not even able to deliver on their own advertised speeds.

Seems more applicable to an imperative style, and IMO even still the advice is too dependent on special/actual case details to be generally applicable as a "rule of thumb".

This is just one specific example amongst many of how redundant logic could be simplified because sometimes the branch is an implementation detail and you want to push it down, and sometimes it's not and you want to push it up.

Sounds like an externality that should be paid for as these things are manufactured

Good code is code that's easy to delete.

I'm not a game dev, but it's got a reputation for being more of a software engineering shit show than other software industries, which your story only reinforces.

All methods? Of course not. Just methods like these.

I find it's possible to operate Python as a statically typed language if you wanted, though it takes some setup with external tooling. It wasn't hard, but had to set up pyright, editor integration, configuration to type check strictly and along with tests, and CI.

I even find the type system to be far more powerful than how I remembered Java's to be (though I'm not familiar with the newest Java versions).

Except it does, which is why so many people are so bad with money.

I could agree with criticisms of outdated teaching methodologies or uninteresting course material, but saying math is irrelevant is totally misguided.