Shortening the Learning Curve When Learning to "Code" with Flex: "Visualizing Memory": What's Really Happening in RAM as You Program.

I have recently joined the ranks of FLEX programmers. While attending Adobe RIA meetings, and researching various books about learning to program Flex, it appears that a problem exists in learning Flex programming: the current books and articles "do not" help "rookie" programmers visualize what the code is actually "doing" in memory. Many outstanding books and articles exist that demonstrate how to code Flex, but not many illustrate what the code is doing in memory. And this fact is important when learning to program.

While struggling to learn how to program Java, I discovered what many experienced programmers probably already know: If you can visualize what the code is creating in memory, and can diagram this "code-memory" interaction, the learning curve of a beginning programmer is greatly shortened. Personally, I discovered this visual-interaction coding style mainly because of the methods I used when teaching high-school students to write the traditional "Five-Paragraph Essay" , as-well-as other forms of "English Code."

Before becoming a librarian at a university, I previously, I taught high-school English for five years. While teaching high-school students to write so their essays and research papers had a proper "flow of ideas", from the beginning to the end of their paper, I discovered that this "flow" was more easily learned if I actually wrote an example "Five-Paragraph Essay" on the board... by using colored chalk to lead from the "thesis/opinion sentence" to the supporting ideas and to the conclusion paragraph,etc. By tracing the "idea flows" occurring in the paper, the students could actually "see" if the ideas had the correct sequential flow, or , if any idea flow existed.

It dawned on me early one morning, about 4:00 am, that I was having difficulty "seeing" what was occuringing in RAM...that I had no visual conception of how my Java program interpreted: int score = 23; ... into: Your score is 23...via the println statement of: System.out.println("Your score is " + score). By drawing a memory chart alongside my code (with colored markers) I was able to "see" exactly what the program was doing. When I leaned how to use objects, especially array objects, this visualization technique was very useful.

Inexperienced programmers and writers both seem to share common dilemas: 1) New vocabulary words must be learned; 2) The process of "stringing" the new vocabulary words into a new "syntax" must be learned; 3) The process of combining the new vocabulary and the new syntax into an application or document "that accomplishes something" must be learned; other similar dilemas exist. However, in programming Flex or Java, my biggest hurdle involved "visual comprehension" of what is actully happening in the memory via the code. Just like many writers can piece together a pretty sentence, many coders can write syntactical code...that doesn't "FLOW" very well. I had no "Flow Control."

The biggest obstacle in coding for "rookie programmers", or for writers, I believe, is "seeing and visualizing"how the code works in memory. In programming, the coder cannot get "away" with "any" errors in syntax, semantics, or logic; in reality, neither can the writer. While programming is the structuring of sequential logic, where one line of code leads to the next, and then to the next, and so on, so is the writing of a document in English; ideas lead to other ideas, which can then be traced back to ideas...and etc.

                           [TO BE CONTINUED] LK
Community content is available under CC-BY-SA unless otherwise noted.