You don't need to understand the justification for a checklist item to be able profit from following a ritual that goes through all the items on checklist. Following a ritualistic checklist would be knowledge in the Chinese sense where there's a huge emphasis of following proper protocols but it wouldn't be seen as knowledge in the philosophic western tradition.
I don't understand your point. The western tradition is perfectly capable of talking about the knowledge that following this checklist results in a measurable 25% improvement. So you must mean something else but I don't know what.
Nobody knows everything at the same time. The knowledge is split between the person following the checklist and the one who designed it. That doesn't make it a different kind of knowledge. And if the person who designed it just tested lots of random variations and has no idea why this one works, or if the designer is dead and didn't pass on his ideas, then there is less knowledge, but it's still the same kind of knowledge.
The programmer is a paradigm case. He works with very well defined logical or mathematical models of code execution. But he constantly relies on the correct functioning of a myriad other pieces of software and hardware. He doesn't know in full detail why he has to talk to these other things the way he does; he just memorizes a great deal of API details which are neither arbitrary not clearly self-evident, and trusts that the hardware designers knew what they were doing.
So when you say:
There are cases where the programmer can describe a heuristic that he uses to make decisions without pointing to a statement that has justified veracity.
It seems to me that almost everything the programmer ever does can be framed this way. Suppose I know that under high contention I should switch to a different lock implementation; but I don't know how the two implementations actually work, so I don't know why each one is better in a different case. I also don't know where exactly the cutoff is, because it's hard to measure, so there's an indeterminate zone in between where I'm not sure what to use; so I have a heuristic that uses an arbitrary cutoff.
Is this a heuristic that has no "justified veracity", or is this a kind of knowledge where I can prove (with benchmarks) that the heuristic leads to good results, with an underlying model (map) of 'lock A has less contention overhead, but lock B takes less time to acquire'?
He doesn't know in full detail why he has to talk to these other things the way he does; he just memorizes a great deal of API details which are neither arbitrary not clearly self-evident, and trusts that the hardware designers knew what they were doing.
I don't think knowing the API is sufficient to being a good programmer. The productivity difference between what Google sees in a 10x programmer from a normal programmer is not about the 10x programmer having memorized more API calls.
Simply teaching someone about API calls and about the specifics about t...
Another month, another rationality quotes thread. The rules are: