Archive for January, 2011

Educating the journo-programmer

Two New York-based journalist-teaching universities, NYU and Columbia, have launched programs to create what Justin Ellis calls “the journo-programmer.”

At NYU, my colleague and podcast partner, Mark Kelly, is leading the effort with Studio 20. Columbia hired Emily Bell from the Guardian to lead the Tow Center for Digital Journalism. I visited with Bell recently, at her office at https://www.yardcaregurus.com, and of course we talked largely about the journo-programmer.

My own interest in this area comes from the development of blogging, RSS, and podcasting software, and booting up the blogging activity at Harvard Law School in the early-mid part of the 2000s.

So.. what is a journo-programmer, and how does higher education create one? Or is it a god-given gift, and is our job merely to develop the talent where it already exists? Can you teach a programmer to be a writer, or a writer to be a programmer? It seems the first step is to ask people who have already made the journey. From both directions.

A quick story. I made a decision in late 1994 to dive into the web. The door was opened for me by the San Francisco newspaper strike. The writers, who were professional news people of the mid-90s, largely before the big change swept through their industry, were well-versed on the abilities of the web. My best teachers were the ones who understood and used linking. And made it very clear that we, the unpaid production staff, were not to lose a single link. Made an impression. The same kind of impression that reading the source of Unix made when I was a compsci grad student in the late 70s.

The importance of linking is comparable with procedures in programming languages. Imagine if every piece of code you wrote had to go all the way back to the beginning and define what it means to add two numbers. Same with writing. I don’t have to write the Nieman article because it has already been written and I can link to it.

In that sense the web is a prior-art machine. A way of sharing know-how. There’s another key, different concept. In the past, as a writer, it was easier to just reinvent than to reference earlier works. This came up in a Twitter exchange, where calixte said that WikiLeaks had liquified the press, turning it into a river. I love that. I think it’s very true. Assange basically said that. Please focus on the cables, he urges, but don’t miss that along the way I got the journos to work with each other. There’s the liquification. It’s one of the things you see very clearly through the lens of wikiriver.org. There’s a lot of duplication in the press, for sure, but there’s also a lot of linking and referencing.

How do we teach the journo-programmer? Don’t worry about how to do it, at first — just start doing it. When we started blogging at Harvard, our first few approaches failed. They wouldn’t have worked any better if we spent a year planning them. Better to try an approach, learn, get it out of the way, and come up with new approaches, until you find a way that works.

In most university departments there is permanent paid staff that manage the websites for the students and faculty. It seems to me, if your goal is to boot a new class of programmers and journalists, this activity should be brought into the curriculum, and every student should participate in managing and developing his or her own publishing infrastructure.

We’re not ready yet to teach how to do this, but a few semesters after the students start, we will have a very good idea of how to accelerate the process, produce more reliable results. And eventually we will be able to teach it alongside the other skills that make a programmer a programmer and a journalist a journalist.

We will also have a much better idea where existing tools are insufficient, which will lead us to the next phase where the students not only manage the infrastructure, they develop key parts of it. At NYU we learned we have students that are this ambitious with the Diaspora project.

Developing is not something to rush into expecting success from your first efforts. From the outside shipping useful software looks easy. It’s an illusion created by the ease-of-use of the resulting product. If the product is easy, the process of creating it must be too. When I say it that way you can see it’s not true. It would be like telling the parent of a wonderful 20-something that raising a child must be easy, because look at how pleasing the end result it. Never mind all the problems along the way, that becomes hidden. Same with software.

Okay that’s how a department at a university might approach it. But what if we let this problem liquify the individual campuses, the same way WikiLeaks is liquifying journalism. What if trying to go it alone is as un-Internet as trying to lock your users in, or not allowing off-site pointers. Well, we got a good start at this sharing process, in the mid-2000′s, when the goal was to bring blogging and podcasting to academia. We did a series of academic conferences that covered blogging from a variety of angles. We looked at how to help people start blogging (that must come first), how to bring new technology to blogging, and the beginnings of blogging as a cultural, political and journalistic process. There were lots of other topics, but these were the main threads.

Every journalism department should learn the art of aggregating. One of the small things I’ve been able to do to enrich the program at NYU is provide an East Village aggregator. The students should be learning how to create these sites. When I leave, what will happen if they want another aggregator. This technology is now fully mature and any student with reasonable technical ability (i.e. almost all of them) can be taught to manage such a site.

I truly hope the hackathon approach falls away. Not much is ever accomplished in intense social programming. Writing code, like writing long essays like this one, is not something you can do in an environment with lots of interruptions. One interruption at the wrong time can set you back by hours as the map falls out of your head. Programming and writing are both intellectual acts. So why would you expect great results from a crowded, smelly room that people have been living in for 24 hours. What you end up with is a bunch of tired, smelly and basically dishonest people (the most impressive projects are done in the weeks and months before the hackathon and just use the event to promote the work).

Instead take a step back, and envision the big problems we need to take on. Let’s break them up into manageable components, and start to solve them with our most talented students, in an interative open source fashion. Very quickly we’d bootstrap a system that works as well as the initial Internet did in the 70s. I was there at the tail end of the Unix bootup. It wasn’t a hackathon, it was more like a marathon. We have to teach our young people to think and work for the long-term. And we start by understanding the process and what yields useful long-term results and what just makes good demo.

In an effort to substantiate this, I made a list of 7 projects that students can attempt, which led to (imho) an even better list of 4 projects. None of these can be done in 24 hours, but all are approachable in a single semester, esp if teams of students work on them. Even better would be teams distributed across several campuses.

I would also insist that every student, without exception, run their own server. Bursting the mystique of the cloud is the easiest first step. That server will play the same role that a cadaver plays for a medical student. It’s a place for them to make mistakes, to gain experience, to gain rational and realistic fears, but not unnecessary ones.

I’ve written a tutorial called EC2 For Poets introduce Amazon EC2. In about 1/2 hour the student sets up and launches their own server in Amazon’s cloud. For many it’s an eye-opening experience.

Running software on the server is no different from running software on the desktop. The priesthood would like you to believe otherwise, but it’s not our job to reinforce the priesthood. Quite the opposite, our job is to explode it.

Part of the brilliance of universities is their iterative nature. We need to do a lot of iteration in pursuit of the journo-programmer. Every semester is a new beginning. Every new student is a chance to try a new approach.