I don't think knowing the API is sufficient to being a good programmer.

Of course it isn't (but it is necessary). I didn't mean to imply that it was. But I do think this example generalizes to almost all the other things that a very good programmer needs to do.

That heuristic is knowledge that's able to be verbalized but that moves farther away from justified veracity. You can go a step further and talk about how to pass down the system I sense of surprise from one programmer to another.

That heuristic is knowledge that's able to be verbalized but that moves farther away from justified veracity.

Why do you think so? To me (as a programmer) heuristics about when to check what feel perfectly knowable and able to be verbalized. To be sure, they would take a lot words. Maybe more importantly, they're highly entanged with many other things a programmer needs to know and do. But I don't see what would make them less justified or less explicit, just more complex.

You can go a step further and talk about how to pass down the system I sense of surprise from one programmer to another.

It's a truism that you can't gain habits of thought, or mental heuristics, just by abstractly understanding and memorizing a bunch of facts; that's just not how humans learn things.

That doesn't necessarily mean there's a lot of information in the heuristics that isn't contained in the dry facts. You can't get the heuristics by practicing without being aware of the facts. If you can't explain why you act out the heuristics you do in terms of the facts you learned, or if you can't verbalize what heuristics you're acting on, that is more likely to be a failure of introspection, rather than evidence that your mind developed extra incommunicable knowledge the facts didn't imply.

If you go and study computer science you won't find classes on developing an appropriate level of getting surprised. It's not the kind of knowledge that professors of computer science work to create.

Because they're studying computer science, not programming.

Yes, if you look at software engineering, its state of formal education is quite bad compared to some other engineering professions. I even have a good idea of the historical causes of this. But that doesn't mean programming can't be taught or even that nobody learns it well formally, just that most programmers don't, as a social fact. They're encouraged to experiment and self-teach; they start working as soon as someone will pay them, which is much earlier than 'when they've mastered programming'; they influence one another; and the industry on average doesn't have a lot of quality control, quality standards or external verification, just 'ship it once it's ready'.

How many checklists have you used the last week? How many thing you do follow strict checklists? How many serious philosophers deal with the issues surrounding checklists?

No checklists that I can think of. I have no idea what philosophers en masse spend their time on, serious or otherwise.

Checklists are a specific solution which need to be justified wrt. specific problems, most of which have alternative solutions. I don't think 'not using checklists' is a good proxy for 'not doing a job as well as possible' without considering alternatives and the details of the job involved. At least, as long as you're talking about explicit checklists consulted by humans, and not generalized automated processes that reify dependencies in a way that doesn't let you proceed without completing the "checklist" items.

Going back to your general argument, are you saying that Eastern philosophical traditions are better at getting people to use checklists (or other tools) without understanding them, while Western ones encourage people not to use things they don't understand explicitly?