I'm regretting I didn't collect my thoughts like this earlier in my career. I personally learned and internalized many principles but by the time I was tech leading and mentoring, they had all fallen to the level of intuition and I couldn't clearly explain the "why"s of things.
George Polya (excuse spelling) wrote book called How To Solve It, it teaches heuristic methods in mainly mathematical problem solving, but the real value comes from whem someone, somewhat rigorously walks you through methods you implicitly know and use.
Anyone feeling honest resonance with your words should read the book. I can't put it in other words.
It's a great book (I'm just about to finish it). But let's not forget that the goal is to internalize problem-solving heuristics so that you use them intuitively.
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.
The hard part of this is that most companies aren't willing to support it (monetarily). You're expected to spend most of your time coding or, at best, thinking about the next problem. Thoughtul reflection rarely gets the support it ought to.
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.
It's also such a good book for mentoring and teaching. It's really important to internalize the difference between giving someone the answer and giving someone the tools to find the answer.
Yes. And the book goes even deeper, discussing the "how" of giving tools - how to give them while preserving interest, sense of achievement, and maximizing the amount of discovery the student is doing themselves.
That's a personal wiki. I think it's invaluable, and since I started building mine with org-mode I feel much more accomplished. That's because some tasks' natural outcome is a knowledge bit, which you can't store otherwise.
In the old times, many Germanic scholars would build a similar thing using flashcards. It was called a zettelkasten.
There's a blog by a (German?) scholar that covers all kinds of Zettelkastens extensively. Apparently the author is heavily inspired by the method of the german sociologist Niklas Luhmann:
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.
That's not an easy question. I think you need to enforce some style guide, like Wikipedia does.
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.
It’s nice to have a personal man page folder on different subjects. I personally use a binding in Emacs to bring up a helm buffer to select it quickly. Also, a tab completion function tied to an alias for it called “mm” so you can access it from the command line too is useful.
I don't think you really need Helm explicitly for this (though you could make use of it if you're using it for other things).
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.
I built mine with... Google Docs because I wanted something simple that was accessible with all my devices.
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.
