e.g. changing the question, reasoning by analogy
How do we have insight, a hunch straight to the answer? It seems obvious that it's like DL; socially distributed search across people; trying out different things unconsciously... but the truth is, we don't know how we do it. We're like steam-punks saying it's obviously like a mechanical device, or Edison saying it's obviously like electrical relays. We just think in terms of the tech of the day, and by persona; introspection and observation. It's not science. It's maybe science fiction.
When we understand Strong AI, we will already know.
Also explains why the concept of being smart is so elusive, as these optimizations are hard to reproduce and don't generalize to everything we think about. For example, a genius isn't better than an average person at filling out forms, there you are forced to think using unoptimized paths, you can't run those paths 100 times faster.
We're one level from popping the top off it all and coming to terms that we've fallen into a trap described by Ludwig Feuerbach.[1] The choice of analogies says just as much about us as they do about the subject.
1. Feuerbach(1881) The Essence of Christianity https://libcom.org/files/The%20Essence%20of%20Christianity.p... (p. 17)
I have a very hard time with reading the official PHP docs. Very hard time.
The official JavaScript docs are not bad, but they throw too much information about each operation. I don't want to know every single possible way to use an operation. I want a Pareto Principle-based categorization of most common use-cases so that I can prioritize what to look at.
For some reason I really like this idea ;)
I think documentation, just like literate programming, would benefit from multiple views or learning paths of the same topic.
When reading code, I break things down differently.
1. Domain knowledge
2. Programming knowledge (e.g. recursion)
3. What is being done
4. How is it being done
5. Where/when is it being done
Wherever possible I try to stay with strong opinions and alignment on the first three. The last two should try to be as simple and clear as possible. Reading code in this day and age should not so much be about 'playing computer' in your head, but rather using well-known/tested patterns that allow for factoring/composition and accurate reasoning without requiring deep context.It's rare that I find mental capacity to be the limiting factor, rather than the unintentional obfuscation of the implementation. Perhaps this is just to say that the code itself is a source of incidental (aka accidental) complexity or confusion.
[0] https://www.goodreads.com/book/show/57196550-the-programmer-...