Crossing the language boundaries across your newsroom: journo to dev and back

Sarah Cohen is an editor for The New York Times, where she works on computer-assisted projects. She previously worked as the Knight chair at Duke University, a database editor for the Washington Post, and a reporter in Florida. She serves on IRE's board of directors. @sarahcnyt

Noah Veltman is a developer and datanaut for the WNYC Data News Team. He builds interactive graphics, maps, and data-driven news apps, and spends a lot of time spelunking in messy spreadsheets. Prior to WNYC, he was a Knight-Mozilla OpenNews Fellow at BBC News in London. Some of his other projects can be found here: http://noahveltman.com/sandbox/

Erika Owens is a web journalist based in Philadelphia, Pa. She works with Knight-Mozilla OpenNews to help journalists, developers, designers, data geeks, and civic hackers create awesome projects together on the open web. @erika_owens

Noah opens the panel by introducing a new hashtag for NICAR: #NICAR14huh, for anything you’ve heard over the course of the conference that you didn’t understand. He says the secret is not to treat developers like a service desk — what ProPublica’s Al Shaw calls “the deli counter,” where you just hand in your order. The developers are reporters, too, and you should treat them as such.

Communication in particular is hard. Email is bad; tickets are slightly better but still aren’t synchronous. Using chat or direct communication is better. Having time to test things can be very contentious. There are other concerns for developers: Are you going to reuse this later? Is this an ongoing project? Will the data be updated? How is that going to work? How is this going to be maintained? What’s the game plan? What is the minimum viable product, and what can be delayed until later?

Noah also points to the use of the word “just”, which can be very alienating to people who may have a different skillset. Developers need to get better at explaining technical decisions. If you make decisions that affect editorial stuff, you have to get better explaining those tradeoffs. There are a few solutions, such as inviting developers to editorial meetings and reporters to developer meetings, etc. You can hold things like brown bag lunches or post-mortems — any excuse for cross-pollination will help break down these barriers.

Now up is Erika, who brings up the example of content management systems. Everyone likes to say they hate their CMS. That phrase can be alienating, because people don’t always know what that means or why they’re saying that. It’s a good way to unpack the different perspectives surrounding the issues. For example, some people find CMSs too inflexible and rigid; on the other hand, it makes it really easy to do the repeated tasks that happen a lot in news organizations. CMSs rely on a really clear workflow, and sometimes documenting those processes can be really challenging. There are workarounds, such as the Chicago Tribune’s Tarbell project. Erika says that CMSs can be used as a sort of “gateway drug into coding.”

Another space that provides a lot of potential for cross-boundary conversations are hackathons, where teams spontaneously organize to produce projects around a topic in a short period of time. It gives a taste of what the development process is like for reporters, and may give developers some idea of editorial concerns. It’s a low-cost way for people to “dip their toe in the water… when people have a chance to work on a project, it becomes clear that [the wizard/Muggle dichotomy] is not true.”

Erika points us to Matt Waite’s piece on ethics in journalism, which she says could be applied to any hackathon, showing the connections between the two. Hackathons let us learn what other people, and even if the project never makes it to the website, they help people work together more effectively in the future.

When starting any journalist project, Sarah asks herself what the journalism going to look like? How is it going to be presented? Is it focused on delivering an app, or is it a more investigative/exploratory project? Depending on your answer to that question, you have to approach the journalism in a different way.

“If you’ve never sat at a copy desk, you don’t understand that if you hand in your story 30 minutes late, you’ve ruined the days of everyone else down the line,” Sarah says. She emphasizes the importance of knowing what other people do. Some people at The New York Times have taken the initiative to adopt an anthropological approach to understanding the work of their colleagues, asking them questions and exploring what it is they do.

“Just because we [the journalists] think it’s important, it doesn’t mean that it’s the right thing to do with the news application,” says Sarah. Developers will naturally focus more energy on things that need to be regularly updated, rather than a one-off project. She also says to always prepared for unexpected situations — in particular, when it comes to budgeting time. “What it appears to be is often not what it really is.”

Sarah says as reporters, we tend not to do enough fact-checking in its entirety, in particular on the developer side. In some cases, the reporters won’t even look at the app for errors. If no editor or reporter looks at a project before it goes live, these errors might not be caught. As the domain experts, you can’t just expect to hand the data off to someone else and hope that it retains the same level of journalistic presence.

We now move into the Q&A section of the talk. The first question is about hackathons — what is the best ratio of reporters, developers, designers, generalists, etc. to make a hackathon successful? Dan Sinker, the director of OpenNews, suggests a 2:1 ratio between people working on code and/or presentation and people working on data/the journalistic side. Noah says depending on the theme of the hackathon, you might need to tweak the ratio, especially if there’s more work upfront in finding the data and surfacing the stories. Sarah recalls her experience at a hackathon — “I didn’t know what I could do.”

Another question is about the hybridization of skills in the newsroom — will the two functions of coding and reporting eventually converge, or will they always be slightly different? Sarah says reporters who learn code tend to do so as a way to answer specific questions, while coders who enter the realm of reporting do so to improve the quality of their work. “It is very difficult to take off a reporter’s hat, and put on a developer’s hat… they’re very different kinds of disciplines. It’s going to be hard to be really good at both.”

Noah echoes Sarah’s point — there’s a difference between familiarity, which is constructive, and true hybridization. It’s not a quick process, and you just have an issue of time. We all want to wear more hats all of the time, but we have to get stuff done. There’s not always time to dabble and switch concepts. Erika points out the idea of the panel is not to get everyone to do everything, but getting everyone at a point where they’re able to communicate with one another.

Next is a question about differing visions — as an editor, you might have a different direction in mind than your reporters/developers. How do you check along the way to make sure valuable time isn’t wasted? Sarah says that one approach is to have developers and reporters meet every day — even as little as 10 minutes — just to get on the same page and speak the same language. Noah says it’s important to write down as much as possible, to avoid mismatch. A chain of correspondence helps clear up ambiguity.

“You don’t know what you don’t know,” says Erika, who says that things like coffee and informal discussions can go a long way. At the BBC, Noah led a series of learning lunches where members of the visual journalism team would sit down and learn about technical stuff — not in a tutorial format, but from the perspective of context. “I think it’s a really good way to create a space for people to ask questions where there’s not really a good time to ask.”

By grounding the concepts in projects that everybody is familiar with (and maybe even worked on), it helps guide the discussion. Noah has a GitHub repo of materials from these learning lunches: http://github.com/veltman/learninglunches. “You can confuse what looks easy and what is easy,” adds Sarah.

Noah talks about the difference between working in the software world and in a newsroom — deadlines are very different, and you might have to prioritize that deadline over other things, such as good code hygiene. You’re not building things that you have to update every week or that people will be looking at six months from now, and that should be considered during the development process. Erika advises newsroom developers to look at a book of journalist ethics and try to filter relevant concerns into the development process.

There’s a question about static site generators. Noah likes to think about the static vs. dynamic debate in terms of food. In the early days of the website, everything was static — everything was an actual file. He calls this the “vending machine” — everything is already there, everything is pre-packaged. On a dynamic site, it’s more like a “restaurant,” where the ingredients are there but the food does not exist yet. You have a database that generates a page on the fly, which gets sent back. Static site generators output a vending machine, but have some dynamic processes underlying it on the development side.

Sarah points out that reporters would never use the word “workflow,” even though they have one. “In reporting, there’s an adage where if you get stuck on something, you have to go back a step… that’s what one of the things that really frustrates developers — there’s a lot of back movement in our workflow, it’s not always moving forwards. It’s not a linear process on the reporting side.” At The New York Times, it decides in advance which stories will involve multiple departments — there are early warning systems in place, but developers and designers can sometimes get frustrated when they get involved too early, when the story hasn’t quite materialized yet.

There’s a question about who “edits” a data application, especially when you have fuzzy lines between the interactive/graphical components and the narrative components. The timing can get very tricky, says Sarah. There can be tension when reporters might want those components beforehand, even though it might not actually end up getting published.

Next, someone asks a question about the intense data work that might only result in a single sentence in a story, versus a big flashy data visualization project. Sarah advises everyone to move back to “what should be done” rather than “what can be done.” — “I mean, how many Snow Falls per year can we really manage?” Noah says to get to the core — why are people asking for the big, splashy things? Is it just because other people did it, or is it actually important to the story?

An audience member revisits an earlier point — developers can be journalists, too. A developer can contribute to a story in the way that a second reporter can.

Feel free to add text/images/links if you are at the talk. Add your Twitter handle if you contributed:
@s2tephen