The synchronization problem (flakiness and all the waits) is tricky to get right. Browsers are concurrent systems, and programming around one is specialized enough that many devs don’t do it well, e.g. IMO if you’re adding ad-hoc waits or nesting timeouts, you’ve already lost.

It refers to a male cousin that is NOT in the same paternal line, so maybe not too uncommon?

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

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.

Fine for prototyping, but adds a scaling tech debt “time bomb” for a live system. Those associations had better be really sparse.

So… a polymorphic many-to-many join table?

What do you do for a living/what are you into that isn’t super deep in some way? What field did you rabbit hole into in the past that makes you go, “never again”, now?

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.

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”:

• https://upperstory.com/turingtumble/ - A physical algorithmic marble and lever puzzle “board game”. Great (and designed for?) for kids. Not programming.
• Factorio - A factory-building game that “feels” a lot like software development. Not programming.
• Opus Magnum - mechanical puzzle game by Zachtronics, build algorithmic “molecule-building machines”. Not programming.
• <Any other game by Zachtronics> - varies from “not-programming” to “contains programming”. Can get pretty difficult sometimes.
• Human Resource Machine - Programming puzzle game using assembly-like language. Later stages are challenging.
• 7 Billion Humans - “sequel” to Human Resource Machine, more featureful language, has concurrency and randomness. Later stages are challenging.
• https://www.hedycode.com/ - An innovative learning programming lang and “levels” method that makes Scratch primitive by comparison. Has free online lesson plan & environment. Hedy level 18 is vanilla Python.
• https://www.codecademy.com/ - you said you’re using this already

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.

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.

avoiding merge conflicts

No, not like that – you misunderstand. I’m not talking about actively avoiding conflicts. Coordinating to avoid merge conflicts is the same work as resolving a merge conflict anyway, just at a different time.

I’m talking about creating practices and environments where they’re less likely to happen in the first place, never incurring the coordination cost at all.

One example at the individual level is similar to what you mentioned, but there’s more to it. E.g. atomically renaming and moving in separate commits, so git’s engine better understands how the code has changed over time and can better resolve merges without conflict.

But there’re other levels to it, too. A higher-order example could be a hot module where conflicts frequently occur. Sure, atomic commits and all that can help “recover” from conflict more easily, but perhaps if the hot module were re-designed so that interface boundaries aligned with the domains of changes that keep conflicting, future changes would simply not conflict anymore.

IMO the latter has an actual productivity benefit for teams/orgs. Some portion of devs just aren’t going to be that git proficient, and in this case, good high level organization is saving them from losing hours to incorrect conflict resolutions that can cause lost work, unintended logical conflicts (even though not lexical conflict), etc. Plus, it implies abstraction boundaries better match the changes demanded by the domain, so the code is likely easier to understand, too.

It’s kind of difficult to explain in the same way git is difficult to grok on the first try.

Perhaps it’s convincing enough to just say:

• Git is the fundamentally better at resolving merges/rebases without conflicts than older VCS that don’t maintain a commit tree data structure.
• Even within just git, using one diff algorithm vs another can mean the difference between git successfully merging vs failing and showing you a conflict
• Software is flexible – there are endless permutations to how it can be structured. Everything else being equal, some code/commit structures are more prone to conflicts than others

I.e. whether a conflict will happen is not some totally unpredictable random event. It’s possible to engineer a project’s code & repo so that conflicts are less common.

Even better, learn how to avoid conflicts from happening in the first place!

Thank goodness for the Hippocratic origins of healthcare. Wish I could throw his words back at him so he could hear how insane it sounds in the context of healthcare. Just imagine:

You think a doctor sits back and says, ‘Gosh, how can we get the price of saving this patient’s life down?’ No, it’s like, ‘How high a price can I get and maximize the profit for my shareholder?’"

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