From news media to Datawrapper: Six things I’ve learned in my first year

Elliot Bentley

Hi, this is Elliot, a data visualization developer on Datawrapper’s vis team. Today I want to share some thoughts on my transition from newspaper to software company. This post is mostly written for people who already understand a thing or two about web development, but I hope there are still a few interesting bits in it for those who don’t.

About a year ago, I left my job in The Wall Street Journal’s graphics department for something a bit different: working as a full-time developer at Datawrapper.

As you might expect, after eight years working in news I’ve had to learn (and unlearn) a few key skills at a software company. Even with what I thought of as pretty decent programming chops, my first year in the tech industry proper has taught me plenty.

1. Byline addiction is real

At risk of stating the obvious, the pace of life in a software company is considerably slower than in a newsroom. No longer do I wake up, check the headlines, and immediately start considering if and how we might cover each story visually. It’s been a pleasant change, even if I sometimes feel that Fear Of Missing Out when really big news breaks. That gets weaker by the day, thankfully.

The other big, obvious change is that (aside from the occasional Weekly Chart) my job no longer involves publishing work with my name attached, and all the cachet and stress that comes with it. The thrill of putting something out into the world and hoping that people like it is an addiction — with the highs of success often followed by a crash in mood as one tries to follow up with something even better.

2. Software development is 75% tidying up

One of the things I was most excited for in a new job was building long-term software. Interactive news graphics might get worked on for a few weeks or months at most, and their half-life is rarely longer than 24 hours. On that kind of schedule, there’s no point in investing much time in high-quality code, architecture, and testing.

With a codebase as mature as Datawrapper’s, those things are high priorities. We have a huge swath of existing features and options that need to be checked with detailed test suites, all of which I expected. But even more than that, we spend a lot of time refactoring code to be less repetitive, making things consistent between the chart types, and doing other maintenance tasks. It’s unglamorous but important work.^[1]

Come to think of it, this isn’t so different from journalism: One has to pay close attention to getting the little details right without losing sight of the broader narrative.

3. Svelte.js is ready for the big leagues

I’m a big fan of Rich Harris‘ work in journalism and software. And after using Svelte for a year, I’m pleased to say that it lives up to the hype, forming a robust backbone for Datawrapper’s UI and, more recently, its SVG render code.

Sometimes I miss the efficiency of being able to define a new React component in a few lines, but Svelte’s highly readable markup more than makes up for it. My only beef is that Svelte files stretching into a hundred lines of code or more can be difficult to read. Maybe the syntax changes in Svelte 5 will help.

4. TypeScript is a blessing and a curse

We’ve been gradually introducing TypeScript into the Datawrapper codebase along with Svelte. Catching type-sensitive bugs is helpful, but it’s the VSCode “Intellisense” integrate that makes it a huge productivity booster — autocomplete that you don’t have to second-guess. The downside, of course, is having to occasionally twist your code into strange shapes to appease the type checker. And resist the temptation to suppress those errors by plonking as any everywhere.

5. Git rebase isn’t so scary

At Datawrapper, we keep our Git history clean by making liberal use of the rebase feature — somewhat essential when you have a dozen or so people committing to the same repo. Git rebase literally rewrites history to move older commits from one branch onto the top of newer ones.

Despite having used Git for over a decade, and being familiar with the typical pull request workflow, I’d never encountered this before! The process was a bit nerve-wracking at first, but I feel fairly confident messing with time after some coaching from my colleague Gregor and help from Sublime Merge.

6. It’s important to make an effort to leave the home office occasionally

Software development is a much more solitary job than journalism, especially since I’m working fully remotely. Visiting Datawrapper’s Berlin office and spending time with coworkers IRL is always rewarding, but it’s a bit far to travel regularly.

So to get a little more human contact day-to-day, I’ve been making an effort to attend events after work (particularly Journocoders, which I am so pleased to see still going strong). My sofa does always look a lot more comfortable than a long commute on the Tube, mind you.

This post first appeared on the blog at my personal website, elliotbentley.com. If you’re interested in Datawrapper’s Svelte setup, check out “What we learned from migrating our web app to SvelteKit,” by my colleague Marten.

Want to join us? You’ll find open positions on Datawrapper’s careers page.

1. Don’t worry, it’s not all dull maintenance: I am currently working on exciting new features for Datawrapper, which I hope to let you all know about soon! Although it almost goes without saying that even building new features requires a considerable amount of tidying up after oneself, too. ↩︎

---

Elliot Bentley

(he/him, vis.social/@ejb) is a senior data visualization developer at Datawrapper. He previously worked on interactive graphics and internal tools at The Wall Street Journal and created the popular web app oTranscribe. Outside of work, Elliot likes to make his own video games. He lives in London.

Liked this article? Maybe your friends will too:

Twitter Facebook