Poster Abstract and Code Camp

It’s been a tad quiet on the blog front over the past couple weeks. Here is what the Praxis squad has been up to.

It’s been a great week for collaborative writing. We put together a poster abstract for DH 2013 that crystallized a lot of our thoughts on Prism and crowdsourcing thus far. Perhaps we will see some of our loyal readers there? The poster abstract that we put together discusses crowdsourcing as a continuum from more mechanical interaction to forms that maintain more of a sense of the autonomous individual. We concluded by conceiving of a few different types of interfaces for Prism and the ways in which they might affect the nature of the crowdsourcing process. Much of the abstract was put together with multiple people writing different parts of the document at the same time, which I thought was an interesting enactment of the sorts of questions and issues that we have been working through. It was great to see each person’s piece combined into the whole. Special shout-out to Gwen for taking the lead on the abstract coordination/writing and to Jeremy for his expert wisdom.

Part of the reason for radio silence has been a distinct shift in our day to day work. After finishing the poster abstract, Wayne and company started hitting us hard and fast with code boot camp. So far we’ve dipped into command line, git, and ruby on rails. Things are going pretty well so far - it feels a little like taking a giant cyber-multivitamin as we prepare to put all of our plans for Prism into action in the next few months. When asked to explain git and version control, I like to do so by comparing it to time travel without the risk of creating a universe collapsing paradox. For next week we are moving through the first ten exercises of Learn Ruby the Hard Way. The idea is that you type out letter for letter a series of code, trouble shoot if it doesn’t run, and then reflect back on what you wrote. This seems a bit unusual - I would expect a more traditional format to teach you the concept first and then enact the code yourself. The LRTHW model works great for my personality type: I always have a hard time with training of any sort. Invariably in any new employee training, my attention immediately starts to wander as soon as my superior starts to explain something to me, and I always wind up learning by doing. So this reversed pedagogical model works well for me: I do first and then think back on the process. I can imagine it being very frustrating, though, if you are the kind of student that dutifully pays attention to the lesson on view.

It’s an interesting model, and I wonder if it could be adapted for the humanities. What might that entail? Maybe I could have my students type out an essay paragraph word for word and then reflect on it after the fact. Would the model still work, or is there something about humanities thinking that requires that the thinking/learning precede the doing?