Two New York 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, Jay Rosen, 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, 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 and mid 2000s.

So…what is a journo-programmer, and how might 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 were well versed on the capabilities of the web. My best teachers were the ones who understood and used linking. And they made it very clear that we, the unpaid production staff, were not to lose a single opportunity to 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 to the importance of 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 Justin’s Nieman Lab article because it has already been written and I can link to it instead.

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, which automatically aggregates news about WikiLeaks. 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’s a permanent paid staff that manages the websites for students and faculty. It seems to me that if your goal is to boot a new class of journo-programmers, 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 and 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 is. Never mind all the problems along the way — that becomes hidden. Same with software.

So 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 links. 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. 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 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 sometimes dishonest people (the most impressive projects are often 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 for a good demo.

In an effort to substantiate this, I made a list of seven projects that students can attempt, which led to an even better list of four projects. None of these can be done in 24 hours, but all are approachable in a single semester, especially 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 to introduce Amazon EC2. In about half an hour, students set up and launch 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.