3 A couple years ago, I had one of those opportunities you don't get often: I got to build a team from scratch.
?? me ?? Not a big team, there would be three of us, and we'd have a role in basically everything that required code on a small news site -- from data journalism, to experimenting with new story forms, to a major site redesign.
As we got into the hiring process, I started making a list of all the skills we might need, so I could compare candidates. This got overwhelming pretty quickly.
It's a problem of language.
I didn't realize it at the time, but this was part of a problem I'd been struggling with in different ways since I started writing code for journalism, back when George W Bush was still president. It's a problem of language. There's an overwhelming number of skills and tools we use in writing code around news. Most of those, and most job descriptions, are lumped together into titles like "news applications" or "interactives" or data journalism.
Reporting. Storytelling. Product. Then a few months ago, a friend asked me to talk to one of her students who was a talented photographer and also starting a comp sci program. And he wanted to know what to do with that set of skills. And after talking to him and thinking about the jobs I've had, I realized that ultimately, there are three kinds of code we write in newsrooms: Reporting. Storytelling. Product. And that's pretty much it. So what do I mean by reporting, storytelling and product?
Reporting: What is the story? Reporting code is, well, reporting. It's scraping, data analysis, machine learning and natural language processing. When you're using SQL, R, Pandas and Jupyter notebooks, you're probably writing code I'd call reporting.
Storytelling: How do we tell it? Storytelling is, of course, what we do with all that reporting. It's our graphics, interactive or not, and maps and charts and generative text. AR and VR and 3D modeling.
What tools do we have available? And what is product? You might be thinking: We have another department that does that. They're IT, and I'm in the newsroom. And I'm here to say, more of us are doing product than we realize. Product is everything we build that isn't for just one story or project. It's everything we do between deadlines that makes our next project launch faster or run smoother or get a little closer to what our audience needs. (In fact, it's everywhere we talk about user needs.) It's anything we need to maintain, and anything that accumulated technical debt. (You might say it is the technical debt.) It's our app templates and starter kits that we update after we launch a project. It's our longform tool. It's our open source code. It's our analytics packages and documented best practices.
Product: In Depth framework (our storytelling template)
Reporting: Which communities are most at risk? Which particular risks does each community face?
Storytelling: Explaining risk and methodology.
Reporting? Storytelling? Product? So why does it matter what we call these kinds of code? Because they move at different speeds, and moving at different speeds is something I've seen every newsroom I've worked in struggle with.
Think of a project you worked on that went well. It probably started with a lot of reporting, which tapered off as the story solidified and you started to focus on storytelling. Meanwhile, product is (or should be) moving along in a steady cadence of sprints.
oops And this is where it's important to know what kind of code we're writing, and to be able to talk about it with other people in the newsroom, especially our editors. This is where it's easy to screw things up. This is where I've screwed things up.
Trying to make something reusable (product) too early, when reporting is what's needed: ProPublica Congress Python client: https://github.com/eyeseast/propublica-congress. I wrote this because someone pitched a story related to Congress, and my response was to create a Python package. Cool. Never used it for a story. Sorry Derek Willis.
Falling in love with storytelling when it's time to move into product: This story was great: http://apps.frontline.org/zika-water/. We did a dozen like it, with a little variation, each one basically a bespoke Tarbell project. After about the third one, we really should have started building tools into WordPress, but I was nervous about technical debt. This is where it helps to think in product terms.
Writing storytelling code that becomes technical debt: The topper here is gorgeous: https://www.desertsun.com/in-depth/news/environment/border-pollution/poisoned-cities/2018/12/05/air-pollution-taking-deadly-toll-u-s-mexico-border/1381585002/. It's also built into our storytelling framework, which means we're responsible for it forever. Oops.

[your screwup here]

I'm sure you have your own examples.
Thinking about these three distinct kinds of code can help beyond individual projects. If you're looking at a job description, it's a good way to get a read on what kind of job it is, and whether it matches up with your skills or career goals. I've been using it to decide which NICAR sessions to go to.

Should I learn ___ ?

What is ___ best suited for?

How might ___ be used for reporting? for storytelling? for product?

It helps answer the question: "Should I learn X?" Now you can reframe it as, "What is X best suited for? How might X be used for reporting, for storytelling, for product?"
one last thing One last thing: When I talk about three kinds of code, I want to be very clear that I don't mean there are three kinds of coders. As I said at the top, most of us are doing all three kinds of programming, and I think that's a good thing, because it pushes us to be better and more well-rounded, both as programmers and as journalists. Reporting and storytelling are still the core of our profession, and product is going to open up new ways of doing both. We all have a lot to learn from each other.
Reporting + Storytelling + Product