There's an idea, emanating from New York, that if we somehow combine the talents of programmers and journalists, we'll figure out how to make news work in the age of the Internet. I haven't been sure what to call this, but I agree that there's a lot of power in the combination.  

Justin Ellis, writing on the Nieman Lab site today, came up with a simple name that works, "the journo-programmer." Until a better term comes along, let's go with that. 

One of the reasons it's important, here, is that two of the journalist-teaching universities, NYU and Columbia, have launched programs to create them. At NYU, Jay Rosen, my colleague and partner in the Rebooting The News podcast, is leading the effort with Studio 20. Columbia hired Emily Bell to lead their effort, a graduate program called Tow Center for Digital Journalism.  

I visited with Bell last week at her office at Columbia. It was a snowy cold day, but what a beautiful place!  

We talked about our histories (she had a career at the Guardian before coming to NY), and WikiLeaks of course (at the center of what we both do) and then to this idea -- the journo-programmer. 

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 SF newspaper strike. I've written about this here many times. But here's something to focus on for this subject. The writers, who were professional news people of the mid-90s, largely before the big change swept through their industry, were very well-versed on the abilities of the web. Not all of them. But 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 left with me when I was a 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.  

The next question is how do we teach the journo-programmer. As you might imagine, I have a few ideas about that.  

Here's what I say. 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. 

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 univervities 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.