I'm using a similar method. Have a single goal for each day. That is the "commit" for the day. If you achieve it it's fine, if not just choose a new goal for the next day and try again.

Sometimes I don't achieve the goal but still choose a new goal for the next day. If time passes you learn something new or things change and your former goal is not important anymore. If the goal is on a list you still have to achieve it because it's on your list.

I think I get the sentiment of what you're saying, but I'm not sure what it would look in practice.

For example, how would that apply to learning a card game like Magic?

What did you do to learn Magic?

Magic is a complex game, but a game regardless. If you feel learning is overwhelming, just play.

The big issue with Magic (for me) is planning how to spend all my mana, calculating which cards to play in which order, and then--I forget. The entire thinking dissipates into thin air!

This after taking 15 minutes for a turn really convinced me I need to train my brain to handle stacks and to memorize the cards.

Even a spreadsheet where I can input mana pool and current hand (click, click, click to select), which generates what can be done (maximal allocation) would be neat (for non-tournament play).

Hm, so for that, I think find the "process loop." That is, the equivalent of the edit-compile-test cycle for Magic.

For example, first choose your domain scope: a thematic deck, super-crunchy probabilities, or studying a pro former deck?

And then create a deck. That's the edit step.

From here, try shuffling and drawing different initial hands. This could also be done in a program, so it could be a good chance to code something.

Finally, some way to test the deck by playing online.

Iterate by repeating the cycle, refining the steps, and so on.

Interesting, thank you for that.

What are your thoughts on documentation separate from the activity itself? Do you see it as something useful, or how do you go about approaching that?

It's easiest to document alongside the activity, or keep a journal. Otherwise, it may never get done.

At least with code, the commit and docs let me repeat info twice, but not a straight copy-paste. The commit lets me discuss why vs how and technical details; the docs answer things like

* I forgot everything; how do I onboard myself?

* Common tasks

* Troubleshooting

Preferences vary. I just know I'll forget if I'm not writing it down in the moment.