Mistakenly defaulting to working on something too complicated
I was trying to figure out a problem in Simply Scheme. I defaulted to using a data set that consisted of a tree with 44 nodes in order to figure it out. After a while I realized that was a mistake and that I should use a simpler example, so I made my own data set with 6 nodes. I made progress using this example.
It's good that I noticed that I made a mistake, but defaulting to working on a data set that was too complicated was itself a mistake that wasted some time. My current theory is that at least a part of what caused this mistake was insufficient consideration given to the question "What would be an appropriate level of complexity of tree for me to be working on right now?" So I'm going to try to think about that sort of question in a more conscious way and look for opportunities to ask it.
It's good that I noticed that I made a mistake, but defaulting to working on a data set that was too complicated was itself a mistake that wasted some time. My current theory is that at least a part of what caused this mistake was insufficient consideration given to the question "What would be an appropriate level of complexity of tree for me to be working on right now?" So I'm going to try to think about that sort of question in a more conscious way and look for opportunities to ask it.
+1
If you're trying to understand a complicated program, then describing how the subprocedures of the program work shouldn't be hard. Even after you've done that step of describing the subprocedures, you'll still have to integrate that information into a new understanding of how the whole procedure works, how data flows through the program, and so on. That's going to be somewhat hard for you. So if even understanding the subprocedures is hard, that's not good.
A frequent pattern is something like this:
1. Take ten small, basic steps that are hopefully relevant to some problem.
2. These steps result in some realization about the problem.
3. The realization lets me solve something I was stuck on regarding the problem.
Before taking step 1, I don't know what the realization will be in step 2, because I haven't had it yet. I think maybe I have some misconception here, because working "directly" on the problem (even if in an ineffective way) somehow seems comparatively better than taking the ten small steps and hoping that that process somehow results in a useful realization. There's a lack of confidence in the process or something.
There's a chance that some set of ten basic steps might fail. There's no guarantee. But working "directly" on a problem ineffectively has a high failure rate. It's a strategy with low expected returns. But that idea doesn't come readily to mind sometimes or something. Hmm.
in other words, if you have trouble, break it into parts and get better at the parts instead of trying to tackle the whole problem at once. (prioritize whichever parts first that you think your'e worst at or suspect might contain an error). and the breaking it into parts shouldn't really be making up new parts. you already got to the big thing by building it out of parts. so preferably instead of coming up with some possible division into parts, you should divide it back into the same parts you made it from. if you do parts that way, it'll be clearer how they're relevant.
Ask the question: "Could this example be simpler?"
Consciously try to use the simplest example possible as a default. Make using a more complex example the thing that needs a reason (e.g. to test that your solution will work in a more complicated case), rather than using a simpler example being the thing that needs a reason (cuz you e.g. failed with a more complicated example and want to try a simpler one now).
> in general, if something is hard, the most directly effective thing to do is examine your premises 1-5 layers below it that built up to it. usually it's hard due to an error in there, and if you improve at those prerequisites/building-blocks it'll get easier.
I went back maybe one layer in Simply Scheme, and reviewed the previous chapter, and realized I'd forgotten some of the material from that, and that some material was not immediately intuitive. So I made flash cards to try to work on that a bit.
there are exceptions but this is typical.
I think another thing related to this issue may be having different modes of approaching problems.
I think roughly that I have a learning mode where I often try to take on too much complexity at once, and a professional mode in which I proceed in a more systematic and step-by-step manner to solve problems and am more honest about when something is beyond my skills.