Trying a "lazy loading" style of adding cards

[badlydrawnrob]

See notes for Elm in Action

Every time you learn a new language, it adds "cognitive overhead" and can, potentially, muddy the waters of your knowledge pool¹. Learning more than one thing at a time can also lead to the context switching problem.

The bigger and more interconnected the code sample, the harder it is to distill down without losing context. At this point it could be easier to create individual files with a question->answer in mind, with a more complete interaction between functions etc.

• An example of notes taken and list of potential cards (cards not created yet)
• A revised list with grouped, numbered notes (cards to be created)
• A further example of grouping a longer, more complicated set of numbered notes (and how it was grouped).²
• An example file that's handy for seeing some learning points at-a-glance (or, just use the Elm Guide)

Understanding comes first!

Problem: Working in this way is slower as you can't zip through the book when you're carefully marking up your code with notes. By the end of the chapter, however, you'll have a (hopefully) nicely laid out file with helpful comments, and a set of learning points as a list to begin creating your cards in Anki (which will hopefully be far fewer and more focused).

Elm-in-action does a good job of summarising the learning points at the end of a chapter, but I've found once learned, skimming the book for reference is slower than having a set of notes with examples in-place.³

I'm trying a method where understanding comes first and the aim is not to memorise code only. It isn't an exercise in cramming with an Anki deck. This comes with a caveat that I'm already further down the learning path and not a beginner (in which there's a vast amount of syntax to remember).

I'm also taking care not to rush things and being ok with spending a whole learning session with, for instance, only understanding a single function (and understanding it well).

• Use comments to add notes or document code
• Add snapshots of diagrams from the book (not added to source control)
• Something new? Something difficult?
  • Write it down! (with no intention of adding cards yet)
• Revise the list (or snapshots)
  • How well do you remember?
• Then (and only then) decide which cards to create
  • Add images and code samples where appropriate

I'm also not interested in memorising every little detail in the Elm in Action book, but broad strokes which could be linked back to sections of the book, or further articles at a later date. Highlighting some sections of text in the book can be useful too. I don't care about the Javascript comparisons There's a lot of stuff about comparison with Javascript so can safely leave that out (unless it's similar concepts).

Where there's code that I've seen before:

You can safely ignore x, y, z

For instance, while HTML is not new to me, the Html module is. It's reasonably simple lists (an attribute list and a children list). Using functions within the HTML will need some examples.

1. Html and CSS I already know!
2. Lispy language a so-so grasp of; rely on memory for similar concepts.
3. New concepts will need to be written down somewhere.

Questions:

• You're highlighting sections in the ebook/pdf also. How useful were these?
  • I'm not sure how often I'll revisit the highlights in the ebook, but I think I've got the jist of the thinking (if not all the terminology) down in files or Anki cards.
• Is a syntax file, or a notes section a better way to scan for information than adding Anki cards?
  • In some cases, most definitely — for simple syntax and stuff to view at-a-glance.
  • I've got one version of the working file that's clean, with almost no notes.
  • I have another one with plenty of notes to fall back on if I don't understand what I see.
  • Use the tree to save files as a link for a specific commit.
• Which bits am I getting stuck on, or finding hard to remember?
  • You have your revised list (see above) for cards to add now,
  • You can revisit the code later to see what you remember. Do you really need a new card?
• Can I interleave different bits? (where some are question/answers; within those there's some contextual rejigging of the easier bits)
  • Interleaving similar themes with programming languages you've learned before,
  • Some things you'll remember through osmosis in future chapters, building things, or simply looking at a card with contextual code!

Also see:

• Using the Anki app (the good and the bad) #72

Footnotes

1. In terms of getting muddled up with this or that language; unless you're a polyglot and very good with languages, it's quite the thing to learn a new language, or framework. As you get older, you have to be extra careful with your time, so it becomes clear that weighing up the pros and cons of learning something new is essential. Lisp and Elm are far enough apart to not make mistakes, but Typescript, Javascript, React, Vue, etc, are easy for one to bleed into the other. ↩

2. This list is quite messy and there'll be duplicate points or stuff that can be mushed together. The chapter in the book wasn't overly long, but it had a lot of learning points for Types and other things like Maybe. Elm lang, and functional programming in general aren't what I'd call beginner reading material. Perhaps object-oriented or type-less programming languages like Python or HTDP's teachpacks are easier to wrap your head around (and therefore creating cards is easier). The main point is, as your learning becomes deeper or more involved and the programs become bigger and more intertwined, creating good Anki decks becomes a bit harder. Can some examples become part of an example program or small note book? Which learning points are a poor fit for card creation? ↩

3. Even these notes aren't foolproof and depend on how well you've written, or understood, the chapter. That's where documentation comes in to play as a shorthand for more verbose learning notes. Ideally you'd create your own documentation with memorable examples — but who has time for that? The downsides of documentation is it can be overly academic or assumes understanding of terminology. If you're anything like me, terminology is difficult to remember — i.e [the difference between an operand and an operator](https://www.lenovo.com/us/en/glossary/operand/#:~:text=What is the difference between operand and operator?). I know what each are in practice, but my memory of terminology can be muddy! (I just say variables and arguments.) ↩