Practice and verification of your understanding are not noticeable compared to information gathering or modeling. For example, if you write a program by trial and error, the final source code does not have an implementation that tried and did not work.
Let’s say you repeatedly experiment to produce something, and eventually succeed. When you announced achievements, you do not mention all of the experiments that did not work.
So, in the learning cycle, the existence of this verification phase tends to be ignored.
Thomas Alva Edison conducted tens of thousands of experiments before completing incandescence light bulbs and had a bad results. To reporters who expressed that as “failed a lot”, Edison said that “I have not failed. I’ve just found 10,000 ways that won’t work.”
It is the same also in programming. When you write the program and run it for the first time, the program may perform differently from your expectation with a high probability. Let’s focus on the gap between expectation and reality. Why does it behave differently from your expectation? Which part of the source code does behave as expected? Where does the behavior different from expectation start? Finding the answers to these questions, and fixing the source code over and over, the program finally works correctly.
I also do not show this trial and error process to other people very much, but at least I tried more than three times as much as the successful case I have published. I think that anyone trying to answer questions without textbooks is doing that.
In the metaphor of boxes, trials are behind the front boxes. You see only the front box, that is, the case the other finally succeeded. Looking at the activities of others, you might think that “Why did they come up with such a great idea? I do not come up with myself. They might be a genius.” It is because you see only the frontmost box.
