Skip to main content.

"We're Not Code Monkeys": A Guide to Working with Developers in the Newsroom

"We're Not Code Monkeys": A Guide to Working with Developers in the Newsroom

Picture of Angilee Shah

Katharine Jarmul was developing a product she was particularly excited about while working for USA Today in the summer of 2010. The newspaper had a lot of data about the quality of hospitals and had created a map to help readers visualize the information.

The online projects team was small – just six people handled web products and interactive projects – and Jarmul was second-in-command. They thought, though, "Wouldn't it be really great if someone could pull this up on their mobile device?" They imagined users finding a lot of information about hospitals nearby when they had to make quick decisions. The online team was excited, and the health and science editors were on board.

But Jarmul says that the project was continuously stalled. The team was called in to do other tasks and not given any extra resources to keep existing products up-to-date.

"It's difficult in a newsroom that has limited resources to prioritize many interesting stories," says Jarmul. The map of hospitals' heart care quality still exists today in Flash form, but the mobile application was never realized.

Katharine Jarmul

Jarmul, who has a masters degree in journalism, began learning programming as part of the online teams at the Washington Post and USA Today. She is now the lead developer at LOUD3R, a startup that builds content curation tools for publishers. I met her while working on a story for the LA Weekly about a Los Angeles-based organization called PyLadies. She is the vice president of the organization and an ardent believer that anyone should who wants to should have access to resources and not feel intimidated to learn computer programming.

That said, quality programming is a real talent. It's not just about writing code – it's a skill, arguably an art, to be able create programs and features that resonate with users. So it is important that reporters and editors learn to work with developers, to value their skills and treat them as part of an editorial team. This week in Career GPS, Jarmul offers some rules of the road for working with programmers, designers and developers to create news applications and interactive features.

Avoid the "abracadabra" assumption.

Editors and reporters often have unreasonable expectations, as though programmers can snap their fingers and make something happen like magic.

"It's hard to explain sometimes the amount of time it takes to rework something in a new way," Jarmul says. "Don't assume that updating or adding to something that already exists is simple."

Streamline repeated tasks.

Quizzes, maps and Twitter streams are the top three requests Jarmul got from reporters and editors. They are relatively simple tasks, but they are also ones that reporters could conceivably accomplish for themselves.

"Journalists shouldn't have to apply for time from the developer team [for these features]. The tools should be available to them," Jarmul explains.

If journalists could create these multimedia features with applications built in to the content management systems, the process could be much easier. But the key is to give developers time to create those applications.

Plan ahead.

Computer Cat by Steve Caddy on Flickr Creative Commons

Elections, awards seasons, the implementation of new health care laws – these are all big stories that editors and reporters know about well in advance. Discuss them as early as possible with your team, including developers, so that no one is left coding until midnight to make a tight deadline.

"As soon as you know those stories, you should be looping in the developers and giving them time and space to do them, hopefully ahead of schedule," says Jarmul. "It's kind of antithetical to the newsroom cycle, but it's really important because if other things come up, it gives them cushion time."

Don't just instruct developers. Include them.

"Don't treat developers as code monkeys," Jarmul says.

You could just hand a developer a pile of data, and you might end up with a really good map or interactive feature. But there might be something even more that can be done with the data, something you didn't even consider. If designers, developers and reporters have open conversations about projects, possibilities will grow. Your online team, even if it consists of just one developer, often has a lot skills and can be a real asset in creating stories, visuals and even new ways to sell advertising.

"Developers are some of the most talented technical people at news organizations," Jarmul says. "See them as a smart resource that can help the company, not just as people who can only write code."

Jarmul chooses to work for people and teams that see her as part of the creative process -- at the Post, for example, she was included in features meetings -- but she has had to actively seek out those opportunities. Her colleagues, she says, are most often handed a design and told to go build it, which does not take advantage of all their skills and leads to burn-out.

"Most of the developers who I know who have left news, have left because of that," she says.

Choose projects wisely.

"Not every feature needs an interactive feature or a designer," says Jarmul. Some types of interactive features are overused.

Bring a developer to the table and treat his or her opinions and ideas as important to the project. Sometimes, you will walk away with a great interactive idea. Other times, nothing in a story will have lent itself to a database or data interactive, and that's ok too, says Jarmul.

(Photo: Computer cat by Steven Caddy on Flickr Creative Commons)


Follow Us



CHJ Icon