FI Learning

For learning with practice. Posts are not private and could end up on Bing.

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.
Elliot, Fallible Ideas +1

Comments & Events

Justin Mallone
I also realized that working on the problems before getting more understanding of the procedures introduced in the chapter was putting the cart before the horse. I made a list of some things to try to make progress:

  • Figure out what the domain and range are for each procedure the chapter introduces in talking about trees and the world-tree
  • Give each procedure an argument, observe the output, and describe what's happening
  • Analyze the procedures involved in the infix expression parser in detail
Justin Mallone
I had a thought related that seems related to my earlier thoughts on working on stuff that's too complicated: If you can't do something with high reliability and low attention that's a sign you might fail. You should be especially careful you're already trying to back off and do something easier and you still require full attention to try to do something. If you're trying to back off, the easier steps you're trying to accomplish shouldn't be hard. I think part of the reason is there is still going to be a hard step when you're trying to integrate some new understanding arising from the easier subparts you're working on, so the sub parts should be actually easy. Let me try to talk about an example.

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.
Justin Mallone
I tried making a tree where I zoomed in to a bunch of detail on a particular branch. I think this is related to my OP, cuz I think not immediately realizing how much you can "zoom in" and break a harder goal down into easier parts is related to this problem of defaulting to working on stuff that's too hard.
Elliot, Fallible Ideas
Some good thoughts and tree. Some writing issues but it's a good start on thinking about this.
Elliot, Fallible Ideas
BTW I think your biggest issue with FI stuff is not practicing stuff enough (with some exceptions like grammar and coding).
Justin Mallone I agree
Justin Mallone
I had another thought about this issue. I think defaulting to working on stuff that's too complicated partially stems from not seeing the connection between working on an easier thing and and making progress on a harder thing.

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.
Elliot, Fallible Ideas
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. and they aren't just hopefully relevant things, they are things in the pyramid that built up to the current thing, so they are relevant b/c you're actually using them for the bigger, harder thing.

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.
Justin Mallone 👍
Justin Mallone
Another thought on this problem:

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).
Anne B 👍
Justin Mallone
Another issue related to this problem: trying to partially copy or imitate a solution to some problem that's related to the problem you're working on, and copying over material that's suited for the complexity level of that solution, but unsuited for you gradually building up your own understanding
Justin Mallone
I thought about it and realized that my simpler tree that I made with 6 nodes and 3 levels should actually have 5 nodes and 2 levels 
Justin Mallone
Elliot said:

> 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.
Elliot, Fallible Ideas
one reason to look 1-5 levels back is it's hard to get more than around 5 levels past a mistake. you end up getting stuck a limited number of levels after a relevant mistake. it gets in the way of unlimited progress but usually still allows going a bit past it (which makes it harder to figure out where the problem is).

there are exceptions but this is typical.
Elliot, Fallible Ideas
(also the number depends on how thin or thick the levels are. you could divide the same stuff into different numbers of levels. so 1-5 is an estimate assuming reasonably culturally-typical amount of stuff per level. if you make a super detailed tree with more levels, that's fine, just change the 5 to a 10 or 20 depending how extra-detailed you do it.)
Justin Mallone
Learning mode versus professional mode

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.
Justin Mallone
I was trying to make a program to parse
(* (+ 4 3) 2) 
which seemed pretty simple. But then I realized I should start with parsing
(+ 4 3)
Justin Mallone
I decided maybe the Simply Scheme material I was working on was itself too complicated, so I'm trying out The Little Schemer