I don't know what companies you've worked at, but you can clearly get pretty far without having that sort of mastery over a particular language. I'm not saying it's good to stay in that state of ignorance, but it's definitely a thing, and I think the more gentle introduction to learning the topics that dynamic languages provide makes it more likely people will stick with programming at all, rather than quitting and changing their major to History or something.

>>but you can clearly get pretty far without having that sort of mastery over a particular language.

Completely agree. If this weren't true, the fizzbuzz test wouldn't exist.

The 90s were filled with businessmen creating Access databases that wouldn't scale, and Visual Basic's drag-and-drop capabilities created a cottage industry for controls consumed by non-programmers.

That's both good and bad. Bad for the obvious reasons (lots of crap software) but good in that for the most part people were able to build what they needed to solve problems and move on.

The trick is to benchmark that "crap software", not against the architectural marvel you would build, but against the Byzantine Excel spreadsheet (or worse, binder of paper forms) that would have been used otherwise.

Nowhere is "worse is better" more true than line-of-business software.

I'd agree, and even in Python, we end up talking about how some variables store "memory addresses," to explain the sometimes confusing behavior of variables bound to mutable objects. What's less essential is understanding all the ways that (C's) pointers can bite you: pointer arithmetic that results in invalid addresses, use after free, dereferencing uninitialized pointers, returning a pointer to a local variable from a function, and so on.