John Fairbairn wrote:
I'll try one last tack. What I am arguing for is that, to learn something from doing tactical problems, the most efficient kind of practice is effortful and rich in associations. Trying to solve a problem in your head is part of the effort, I agree, but you can add to the effort by playing the moves out on a board. This gives you the flow (suji) of the stones and creates associations.
I'm with you on this. In my last post I made a short remark that replaying the moves on a physical board adds experiences (ie possible associations) but what remains is the question of efficiency (let alone practicability). More on that later in this post.
John Fairbairn wrote:
The exact method you adopt can be totally different from what I'm proposing but I don't see that efficient learning can be achieved unless your choice of method guarantees extra such as associations and flow. Mere repetition of problems that you've solved before but can't now remember is even more boring than - and actually more similar to -tracing your own steps in the sand.
Agreement with the first sentence. For the second sentence: There is some nuance. Repetition (especially spaced-repetition) is really powerful to remember stuff and for remembering facts I don't know any method more efficient (whether you enjoy this process might be personal preference?).
Now we really go full circle: The problem when learning go problems through repetition is that you have a visual (ie diagram). Since the brain does not take photographs, subconciously you will end up memorising only certain abstract elements of the visual. And here comes into play what (I guess?) Bill Spight refers to as key stones. If the way you remember the visual does not include the key stones, you can't likely claim understanding of the problem but just memorisation of this particular shape. To keep the imagine of the toolbox: You'll end up with an open-end wrench only useful for working on this problem. Been there, done that. (Anyone also reminded of the bias in maschine learning algorithms?)
So yes, (solution) diagrams might end up being a bad when you combine it with spaced-repetition. So how to proper engage with tsumegos to understand them instead of
just remember them?
John Fairbairn wrote:
All of these methods will add something further to your knowledge, but some methods are better than others. For example, scribbling in the margin is often close to useless, whereas scribbling the book's ideas in your own words - self-testing, in other words - tends to pay off big time. Your internalise the knowledge.
...and I believe the same is true for tsumegos. It's not revolutionary either as far as I know: Start making your own problems! "The asians" did that all along when I correctly remember my reading of various go exchange students' experiences.
You have various ways to turn that into practice: In a book you can pose problems the usual way but instead of
just given the answer on the next page you can ask the reader whether the problem would work with the same solution when you take away this or that stone. For more engagement, don't show a diagram with less (key) stones but instead ask the reader which stones they consider key for their solution to work. Now you can present the answer to both the initial problem and the key stones on the next page.
If you structure the problem book thematically you can end each chapter with a couple of empty diagrams encouraging the reader to make their own problems based on what they have seen and learnt about key stones (and ask them to upload them to your site for interaction with other players... not even discussing the business value behind this). Like this you still keep the entry level for engagement really low (even better: make an app), since no board or stones are needed (and no place to put them) and you can at least spark engagement, ie by given the reader the choice to immerse themself. I'd say this choice is better than designing a cumbersome solution and (more or less) forcing the reader to use "third party devices".