Anyone feeling honest resonance with your words should read the book. I can't put it in other words.
In fact, the book itself has two audiences - the problem solver, and the teacher of future problem solvers (with the suggestion that if you're the former, you can also be the latter by talking to yourself). So the book gives you both a bunch of stuff to internalize, and a discussion on how to teach that stuff to other people.
--
Tangentially, reading this is making me do some serious soul searching about the way I approach programming. For instance, Polya emphasizes reviewing your work as an important step in solving a mathematical problem - not (just) to re-check correctness, but to spend some time thinking about the structure of your solution, and learn something from it. This is something I just realized I rarely do in programming - I don't review my code to learn more from the very solution I just implemented. I usually just commit and continue to the next thing. This is a thing I'm going to work on changing.
That said, I think it's worth investing your own time in doing it. I feel a lot more at ease when I take time to think about my work, and I think it pays off in my own career in the long run, even if it costs me some of my own time.
In the old times, many Germanic scholars would build a similar thing using flashcards. It was called a zettelkasten.
I have recently switched all my note-taking and task/todo management to org-mode, but I'm still figuring out how to use it properly. At the moment, I just have a personal.org, refile.org and project specific .org files, all kinda taking the shape of headings with sub-sub-sub-sub-headings inside until there is either none or some content inside, but a personal wiki, it doesn't feel like. It feels more like ordered mess, kinda. It's definitely better than anything I've ever used before.
Any good tips you want to share?
org-mode is a bit like C++ or LaTeX. I say this as a good thing. It has tons of features, but you need to choose what to use and what to keep out.
For me, something that works great is to keep all org files in the same folder, with a flat structure. That includes my task list and my calendar. I version control everything, except organizational things that change often instead of growing like articles. I also keep out of version control first quick drafts of any article.
The standard Emacs function for prompting for data with autocomplete is completing-read. You could build an elisp function that prompts for the name of a wiki file with completing-read, and then visits it. The autocompletion will be provided by whatever package you have configured globally - be it Helm, or Ivy, or something else.
A quick example how I started using this feature - I have my half-done invoicing system (for turning time clocked on org-mode tasks into PDF invoices). An entry point to invoicing a customer may look like this:
(defun invoice-customer (customer-name)
(interactive (customers--completing-read-customer))
;; TODO Create an org document containing the invoice table and link.
(message "Invoicing %s" customer-name))
Note that the "interactive" declaration has a function call in it. Now the completing-read call: (defun customers--completing-read-customer ()
"To be used as a value of `INTERACTIVE' declaration for functions that need to read a customer value."
(list (completing-read "Customer: " (mapcar #'car *customers/customers*) nil t nil nil *customers/current-customer*)))
There's a bunch of parameters to completing-read, but at a glance you can see the prompt ("Customer: "), code generating a list of entries (I'm doing a mapcar over customer database; you might want to do a mapcar over a call to directory-files), and an optional default value.Or, instead of all that, you can do what I actually do for the wiki - bookmark the wiki folder itself (with C-x r m in a dired buffer), and use C-x r b foldername to jump to it, and use incremental search in the resulting dired buffer to find the entry you need.
Knowledge pays compound interest: the more you know, the easier it is to learn new stuff (more branches on the semantic tree). Just jotting down simple unconnected facts and organizing them later has helped me become a much competent person.
I'm thinking about publishing a subset of it, but at this point it's one big mix of general knowledge and pretty personal stuff.
Also some other wikis have similar principles, for example: https://tiddlywiki.com/static/Philosophy%2520of%2520Tiddlers...
https://takingnotenow.blogspot.com/2007/12/luhmanns-zettelka...
https://takingnotenow.blogspot.com/2016/09/luhmanns-zettelka...
https://takingnotenow.blogspot.com/2016/08/my-translations-o...
And, just for quick reference, his entire 'zettelkasten' tag:
https://takingnotenow.blogspot.com/search/label/Zettelkasten