NICAR Q&A with Armand Emamdjomeh

Armand Emamdjomeh

Armand Emamdjomeh is a data reporter at the Los Angeles Times. While at the UC Berkeley Graduate School of Journalism, he helped to launch Mission Local, a community news site covering San Francisco's Mission District. In a previous life, he worked for international disaster relief and development agencies. Our interview follows.

How would you describe your job?

I'd say it's pretty open-ended. We all have a few basic responsibilities on the Data Desk and have mini-beats we cover. While I oversee the Homicide Report site and Quakebot (our earthquake monitoring and story-writing robot), I also tend to work on anything involving transportation safety, since I've spent a lot of time learning how to analyze California's SWITRS database of road accidents.

That said, if I have a compelling story or viz idea outside of those areas, I'm usually completely able to work on them. The only real constraint is time.

How did you learn how to code and start creating interactive designs?

I took a basic HTML/CSS class in j-school which started me down the rabbit hole, but I pretty much learned on the job. I was hired at the LAT as sort of an on-demand hacker/uber-producer, so it was a lot of "we need a video/Twitter/something widget five minutes ago, go!" You tend to learn pretty quickly in those sorts of situations.

After a while our editor Megan Garvey had me use my HTML/CSS skills to produce what we now call our "Big Builds," which are basically hand-crafted story templates, and from there I started doing some basic data visualizations, which is how I learned JavaScript and basic data manipulation using JSON and CSVs.

I usually set a goal of learning something new with every project. For example, in one project I'll try to use web scraping in Python, in another I'll try to use a JavaScript SVG library that isn't D3, or drawing custom items on Leaflet maps, and so on.

At what point in the story process are you brought on to create the visualizations? Do you also get to pitch stories that you find compelling?

We're always open to compelling pitches at the L.A. Times, we're very flexible in that respect. For example, as a producer on the website, I shot and edited videos and worked on a "Column One" story. Likewise, on the Data Desk, I can develop the idea for and begin reporting out a story. These are among the best situations, because I can start thinking about the visualization and online presentation from the very beginning. Our recent story on pedestrian accidents, bicycle hit-and-run piece, and pro athletes filing for workers compensation stories are good examples.

As for when I'm brought in to create visualizations, it depends. Sometimes, it might be something we need to crank out over a day or two because it's for a daily or weekly column, and other times we'll typically have a few weeks or so. I try to build my own relationships with reporters in the newsroom, so a few folks will come to me and say, "I'm working on this story, so what are some of the ideas that you would have for a visualization angle?"

You don't want to be in a situation where you see a story run that you could have done something great for, so clear lines of newsroom communication are essential.

What was one of the most memorable stories you've worked on so far, and what made it interesting?

There've been a few. One of my all-time favorites is an interactive for a story on the first satellite in geosynchronous Earth orbit. It wasn't a huge story, but it was a really fun viz, because I got to learn how to use the three.js JavaScript library, used for creating 3-D interactives, and who doesn't love plotting things in space? I've never really gotten to use three.js again since then, though I'm keeping my eye out for opportunities.

Another favorite is "Finding Marlowe," a story by Daniel Miller on Samuel Marlowe, L.A.'s first licensed black private detective, who may have been a major influence on noir writers Raymond Chandler and Dashiell Hammett. While not a technically complex piece, we had a lot of fun making the presentation. My colleague Lily Mihalik tracked down an illustrator who came up with these great animated illustrations that really gave the piece the flavor of 1930's L.A noir. We had fun making the piece, and I think it comes through in the final presentation.

Overall though, I think I'm most fond of our pedestrian accidents story, both because of the subject matter, and how much I learned in the project - from data process and analysis to custom mapping in Leaflet and QGIS. It's great to be able to dive deep into a library (Leaflet in this case) that you've considered magic for so long and realize "Oh. So *this* is how it works."

When you come across problems with the data in a project after it gets published, how do you go about fixing the problem?

Usually, we'll have to post a correction of some sort. Which makes things tricky because at some point it's nearly impossible to ensure 100 percent accuracy in a massive dataset. For example, with the pedestrians story, we realized after a reader wrote in that somehow the Bing geocoder we used had located several intersections exactly 200 blocks south of where they were supposed to be - Western and 48th was located at Western and 248th, Western and 46th was at 246th, and so on.

It was a bummer to post a correction on a story we'd worked on for so long, but it was also humbling and a reality check. That's the risk of dealing with many, many points of data - there are many, many things that can go wrong.

What would you say are the key things to keep in mind when working on a big project like your latest story on the dangerous intersections in LA?

Document everything. You don't want to be trying to confirm a number that you have no idea where it came from. One of the things I like most about working in Django is that everything can be walked back through the views and models to the beginning of the data, and the nature of Python encourages readability and good documentation practices.

Using a version manager like GitHub also helps with this. Nothing annoys me more than seeing a bunch of files named something like "xxxx_final_REALLYFINAL_new_credits.csv". With version control, you can just overwrite the old file. Later on, if you find you need something you worked on earlier, you can just walk back to that stage in the project.

This interview has been lightly edited for clarity.