I heard a story once about a math teacher that always taught their students using hand-eye models instead of just visualization.� For example, when teaching simple derivatives, they would use their hand to grab the exponent and drag it down to the multiplier positions, and ask their students to go through the same motions.� The reasoning (however apocryphal it may or may not be) was that the hands and fingers had a lot of circuitry built in for the detailed oriented repeated skills like programming / knitting / making food / solving equations / solving video games.� Come to think of it, maybe I'll try a kinesthetic approach to teaching in whatever my next workshop is...� At any rate, maybe you are both right! :)<br>
<br>On an unrelated note, another toy I would love to have at noisebridge is a eye tracking rig.....<br><br><br><div class="gmail_quote">On Tue, Sep 1, 2009 at 12:54 AM, Naomi Most <span dir="ltr"><<a href="mailto:pnaomi@gmail.com">pnaomi@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Yeah, that's interesting.<div><br></div><div>Just to recapitulate my part of the discussion of programming phenomenology:<br>
<div><br></div><div>I posit that the physical act of programming involves holding mental frameworks and objects with their attendant potentialities all in mind. �Most programmers I know, including myself, can attest to a "set-up" time before actually producing new code of any worth that is directly proportionate to the size of the project and existing codebase. �</div>
<div><br></div><div>This is the sort of set-up that happens when you've stepped away from a project long enough that you've had to load other complex state in the meantime (e.g. negotiating dinner with significant other). So, when you come back to it,�smaller projects might set you back 5 minutes of set-up time in your brain, whereas larger projects might require an hour or more.</div>
<div><br></div><div>Why this is relevant to text versus visual tools:</div><div><br></div><div>Visual tools seem to attempt to provide the sort of representation that happens in the brain during the practice of programming. �In the beginning stages, they do seem to help; in later stages (and not very far down the line) they seem to become a hindrance, making more aspects of the model obtuse rather than easier to mentally manipulate.�</div>
<div><br></div><div>At some point, your brain just becomes way better as a tool of model state-holding and manipulation than the visual tool, and you fall back on the text to provide you with pure input and output for the models and frames in your mind.</div>
<div><br></div><div>To give a somewhat politically incorrect analogy, visual tools can get you about as far with programming as an autistic brain can get you in peaceful negotiations of dinner.</div><div><br></div><div>--Naomi</div>
<div><br></div><div>ps. the irony of the use of the word "manipulate", rooted in the word "hand", is not lost on me.</div><div><br></div><div><br></div><div><div><div></div><div class="h5"><br><br><div class="gmail_quote">
On Sun, Aug 30, 2009 at 9:26 PM, Jason Dusek <span dir="ltr"><<a href="mailto:jason.dusek@gmail.com" target="_blank">jason.dusek@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> �This paper echoes a notion that came out of a discussion Naomi<br>
�and I had after I mentioned some comments Meryl made in my<br>
�Ruby class. The authors say:<br>
<br>
� �Overall, throughout the whole debugging session expert<br>
� �programmers � who also found more bugs � relied more on the<br>
� �textual representation of the program than the less<br>
� �experienced programmers did. Output of the program became<br>
� �more important than visualization at later phases of the<br>
� �debugging strategies of experts, while novice programmers<br>
� �tended to rely on the visualization.<br>
<br>
�The accompanying graph (page 8 of 15) shows us that, while<br>
�novices spend substantially more time looking at the visual<br>
�representation, both groups spend most of their time looking<br>
�at the code.<br>
<br>
�This dovetails well with my changing experience of program<br>
�development: I came to care less and less for visual tools and<br>
�code visualization as I become more comfortable with just<br>
�building the model for myself.<br>
<br>
�Perhaps our visual tools are simply inadequate and successful<br>
�programmers are those who can adapt to the paucity of tools;<br>
�or perhaps the mentality required for programming is little<br>
�aided by visuals. I tend to think the latter but the research<br>
�can be read either way.<br>
<font color="#888888"><br>
--<br>
Jason Dusek<br>
<br>
<a href="http://www.ppig.org/papers/19th-Bednarik.pdf" target="_blank">http://www.ppig.org/papers/19th-Bednarik.pdf</a><br>
</font></blockquote></div><br><br clear="all"><br></div></div>-- <br>---<br>Naomi Most<br>Producer<br>Little Moving Pictures<br><br>+1-415-728-7490<br><a href="mailto:naomi@littlemovingpictures.com" target="_blank">naomi@littlemovingpictures.com</a><br>
skype: nthmost<br><br><a href="http://twitter.com/nthmost" target="_blank">http://twitter.com/nthmost</a><br>
</div></div>
<br>_______________________________________________<br>
Noisebridge-discuss mailing list<br>
<a href="mailto:Noisebridge-discuss@lists.noisebridge.net">Noisebridge-discuss@lists.noisebridge.net</a><br>
<a href="https://www.noisebridge.net/mailman/listinfo/noisebridge-discuss" target="_blank">https://www.noisebridge.net/mailman/listinfo/noisebridge-discuss</a><br>
<br></blockquote></div><br>