It's us in the industry who need to be able to code

I have a dreadful confession: I still use my fingers to do mental arithmetic. After a couple of decades in the commercial world I can do sales-minus-cost-of-sales-all-over-sales-equals-margin in my sleep, but ask me 14-plus-27 and I’ll tap out the four, just to be sure.

So given this pitiful natural capability, coupled with an arts degree (archaeology, and not the statistical, analytical sort, but the vague hand-wavy these-sticks-signify-an-ancient-rite-of-passage kind), you wouldn’t think I’d find myself a professional Ruby on Rails programmer at the age of 40.

Yep, I’ve done my ten thousand hours. Since 2011 I’ve spent an average of eight hours a day practicing and writing SQL, Ruby, Rails, Javascript, CSS and HTML.

I might be useless at arithmetic, but, you see, I love patterns. I’m a pianist and an artist. I like words, symmetry and brevity. Writing code trips many of the pleasure centres in my brain. And I love feeling that I’m doing something meaningful, creating something out of nothing. Plus the inherent difficulty of writing good code is a source of huge pride.

I’m also someone who is fairly bloody-minded and determined, who can’t stand doing a boring task more than once – and I’m an independent publisher, which is not a subset of the population known for its great wealth. Given a choice between finding £150k to get someone to turn my ideas into code, or just reading the big thick technical books and putting the hours in, the decision is not hard.

The main reason for spending so much time learning to code, though, has been the desire to solve an urgent problem. Ever since I co-founded Snowbooks in 2003, I’ve wanted a system to help me manage the business in the way I think necessary – with all my data in one place, with an absence of duplication, with as little data-entry effort as possible – to rescue me from organisational chaos. I have always wanted computers to do the drudge for me so I can get on with publishing, with cover design, with imagining new ways to sell books. In other words, I want to be a creator, not an administrator.

Who goes into publishing so they can spend their days typing metadata into spreadsheets, and PubWeb, and InDesign AI templates?

Integrated systems that cover metadata, ONIX, production, royalties, contracts, rights, permissions, schedules – everything, really – do exist, but you’ll have to remortgage to afford them. So I’ve been steadily writing my own system which is all this and more, and after four years of active development, with a growing team of programmers, it’s rather wonderful. Have a look at Consonance.com to see the fruits of our labours.

Ten thousand hours later, I have magic fingers! I can think of an idea for an app, or a website, or a little program to help me automate a boring task, or receive a feature request for Consonance, and presto – I type the code. No briefing people. No meetings to agree the agency budget. No fighting for sign off. No trying to explain my idea to a developer with mounting frustration on both sides because we’re speaking different languages. I just get on and write the code. And enjoy the results.

I now occupy this zone where I know plenty about both trade publishing, and plenty about code.

You know that weird feeling when your parents turned up at your University? The sensation that your life at University is completely separate and other to your family life, and it’s just plain weird when the two worlds collide? I get that when I’m talking to most publishers about code, and most coders about publishing. There is barely any intersection between the two sets at anything other than a buzzword level. And when there is, those people are remarkable. To name a few, Nick Barreto, James Bridle, Xander Cansell: publishers who code can do amazing things.

To the coders, I’d say this.

You should learn more about publishing. Too many apps exist because their creators thought the code would be cool. The code probably is cool, but you walk the aisles at the book fairs and see that no-one’s clamouring around the stand of yet another ebook delivery platform. The SaaS build-it-and-they-will-come model only works, rather obviously, if you build something that people want in the first place. So:

Start a little micro press.
Try to sell a book in to a high street retailer.
Pick apart a printer’s scale.
Write a royalty statement that doesn’t confuse your authors.
Try to update the Ingram metadata spreadsheet programmatically.

You’ll end your first week as a publisher with a hundred ideas for solutions that will answer an actual problem. Completely Novel and Valobox are a good example of this. The team know all the real-world details of working with authors, printers and so on from running their Completely Novel self-publishing platform. It means their pay-as-you-go venture Valobox was developed out of an on-the-ground understanding of the industry – and it shows.

To the publishers, I’d say this.

There is no shortage of ideas for ways that a little – or large – program can make publishing better. Our industry is built of data:

Descriptive metadata
Sales data from a huge range of sources
Reader data
Online campaign data
The words we publish and the way they’re structured into larger sets of content

It’s all there waiting to be corralled and explored and arranged in patterns which help us to be better publishers. And if we don’t learn to use all the technical tools that exist, then outsiders will build things themselves. We’re seeing that now, and we’re seeing that the things they’re building, whilst interesting, are just a shade off the mark, because they don’t know publishing like we do.

Given the data-y nature of the book trade, the fact that learning to code is so astonishingly moreish, and the fact that I’m living proof that you most certainly do not need a computer science degree to write a FutureBook Innovation Award-winning web application, I’m hopeful that I’ll be able to persuade publishers that becoming adept at code-writing is good for business, good for your teams, and good for the long-term health of our industry.

You don’t have to go as far as me.

Learning the fundamentals would be enough for you to have a decent conversation with a developer. The benefits are clear: you’ll know what’s technically possible, more or less, so you’ll both save time and energy. You’ll be able to tell if the developer is responding sensibly to your specs, and you’ll know enough to be able to look at his or her proposal and cost estimate and see if it’s reasonable.

But I bet the bug will bite you (heh, amusing code-related joke). I started out being interested in code when I took an ONIX message and used it to create a catalogue automatically in InDesign. Technically, it’s not difficult: you set up a template tagged with placeholders, and import the XML into those placeholders. But psychologically, it’s revelatory. I created hundreds of pages of catalogue copy in a single click. How long does your catalogue creation cycle take? Three months? Four? Wouldn’t you rather spend that time learning enough to automate the awful job the once, so you never have to do it again? I don’t know how anyone can stand to do some of the repetitive tasks that I see them do, when I know that you could spend a month, a week – even a few days – learning plenty to save you from death-by-admin. Once you’ve glimpsed what code can do, it’s really hard to go back.

Something which afflicts all industries is the problem of getting systems to talk to each other. But the problem is solved! Just not by the book trade. As an industry we are really backward in this, you know. There are all these spreadsheets and CSV files and FTP folders that even the largest companies still use to transfer data slowly, brittlely, between distributor, ecommerce, metadata, royalties, rights, CRM and other publishing applications. Modern APIs are clear, well-documented conventions for getting applications to talk to each other. It takes a morning to write a simple, brief JSON API, and a month to test and iterate. But there are only a handful of well-maintained book APIs around – for example, Amazon’s Product Advertising API, Goodreads’, Google’s, one or two from the larger publishing companies (and Consonance’s, of course). You look at something like accounting software Freeagent’s API, and it’s enough to make a grown man weep – you can do so much with it and it’s beautifully documented. If the accountancy industry can do it, so can the book trade.

This is an opportunity to draw a line against the relentless outsourcing of skills.

As an industry, we’re really running the risk of limiting our scope to being middle-men.

We often don’t write the books, or proofread them, or typeset them, or take the photos, or draw the illustrations, or create the ebooks, or code the apps, or print the things, or store or ship the books ourselves.

Our industry has been outsourcing everything we possibly can for years.

With code, we have a chance to take back control.

You don’t need the sort of money you’d need to set up a printing factory to bring print back in-house. You especially don’t need to hire in Rails developers on a £80k annual salary. That wouldn’t fix the problem. The problem is that it’s us in the industry who need to be able to code. You don’t know how many more books you can sell, how many more readers you can engage, how much more justice you can do to your authors’ writing, until you have the technical knowledge to create the new tools and new applications that no-one’s thought of yet.

Where do you start? You can do the free Rails course at Codeacademy.com. Follow that, and by the end you’ll have written your own version of Etsy. Or you can buy a book for $49 – The Rails Tutorial by Michael Hartl – and spend a day a week on it for six months. By the end of six months, you’ll have written Twitter. Yep: you’ll have actually written your own version of Twitter. With your own human hands.

If you don’t want to read a book (and I needn’t point out the irony of that) then come along to the course my Consonance colleagues and I run called Try Programming. The Consonance team also volunteers at London RailsGirls, which is a brilliant way for women to get experience of coding. Your kids are learning how to code. So should you.

And HR can start changing their recruitment requirements. Can you imagine asking your editorial assistant applicants, at interview, what marketing initiative they would propose given a 120,000 word manuscript, 25 illustrations, a command line, a text editor and a Github account? That probably sounds outlandish. It shouldn’t.

One of the many lovely things about coding is that it’s a proper, cerebral activity that doesn’t necessarily suit a 9-to-5 office location. It requires intense, prolonged sessions of quiet thought. It’s ideal, in other words, for working parents who can work between school runs from 10 a.m. to 3 p.m and then from 8 p.m. to 11p.m. If you’ve any desire to improve your company’s flexible working capabilities at the same time as generating new revenue streams and increasing your creative output, get your staff to learn to code.

From where I stand, it terrifies me that there is so much opportunity for the book trade, and such a dearth of skills to take advantage of it, with apparently little appetite for change.

Make this year the year that you learn to code – for the sake of our industry.

Originally written for and published by The FutureBook

Are your current systems sabotaging your growth ambitions? Are you hungry to implement new business models, but concerned you lack the strong administrative foundations needed for innovation?

We're always amazed at how resigned publishers have had to become to the low bar in publishing management systems. Demand more.