Photo by corinnepw/Flickr
More than ever before, reporters are learning hybrid skills by using open-source storytelling tools, building data visualizations such as charts and maps, and using HTML and CSS skills to improve Web stories. Editorial teams are working hand-in-hand with developers and their work every day, from using Tweet embeds to fusion tables, and sometimes, within our companies.
To start working with developers, it’s helpful to understand what kinds of work they do. On any team, there can be vague roles that have intersectional duties. This is also true for developers at media companies, whose responsibilities can range from keeping the site running and preparing a plan for DDoS attacks to working with designers on new editorial tools to developing user experience interactions in native ads.
Front-end developers work on the user-facing side of apps and websites. Generally, anything you can see on the surface level when visiting a website is there because a front-end developer coded all those components to display in those places. Front-end developers also work on websites to display consistently across popular browsers and devices readers use.
Front-end designers have skills somewhere on the spectrum of code and design, depending on their skills and interests. One end is a designer who sometimes uses front-end coding and mostly does design work, and the other end is a front-end developer who mostly codes and has design experience.
Back-end developers are in charge of writing code within frameworks that organize and store all content on websites. Users can find articles by clicking on URL links, writers can find photos, galleries, and other assets with admin permissions, and back-end developers organize and maintain all of that in the codebase.
Full-stack developers, like front-end designers, have intersectional skills that draw from both front- and back-end development. Their daily work is varied and the learning curve is really high in switching between tasks such as troubleshooting layout placement bugs to migrating large amounts of data for relaunches.
Operations engineers keep the site running, they and have many strategies to do so. They plan ahead for traffic surges and DDoS attacks so the website continues running or at least is back up as soon as possible. When 500s appear anywhere on the site, or redirects have to be placed, ops is there to help.
After getting to know about what kind of work developers do, it’ll be easier to build a foundation of questions to ask. When things like site outages and technical malfunctions happen, you’re already calm because you realize wait, I generally know who is working on this issue. Here are a few basic questions to ask your friendly neighborhood developers after asking what they work on. Their different perspective will provide some unexpected ways of looking at the same situation.
How do you tell the difference between a bug and a new tool or feature?
There are a lot of updates and fixes rolling out all the time for content management systems, and it’s difficult to keep up with changes. Fixes for one feature have the potential to accidentally step on another part of the codebase for another feature, which creates a new bug. The intentional design for a new feature may not make sense for the people who use it, which also could look like a bug. Tech support and developers can look at these situations in different ways, so it’s worth asking how a developer (who isn’t aware of all of the features either) finds out the difference between the two.
Do you usually write documentation for new features or tools, or does someone else on your team?
When new features and tools are developed, someone usually writes an explainer on what the tool is and what to expect. The workflow between editorial and developer teams is similar: report on an issue (on a beat in the outside world or within a product), write code and copy on that subject, have the code or copy edited and tested by peers, and push it out in a deploy or publish it. When the product is the CMS or tools that your team uses, it’s worth asking to be in the loop to see occasional documentation that explains any large changes or new tools. Developers who write documentation or occasionally provide support to users can often benefit from thinking about products from the user’s perspective (especially if that user is you).
What are you interested in doing professionally? What would be your ideal project?
This is a telling question that managers should ask, no matter if the person you’re asking is a direct report or not. Just like anyone else, developers are all over the place in terms of experience, interests and goals. Asking colleagues, past and present, what they’d like to do in the future has really benefited my understanding of their work, and at times I’ve looked out for and built collaborative opportunities that are relevant to their goals and mine.
Have you worked with editors or reporters before? Are you interested in working on editorial or video projects?
From what we learned from having an experimental editorial-product hack week, designers and developers who hadn’t worked with editors before ended up expanding their horizons and making new goals to work on editorial projects in the future. It’s a powerful thing to open a door to that future collaboration, even hypothetically, and put out a call to pitches from people who may not be traditional journalists, and to value ideas that could bring something new to the table.
