occasionally, i have had to write code with an audience. i have long since known that it is not a strong part of my skill set to do this by improv. betty edwards, in her book, "drawing on the right side of the brain," argues for the philosophy of right-brained vs. left brained thinking. in computer science terms, left brained thinking is your sequential, logical side, which steps through things one piece at a time. right-brained thinking is your parallel processing side, which processes everything at once and just "sees" things. when i am writing a paper, i am using my left brain, since i am trying to logically anticipate the reader's response to each sentence i write. I want to write a sentence that makes them think about things the way i want them to so that what i am saying is clear. when i am drawing, i am using my right brain. there is almost no conscious thought. i play with what i see and just run with what's intuitive to make a picture. i have no idea what time has passed or what music i am listening to, if any.
when i first learned to code, i thought with my left brain. i thought through things one line at a time and made sure each line worked to say whatever it needed to say so that the computer could compile it into voltage differences that allow it to go do something useful with itself, if we hook up our circuits right. i eventually started to think of code with my right brain, however. i think of it now as a concise mathematical statement that needs to work on its own as a whole. each line is not separate; they intertwine together to make things say what they need to say as a concise entity.
when i talk to an audience, i am analytically watching their faces and listening to their tone of voice to see how they respond, and i adapt my level of detail and redundancy of statement based on their reactions. it's very left brained.
i am very bad at improvising code in front of a class. so i write my lecture notes, as everyone does. and then i rewrite them as i think about what questions students might ask. and i plan a couple lectures ahead to let things "gel" in the back of my mind, so that i have a better idea of how well they will work before presenting them. of course, smart students ask me questions that catch me off guard, which might head down the road of a different explanation but i steer things back to where i was going, regardless. not out of a sense of correctness, but because i know full well that if i head down another path, the right-brained/left-brained battle will stalemate and either my communication will break down or my solution will be wrong, or more likely, both will suffer. richard williams, in his book, "the animator's survival kit," shows a newby animator (the author) asking an experienced animator (milt kahl) if he listens to classical music while he works. turn the page. milt expands in size tenfold, and says "of all the sssstupid #@$#$@$#$ questions iiiiiiiv'e ever heard!!!! iiiiiiiiiiii never heard such a f$%$%#$%$#%$ stupid question!
i'm not smart enough to think of more than one thing at a time!!!" that's me writing code from scratch. that's also me communicating to an audience. and animating too. they don't mix and match at all well.
as to the music question, i sometimes have it on, but i usually have no idea what's playing; it's completely blanked out of my thinking. the only time i found music to be specifically useful was when animating some fire in one of these movie films that comes out every now and then. i had my fire animation, some reference footage, and the adjacent fire shots playing on screen together, with nin's "burn" on repeat. it worked, helping to get the feel of fire out of jos's discretization of the navier stokes equations. the emotional feel of the music and shot were different, but the emotional feel of the music and fire motion were the same. that's rarely the case.
i recently had the opportunity to improv code with an audience. i was way way off my game. i learned a lot from it though, in terms my personal limits. sometimes i really am only smart enough to do one thing at a time.
