While trying to implement closures for my programming language, I got stuck. I'm loosely following the book Crafting Interpreters, but my language has a different syntax and I'm using TypeScript, so my implementation is quite different. The book shows you all of the code, but I usually have to read the code, understand the code, and then implement it in a way that makes sense for my language.
This was a problem for closures. The code was too spread out to hold in my head, and I didn't understand why some of it was necessary. I got in an endless loop of reading the same code every evening, hoping it will eventually click.
This went on for /eight days/, which took all the momentum out of the project, and I finally had to admit that I was stuck in a research loop. They look like this:
I've found (so far) three techniques that help me break these loops:
Nothing makes you understand something like actually doing it, even if you only half understand it. Sometimes you have to accept that, stop reading, and start doing.
For me, this was writing a bad, unfinished, non-functional implementation of closures. I threw it away the day after I wrote it, but I got a deeper understanding of the problem.
An implementation intention is like this: "In situation X, I will do Y", as opposed to a goal intention, which is "I want to do Z". The intention "I want to implement closures" is a goal intention, whereas "after dinner, I will read article X about closures and summarise it in my own words" is an implementation intention. The goal is still the same, but now there's a specific action to take that has defined start and end points.
I'm stuck on something I'll open the same half dozen things over and over again in the hope that today I'm smarter and will somehow understand them. Implementation intentions help to structure this, letting me focus on one specific thing. Plus it feels good to decide to do something and then achieve it, no matter how small.
This is the most drastic, but sometimes it's the only way. This is taking one example and bashing your head against it until you understand it. I usually do this by taking something apart into small chunks that seem understandable, then writing up lots of notes while I try and join all those bits together.
For me, this was taking the closure code I didn't understand, opening a notepad, and manually "running it". I stepped through it line by line, keeping track of the variables and any other important state, and eventually I understood why every line of code was there.
gate
2020-08-23