I'll resist this, for my interest in the analogy is not primarily to get an anatomy of thought processes, my focus is on techniques to improve thought, and this requires a different perspective. In improving software performance, concentrating on the language features would be like an artist whose focus was on the paint and the brushes. Although one uses the language features to make changes it is experience of software optimisation itself, rather than the language, that sheds some light on how to change one's own thought patterns. Two programs running at the same time on the same hardware may take more total resources than if run one after the other. Thinking about one thing whilst worrying about something else may be a waste of resources.
Productive programmers debug their procedures before trying to improve performance.
Their work on optimisation focuses on the most heavily used and most common cases. By analogy, if teaching ourselves how to make good and useful snap decisions, it's as well to check out the reliability of the 'slow but sure' method first. Good programs have comments. So should ways of thinking. I could go on, possibly with more tenuous connections.