A significant amount of programming is done by superstition

This is probably why I am an engineer instead of a pure scientist. I want to see something working, and be free to play with it, take it apart, put it back together, combine it with other things I know, etc. I do this with computer programs, with engineering systems, with mathematics. The more I do this in a given area the more intuition I build up and the more easily I can then learn something else from first principles if I need to. But I really do prefer to get my hands dirty first. Other people don't do this -- chalk that up to different learning styles.

I try to guard against cargo-culting (I abhor it).

If init scripts are mostly boilerplate that people keep copy-pasting, maybe the init process is the problem, rather than the poor chumps who have to write the scripts?

Usually when I'm writing code it is "Let's get the infrastructure up and come back to clean up after I know it works..." Sometimes I never come back. It doesn't mean I think the code is correct, only that it is not the biggest problem.

As you've pointed out, "no intuitive knowledge", the first principles of a language/api/framework come implicitly attached with design patterns that are probably fairly deep for whatever reason. Your usage of them gets you familiar with the framework, thus your ability to work with them. I would also concur that practice is necessary before being able to construct anything from scratch.

The cognition of programming languages is very much like regular human languages. It takes a tremendous amount of disciplined, repetitive practice and observation before the mastery of a language allows it to just flow effortlessly out of ones fingers.

A simple concrete example is the difference in articulative ability in constructing the same exact sentence for an essay between a 12, 18 and 25 year old post-doc. For the post-doc who has written a countless number of 10+ page essays versus the 12 year old in 6th grade who has more-than-likely never written anything beyond 1-2 pages, the ability is obvious and striking. The patterns and structures come naturally to the well-practiced individual as the Chinese parable of ZhaungZhi teaches us the the concept of achieving flow (WuWei).

The difficulty with mastering programming the way we speak english (or any other primary language for that matter) is that many projects only ever need to construct the equivalent of a proper sentence once, then that sentence is committed to source control for eternity without ever needing to be constructed again, thus the cognitive muscles creating programs tend to not achieve flow, but the muscles of identifying, locating, copying, pasting & modifying do tend to achieve flow.

To exacerbate our inability to construct things from scratch, we also look to reduce the monotony and abstract away the difficulty and reduce what actually needs to be written and kept track of from our keyboards via APIs and abstractions that segregate duty. Of course I'm not advocating that good architecture be thrown out for the sake of practice, but in a sense, programming could use the equivalent of musical scales, where the well known patterns, and language-native constructs are exercised daily (frequently enough) to the point of trivial mastery.

The argument against such kinds of practice from my peers & others on this board has been,

"duh, that's what API documentation and computers are for." "This stuff can be looked up." "This is why whiteboard programming exercises are not indicative of programming ability." "See, why learn math, when I can just type x+y into the console and get the result?"

However, I'd argue that the effortless mastery that comes from daily practice comes with tremendous benefit. The mastery allows one to focus on the architecture problem set rather than the details of what to name a method (assuming that good method names come naturally from practice). Or be encumbered by whether the first or second argument in the split method should be the separator.

Would it be acceptable as a passenger of a bus if the driver claimed that they did not need to know whether the left or right pedal was the gas or brake pedal since that could be looked up via Google in the API documentation for the bus? Of course the scope of learning how to drive can be mastered in a couple of months, but programming is more equivalent to spoken language and perhaps mastery of playing musical instruments.

I would argue that much of the arguments for or against certain interview techniques/questions/strategies really stems on what the interviewers and interviewees see as a signal for effortless mastery. Esoteric pet questions test for intimacy with a narrow topic, but also get to assume that other deep-related knowledge follows along. Whiteboard interviews are looking for problem solving ability, but also effortless mastery of a language and basic data structures that someone with 1-2+ years in a language probably should have.

But at this point, I digress.

I think that sometimes Hungarian notation and strict coding guidelines can help, but more and more I think that there's no way to effectively enforce those things unless you automate them from the beginning. I've worked on very effective teams, where nothing ever got checked into master without two sets of eyes on it, strict rules were followed, etc., and there are always holes from lack of automation and legacy code.

Automation helps: linters, static checkers, runtime memory checkers, automated tests, all should be run on every check in. On a C# project I even created a tool that correlated diffs with a code coverage tool and rejected diffs that weren't covered by unit tests (it misses cases where code paths were executed by preexisting unit tests, so it didn't necessarily require a new test for every diff--I consider this a bug). But you always end up making compromises because there's Xthousand lines of code written at the beginning of the project that you don't have time to go back and write tests for.

One of the reasons I'm really excited about Rust right now is that it makes it easier to set these things up at the beginning. A lot of memory checking you have to do with separate tools in C comes free with Rust's type system, while Cargo makes it very easy to get unit tests up and running. My hope is that if Rust finds wider usage, the projects I come into will be more likely to have been set up properly from square one, and it will be easier to work on larger code bases.

I dunno, I'm somewhat new at technical leadership, so I'm still working out some of this stuff.