What would you do differently if you could go back to college again? It’s a question I often get from college students who are interested in pursuing a career in journalism.
I always say the same thing, “I wish I took more computer science classes, more statistics classes, didn’t worry so much about my grades and got off campus more.”
But comparing a college journalism experience from a decade ago with someone’s experience today is like comparing an abacus to the Apple Watch. Back in my day, which wasn’t that long ago, we didn’t have Facebook, Twitter, Tumblr, Reddit, GitHub, Snapchat, Uber, Kickstarter, or YouTube. I used to promote my weekly humor column by waking up early on Wednesday mornings and folding the campus newspaper so my column was above the fold. Sometimes I would email it to a journalist I admired. At the time, that’s what social media meant.
To answer the question in a better way, I thought I would turn to some really successful college journalists from around the country and ask how they do the work they do — and what they’ve learned by doing it. (I suspect even non-college journalists will benefit from reading what they say. It’s applicable no matter what newsroom you work in.)
Over the next three weeks, I’ll profile three different college journalists from around the country who are leading the digital charge within their college newsrooms and ask them what every journalist should know.
I’m starting with Stephen Suen, who is a designer, developer and college senior majoring in Comparative Media Studies at MIT. He leads the online media and interactive graphics team at MIT’s college newspaper, The Tech, and spent a summer at ProPublica as a Google Journalism Fellow. I was really impressed with the way The Tech created an extensive package to talk about stress on campus and asked Stephen if he would talk about how it was built.
MK: What are you working on currently at The Tech?
SS: We’re currently in the final stages of launching our website’s latest redesign. The Tech has always claimed to be “the first newspaper published on the Web” (this specifically means the World Wide Web, not the internet in general) but our current website is painfully not up to today’s Web standards — it’s visually dated, isn’t responsive and uses outdated technologies. The last time the website was updated was back in 2007; this redesign is the second attempt since I’ve been at MIT. As one of the few frontend developers at The Tech, I’ve been leading the design side of things.
To make matters worse, our entire content management system was entirely beholden to our print workflow; in order to publish a breaking news story or push a simple change to an online article, somebody had to physically go into the office and make those edits in a very roundabout way. In other words, there was no way to directly publish to the Web. So we’ve completely rebuilt our backend systems and modernized our technology stack (which is also important for recruiting developers — nobody wants to maintain decade-old Perl scripts).
To accompany these changes, The Tech recently switched from publishing in print twice a week to once a week; with the new website, our goal is to become a digital-first newsroom, publishing stories online on a rolling basis, with the print paper being a compilation of the week’s articles. There have been some growing pains as we are also transitioning our “issue night”-centric editorial workflow to this continuous publishing model.
MK: I was wondering if you could talk a bit about what went into this package on pressure at MIT. It’s a lot of material and I’m wondering how you decided what should be represented visually vs. a video vs. an infographic.
SS: Starting in 2009 with the sex survey and continuing in 2012 with the religion survey (which both predated my time at the paper), The Tech has run a number of school-wide surveys. The pressure special was my first big project at the paper. I was essentially the data editor for the package — I sat on the committee that designed the survey and was in charge of querying the resulting dataset to identify patterns, surface stories, and just come up with generally interesting statistics to highlight.
The package was envisioned as a Tech-wide effort, with all departments contributing stories within the theme. The online media department, which was brand new at the time, was to contribute interactive graphics and video content. We always wanted to have a man-on-the-street component to compliment and contextualize all the quantitative data we were presenting.
We had a free response section on the survey, but aggregate text analysis is hard and we wanted to avoid a word cloud (shudder). Instead, we cherry-picked the best comments (see PDF p. 25 — it’s marked as p. 28, or see the online version). For this kind of thing, video is still far more evocative than text — seeing and hearing the person saying these things makes it far more real. Thus, we filmed additional interviews (though if you watch the video you’ll notice it’s pretty hard to hear anything).
With the interactives, our team members pretty much looked at the data we had available and pitched their own ideas, hence the diversity of the final results. We had an overall data breakdown but also graphics drilling down into specific ideas: sleep, work-life balance and difficult classes. Looking back now, there are so many things we would have done differently both in methodology and design, but for most of our team it was the first time doing something like this. Our output was also pretty miraculous given the two weeks we had between getting the data and publishing everything.
MK: What’s your workflow like? What hardware do you use? What software?
SS: With news interactives, a lot of the attention is placed on the final graphic/visualization, but really most of the workflow consists of finding, cleaning and analyzing data. Even when I do get my data, I spend most of my time actually conceptualizing and designing before I actually write any code. Roughly, my workflow looks like this:
Getting data: I find data through savvy Web browsing/searching (you’ll be surprised how many random reports and datasets are just floating around your college website), asking people nicely and scraping. For the latter, I tend to use the BeautifulSoup package, which is funny, because I’m more of a Ruby guy, but the intro CS class at MIT is taught in Python so it’s easy to teach others.
Designing: I try my best to adhere to the design thinking-style prototyping process, starting low fidelity and iterating quickly. The progression: rough sketches on pencil/paper, wireframes for basic layout (typically done in Keynote), and then final comps (I used to do them in Photoshop/Illustrator, but I’ve been using Sketch as of late). I haven’t tried out any of the interactive prototyping tools like Framer but I’d like to try it out one of these days.
I haven’t had the opportunity to do any hardware projects, unfortunately. I use a MacBook Pro for all my development. Also, Terminal is your friend.
MK: What would be your #adviceforyoungjournalists?
SS: Experiment! Take more risks. In a high school or college newsroom, there is so much freedom. At The Tech, we had no idea what we were doing with any of our interactives. We still don’t. But that doesn’t mean you can’t produce good work, and it definitely doesn’t mean you can’t learn.
For people looking to start interactive teams at their student papers, my main regret is not doing more to recruit computer scientists (especially at MIT). Most of the attention in the space right now is on how to teach reporters to code — but what about teaching coders to report? The OpenNews folks are doing a great job at the professional level; can we do the same for students?
Right now there’s a lot of buzz around college hackathons and I wonder if we can channel some of that spirit in the newsroom. Alex Duner has started a great Campus Media Hacks Facebook group that can hopefully serve as a starting point for this community moving forward. If you haven’t already, get on Twitter and start following other people in the space — it’s a great venue for inspiration, conversation, and late-night code questions.
MK: How did you learn how to code?
SS: I was fortunate enough to get some early exposure to programming by way of my dad, who studied computer science. I got into Web development thanks to the likes of Neopets (surprising as this may sound, a lot of people my age will say the same thing) and Geocities. For a while I was really into Flash, but eventually graduated to PHP and made WordPress/Drupal sites in high school. I starting doing some freelance work and also got some experience in online journalism by being the Web developer and occasional contributor for my older brother’s site 21st Century Boy, an English language blog on Asian politics and pop culture. It wasn’t until I got to MIT that I discovered how much I didn’t know and how deep the coding rabbit hole went. I’m not majoring in CS but I take classes here and there and try to pick up at least one new technology/library with every project I do.
MK: What project are you most proud of?
SS: The NSA Mythbusters-meets-pop-up-video graphic I did during my Google Journalism Fellowship at ProPublica. It features clips of government officials making statements about NSA surveillance that I edited together à la the old VH1 pop-up videos. The YouTube API was then used to display an annotated transcript and analysis in real-time. It’s definitely the most unconventional/original graphic I’ve worked on to date. The super neat thing about it is that it employs the principles of spreadability and drillability (yes, I’m aware these are terrible names) — the video is a self-contained unit that can be shared by itself on social media, but those who want to engage at a deeper level can go to the graphic and read the more detailed analysis. I didn’t only flex my creative and technical muscles on this project, but I was indulging my inner media scholar as well.
MK: What do you plan to do when you graduate?
SS: I actually took a break from journalism last summer and worked in tech (I’d never had a proper internship at a software company) to get some perspective. My conclusion from that experience was that — while I could definitely flourish at a tech company — I need to work on a product I care about, ideally something related to media. That being said, I don’t want to completely abandon the tech side of things either. Right now I’m looking at media-related tech companies and also tech-savvy media companies/newsrooms. The problem for someone like me (and I’m sure others in this space) is knowing what role to apply for: should I apply as a journalist? A designer? An engineer? I’m still trying to figure that out. (But do get in touch if you’re hiring. My parents are worried about me.)
MK: How did you decide to focus on journalism?
SS: I originally went to college with the intent of studying cyberlaw/internet policy, but after taking a law class I quickly learned it wasn’t for me — I’m a person who wants to make things. While doing research at Harvard’s Berkman Center for Internet & Society I got really interested in data visualization of social networks and Twitter data. Surprisingly, there weren’t any real data visualization classes at MIT (though this has changed). This was the summer of 2012, when The New York Times was putting out some pretty amazing interactives for the Olympics, and I figured that I would try and replicate this at The Tech, which had just formed its online media department.
I’m still not entirely comfortable labeling myself as a journalist, but more broadly, interactive news appeals to my interdisciplinary nature as someone who wants to work on both content and technology. Journalism may be facing a crisis as an industry, but that has also meant more experimentation and risk-taking. I can do design, code, and storytelling all at the same time — something that would not be possible as a typical software engineer or Web developer. The awesome people in this space and the amazing work that they do have only intensified my excitement for the future of news — a sentiment exemplified by my time at ProPublica.
MK: If you were going to give one piece of advice to people who might not know how to code but would like to help their own reporting, what would it be?
SS: You’ve probably been told to “learn to code” already, so I will add the corollary to that: learn to talk about code. Even if you can’t implement something, basic code literacy and algorithmic thinking can help bridge the gap in the newsroom — knowing what is possible with technology will allow you think about stories in a different way and identify new ones entirely. Look at what other newsrooms are doing with code and use that as inspiration.
In the same vein, if you are learning to code, know that it’s okay to copy. There are so many resources at your disposal available online. That’s how most programmers learned in the first place, and that’s still how we operate — being good at programming is often less about knowing how to implement complicated algorithms and more about being good at wording search queries and perusing StackOverflow answers or GitHub issues.
That being said, don’t be satisfied to just copy. Take it a step further. Modify it and repurpose it. When you make changes to code, that’s when you have to really drill down, reverse engineer, and understand it. The changes can be small — changing the color of something or what information is displayed. Baby steps.
MK: What tools do you use that are must-haves?
SS: I already name-dropped a bunch of tools earlier, but remember that tools are a personal preference — use whatever you’re comfortable with or what works for you. It’s good to always learn new things but don’t let the technology you use constrain the story/product/design. In general terms, you should get comfortable with the command line, a good text editor, a data wrangling tool, your browser’s Web inspector, some sort of design software, and a project management system.
In these categories, I personally use:
Terminal.app, Sublime Text (code) + Mou (markdown), OpenRefine, Google Chrome, Sketch, Slack (all aboard the hype train!)
The closest thing there is to a must-have is Git. I wish I could say version control systems are a matter of personal preference, but I’d be lying. Learn Git.