Code + Ed

conferences
Author

Amelia McNamara

Published

July 22, 2014

Last month, I had the opportunity to attend the eyeo festival as a student volunteer. For me, one of the most useful parts of the festival was the Code+ed Summit, which took place on the day before the official conference opening.

This was the second annual meeting of the summit (which I also attended last year) and it’s organized as an un-conference/wiki-style conference, meaning that there’s no set schedule when you arrive. Instead, the participants build the schedule as they arrive, writing down topics they want to talk about themselves or things they’d like to hear others discuss.

Here’s what the board looked like when we arrived: Blank whiteboard

What the board looked like when we showed up. (Shoutout to the awesome Intermedia Arts space!)

You can see that there are a number of different physical spaces available at all times, with sizes that accommodate from 10 people to “a lot.” The time is broken into four sessions, two before and two after lunch. I didn’t get a shot of the full schedule, but here’s what it looked like as people started arriving and filling it up.

Filling it in

As people started filling in the board.

This shot isn’t much better, but maybe you have an OCR algorithm that can catch all the names:

Tega Brain started a collaborative “hackpad” (hadn’t heard of this site before) so people could contribute notes, and those are available here. Uncharacteristically, I wasn’t taking good notes or tweeting during the summit, I think because I was so engaged in the material! With that said, here are some of my takeaways, in what I think is chronological order. If you want to know more about the summit, I really recommend the hackpad. There are many differing perspectives there!

Big data and data science for beginners

During the first session, Jer Thorpe, Golan Levin and I led a session on teaching big data and data science to beginners.

We were talking about the skills that beginners really need. Do they need to understand SQL? Web scraping? Complex joins? Spinning up Amazon EC2 instances? I don’t know if we got all the way to this in the discussion, but I think these questions really point to a need for a second course. Do whatever you want in the first course (I don’t even think it needs to be the “easy” stuff, as long as it’s interesting) and resolve to cover the other stuff in the next one. This takes the pressure off fitting it all in!

I believe this was the session in which we were talking about responsible web scrapers. Sometimes, scraping looks like “hacking,” especially if you’re someone who doesn’t know much about hacking. To alleviate this tension, someone (probably Jer) has his students include some text with their scaper, saying something like “we’re students in Jer Thorpe’s data art class. If you want to know what we’re doing with your data, feel free to contact us at this email address.” This simple act can change the way people view the scraper, and afterward they got overwhelmingly positive responses.

From my experience, if you’re going to teach “data science” to beginners, you need to make sure that the vocabulary that you’re teaching is very limited. Obviously, this can expand as the students gain experience, but it’s crucial not to overwhelm them at first. I got a laugh with something like, “we’ve been very specific about the syntaxes we use with the students. Syntaxii? Syntaxonomies?” (Pretty sure it’s “syntaxes”)

New medium for education

I didn’t totally know what this theme meant, but we certainly had some interesting discussions. The two I remember most distinctly were focused on the iPad.

I mentioned the “navigate/drive” strategy that is often useful when people are learning at the computer, especially if equipment is limited. One person (the navigator) is more of the thinker, deciding what the pair should be doing. The other (the driver) actually has their hands on the keyboard/mouse. After a set period of time, participants switch roles. This can be a bit freeing, because the driver doesn’t need to be focusing on the strategy as much, just the technical difficulties, and the navigator doesn’t get caught up in syntax issues. However, it takes a certain type of person to enjoy this breakdown. Personally, I know that when I’m talking about computer tasks with someone (often a student) I am just itching to get my hands on the keyboard. However, it’s definitely a better pedagogical strategy to have them do it themselves!

In the same vein, one participant in the “new medium” discussion said that his significant other, who is a teacher, uses an iPad in her elementary school classroom. At any given time, one student is chosen as “The Finger,” which means that they are the one who gets to touch the iPad. This is a fun role for the person who gets to be The Finger, and it really focuses the attention of the class.

Another participant had worked with one of the Federal executive departments, and was on a team that had something to do with daily briefings of top officials*. Typically, these briefs are created as pdfs and distributed as printed documents. But, a much more engaging way to display the information is to have an iPad app so that the official can ask questions and be shown answers on-the-fly. This department changed their briefing to iPads, with the option to still receive paper briefings if the officials preferred that. One particular official* is very tech savvy and loves the iPad, but was not being briefed on the iPad. When they investigated, the department learned that it wasn’t the official’s preference, but rather the briefer’s. With a paper report, both official and briefer can have a copy of the brief, and the briefer can keep a respectful distance from the official. The iPad requires a much more intimate connection, both heads bent over the iPad, manipulating the screen. It came out that the briefer felt this was disrespectful to the official.

I thought this was an interesting intersection of culture and technology. From friends who work with the US Army, I understand that it’s engrained in army culture for a presenter to provide paper copies of presentation slides (e.g. PowerPoint) and pay attention to the most senior official in the room. When they turn the page on their document, everyone else turns the page, and the presenter is expected to move on to the next slide. The iPad example similarly comes from a desire for the official to retain their power, rather than giving the briefer the same (or more) agency. However, it’s not just culture– the iPad (or the app) could have been programmed to allow two devices to sync, so that the briefer could maintain a respectful distance but still “drive” the briefing.

* I know the names of the department and the official, just trying to maintain some modicum of anonymity

Language and teaching

The biggest takeaway I got from this session was the importance of concreteness, both in terms of language and in terms of making tangible representations. The woman who made this point was from IDEO, and was talking more specifically about design meetings. She said that in her experience, you can talk about “a pen” but it’s always better to talk about “this pen.” This reminds me of Megan Erin Miller’s tactile design kit. This is a free (!) printable download that allows you to do web design using physical pieces. I saw Megan speak about this at eyeo 2013, and I was impressed with all the creativity-enhancing limits it places. For example, you can clearly see when things won’t all fit on a particular page, or when your buttons will overflow without some sort of collapsing menu. It would be fun to make something similar for statistics education, or even just use this same concept when planning computational projects.

We also spent some time talking about the difference between a prototype and a provocation. I think the difference is that a prototype is a proof of concept of something you could actually make. A provocation is something more conceptual, that you wouldn’t actually put into production. But, having it (again, physically) in front of a group can stimulate good conversation that wouldn’t happen otherwise. When you create provocations, you can make many very different iterations, instead of the many similar iterations that you might create as prototypes. Again, this is something I’m trying to bring into my own work. Instead of trying to conceptualize prototypes, I want to think more in terms of provocations.

Teaching coding in high school

We talked about “what doesn’t work” for quite a while in this session. I think this was a cathartic thing to do (there’s a lot that doesn’t work) but it probably would have been more useful to talk about what did work. Luckily, we did transition there eventually.

I was glad to hear that most schools are moving away from things like Java and C++ towards simpler scripting languages, at least outside of AP Computer Science. Several people in the session were teaching Processing (even in high school geometry), and I also heard mention of JavaScript. I mostly teach high school teachers, and (of course) I’m teaching them R within RStudio.

We all seemed to agree that for effective computer science teaching, you need to find a balance between open-endedness and unpreparedness. It’s important to know that the problem can be solved, or that there’s something interesting there, but you don’t want to have come up with “the answer,” otherwise it won’t feel creative and interesting to students. We all also agreed that finding these interesting prompts is pretty tricky. One successful coding exercise that a teacher set was creating a “choose your own adventure” narrative using HTML pages. Students could make the narrative as complicated or as simple as they wanted, so it scaled well, and they could customize to their interests. The teacher who told this anecdote admitted that his example story was pretty simple and uninteresting, but that his students really ran with it.

I was talking about the “recipe” idea that I’ve seen come up in some research on teaching/learning Java. Greenfoot (a learning environment for Java) uses the philosophy that students should never start with a blank page. Instead, they should be able to modify one line and then run something and have a result. This is like a recipe. “Starting from a blank screen requires design, and is an advanced exercise. It is something students encounter later, but not as the first contact” (Michael Kölling).

Another universal is that humans tend to view any change as bad change. So, if you’re going to show a few different tools you really need to scaffold the transition. It needs to seem like, “oh, we’ve reached the edge of the capabilities of this tool. I really wish we could do [X]” and then give them the tool to do [X]. But, you need to build up. If the new tool can’t do the things that the old tool could, it’s going to feel like a downgrade. A teacher gave the example of starting with Processing and then trying to sell students on R. As you might expect, that transition didn’t feel good to the students. Similarly, I’ve found that people will complain about any tool you give them, but if you try to change it they will complain! Similarly, any time the interface to a social networking site changes, all you see are complaints. Humans hate change!

The pitch

Once again, the Code+ed summit gave me tons of inspiration for my teaching practice and dissertation. I love the eyeo festival, but I think I get more actionable ideas from the summit. If I haven’t already made the pitch to you, allow me to do it now: the summit has been free to attend so far, and you can register separately from the eyeo festival. The eyeo festival sells out within minutes every year, but the Code+ed summit fills at a more civilized rate. And, there are often a few people who don’t show up, so you can also test your luck by just showing up at Intermedia Arts on the day of the summit and asking if they have space.

And the best part is because it’s an unconference, you can make sure that it fits your interests. People have asked me, “was there a session on [X]?” and even if the answer is no, there could be next year! It’s a very casual event, and great for networking. If you work anywhere in the space of education and computation, I recommend attending!

P.S., it was only as I was writing this post that I noticed that the name “Code+ed” can be read as “Code and Education” or “coded” (which itself has two meanings; either programmed or as in “coded language”). Nice job with the naming, organizers!