[Noisebridge-discuss] Analysing and Interpreting Quantitative Eye-Tracking Data in Studies of Programming: Phases of Debugging with Multiple Representations

[Naomi Most]

Yeah, that's interesting.
Just to recapitulate my part of the discussion of programming phenomenology:

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.

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.

Why this is relevant to text versus visual tools:

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.

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.

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.

--Naomi

ps. the irony of the use of the word "manipulate", rooted in the word
"hand", is not lost on me.




On Sun, Aug 30, 2009 at 9:26 PM, Jason Dusek <jason.dusek at gmail.com> wrote:

>  This paper echoes a notion that came out of a discussion Naomi
>  and I had after I mentioned some comments Meryl made in my
>  Ruby class. The authors say:
>
>    Overall, throughout the whole debugging session expert
>    programmers – who also found more bugs – relied more on the
>    textual representation of the program than the less
>    experienced programmers did. Output of the program became
>    more important than visualization at later phases of the
>    debugging strategies of experts, while novice programmers
>    tended to rely on the visualization.
>
>  The accompanying graph (page 8 of 15) shows us that, while
>  novices spend substantially more time looking at the visual
>  representation, both groups spend most of their time looking
>  at the code.
>
>  This dovetails well with my changing experience of program
>  development: I came to care less and less for visual tools and
>  code visualization as I become more comfortable with just
>  building the model for myself.
>
>  Perhaps our visual tools are simply inadequate and successful
>  programmers are those who can adapt to the paucity of tools;
>  or perhaps the mentality required for programming is little
>  aided by visuals. I tend to think the latter but the research
>  can be read either way.
>
> --
> Jason Dusek
>
> http://www.ppig.org/papers/19th-Bednarik.pdf
>



-- 
---
Naomi Most
Producer
Little Moving Pictures

+1-415-728-7490
naomi at littlemovingpictures.com
skype: nthmost

http://twitter.com/nthmost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.noisebridge.net/pipermail/noisebridge-discuss/attachments/20090901/1dc3c1e8/attachment-0002.html>