January 7, 2021

Should Writers Code? Rethinking Publishing on the Web

I’m a designer who codes. But I also enjoy writing, and I spent the first several years of my career as a staff writer and editor for publications ranging from consumer magazines to whimsically-named literary journals. Since then, I’ve felt increasingly passionate about encouraging other writers and creatives to code — and to get just as excited as I am about the future of the web.

Getting your hands dirty with the fundamentals of HTML and CSS can make it easier to build or update an online portfolio. Or be the gateway drug to interactive storytelling experiments and even unconventional adventures in data-driven journalism, such as The Pudding's exploration of how women's pants pockets are inferior.

But that’s not what I want to talk about. There’s something far less sexy that I don’t think gets the discussion it deserves. And that’s the relative impermanence of writing on the web.

A year ago, I was saddened to discover that The Awl and its sister publication — The Hairpin — would be retired after nearly a decade of championing incredibly weird and honest and often brilliant approaches to journalism, including the all-caps filled “existential advice column” that many of us know and love as Ask Polly.

News of The Awl’s departure has since been followed by the shuttering of several other influential independent digital publications: including Lenny Letter, Racked, and Rookie. Other players are in the midst of dramatic evolution. Mic was recently sold to Bustle; Tin House and Glamour have both bid farewell to print publication; and The Great Discontent went up for sale last November.

That’s a lot to digest. But I think it’s relevant. Because I know from experience that each time publications like these reach a tipping point of financial instability, or otherwise evolve, the future isn’t always bright for previously published work.

Not just because it’s expensive to keep all the lights on. Often, the underlying platforms that support the stories we love are just obnoxiously, unbelievably bad.

{: .article__hr}

Several years ago, I wrote for a magazine that made a strategic shift from print magazine to digital media, online-learning-oriented platform. Since the shift happened, it’s become an uncommonly successful story of pivoting to video. But when the relaunch of the website happened, much of the magazine’s previous content was missing —

Including a substantial amount of what I’d contributed. Which was heartbreaking, but it shouldn’t have been surprising.

Because the first website I maintained for the magazine was so terrible that it was hard for anyone to discover our content. Visitors couldn’t search for, or even browse, stories that weren’t already highlighted on our homepage. And even if an editor wanted to find something specific, say for an email newsletter or social media post, they’d be forced to login to the backend of the website and use a search function that was the digital equivalent of Charlie Brown attempting to kick a football.

Whenever I tried to use it, more often than not the website would just burst into flames spit out an unintelligible error. But not always — sometimes it would work. After eight. Or nine. Or possibly ten tries. So I’d get an error and hit the back button and then keep hitting submit on the same search query until I finally got results.*

(*Not necessarily accurate ones.)

The Wordpress website that followed wasn’t much better. So I don’t blame anyone for deciding to call it quits and start over, with only a hand-picked selection of content.

{: .article__hr}

Yet it doesn’t have to be this way. If writers and editors learn to code — or get more comfortable with researching relevant technologies — we can become more active participants in conversations about what tools we should adopt for future projects. We can weigh the pros and cons of a particular platform, and ask questions about how closely it's tailored to our actual needs.

We can discover new approaches to publishing content on the web, in a way that makes it easier to separate content from code. We can even save ourselves from the headache of using databases to maintain that content, which is certainly the dumpster fire causing a disaster for someone in media at any and every given moment.

We can also avoid relying on platforms that make it difficult, if not impossible, to casually export or otherwise own the content we create.

We can stop worrying about how our choice of CMS might impart a certain, unmistakeable smell and affect the pre-baked appearance of our publications — or limit our ability to pursue unconventional approaches to storytelling.

And perhaps most importantly, we can advocate for software development teams that prioritize accessibility, and speak up when the problematic leadership of an incredibly popular tool makes it unfortunately clear that his team does not.