PUBLISHED MAY 2015
by Emma Barnes, Publisher, Snowbooks
I have a dreadful confession to make: 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 14, just to be sure.
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 centers in my brain. And I love feeling that I’m doing something meaningful, creating something out of nothing. Plus conquering the inherent difficulty of writing good code is a source of huge pride.
I’m also an independent publisher, which is not a subset of the population known for its great wealth, and I’m someone who is fairly bloody-minded and determined, who can’t stand doing a boring task more than once. Given a choice between finding hundreds of dollars to get someone to turn the ideas for my apps into code, or 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 cofounded Snowbooks in 2003, I’ve wanted a system that would rescue me from organizational chaos and help me manage the business in the way I think necessary—with all my data in one place, with an absence of duplication, and with as little data-entry effort as possible.
I have always wanted computers to do the drudgery 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, and after four years of active development, with a growing team of programmers, it’s rather wonderful. You can see the fruits of these labors at Bibliocloud.com.
Ten thousand hours of work, and now 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, and presto—I type the code. No briefing people. No meetings to agree on the budget. No fighting for signoff. No trying to explain my idea to a developer with mounting frustration on both sides because we’re speaking different languages. I just write the code. And enjoy the results.
I now occupy a zone where I know plenty about trade publishing, and plenty about code.
You know that weird feeling you got when your parents turned up at your college? The sensation that your life there was completely separate from and other than your family life, and that it was just plain peculiar having 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 groups at anything other than a buzzword level.
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 if you walk the aisles at the book fairs, you’ll see that people aren’t clamoring around the stand of yet another e-book delivery platform. The build-it-and-they-will-come model works only, and rather obviously, if you build something that people want in the first place.
And 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 on data—including descriptive metadata, sales data from a huge range of sources, data about readers, data about online marketing, and data about 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 that will help us be better publishers. And if we don’t learn to use the technical tools that exist, then we will have to rely on things outsiders build—things that are a shade, or more, off the mark, because they don’t know publishing the way we do.
In light of the data-heavy nature of the book trade, the fact that learning to code is so astonishingly addictive, and the fact that I’m living proof that you do not need a computer science degree to write a FutureBook Innovation Award-winning web application, I’m hopeful about persuading you 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 I did. Learning the fundamentals, either by reading technical manuals or attending a course or two, will let you have a decent conversation with a developer, and 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 be able to see whether the developer’s proposal and cost estimate are reasonable.
But I bet the coding bug will bite you. I started out being interested in code when I took an ONIX message and used it to create a catalog 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 catalog copy with a single click. How long does your catalog creation cycle take? Three months? Four? Wouldn’t you rather spend that time learning enough to automate the awful job 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 they could spend a month, a week—even a few days—learning plenty to save themselves from death-by-admin.
Once you’ve glimpsed what code can do, it’s really hard to go back.
Resources and Rewards
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, an e-commerce site. Or you can buy a book for $49—Michael Hartl’s breathtakingly masterful tutorial for learning Ruby on Rails (go to railstutorial.org/book/beginning#sec-prerequisites) 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 access materials for the course my Bibliocloud colleagues and I have offered by subscribing at bibliodocs.com/try_programming.
All industries have had the problem of getting systems to talk to each other. But the problem is solved! Instead of using all those spreadsheets and CSV files and FTP folders to transfer data slowly, in brittle pieces, among distributors, e-commerce platforms, and publishing applications for metadata, royalties, rights, CRM, and more, you can use modern APIs. These clear, well-documented conventions get applications to talk to one another. It takes a morning to write a simple, brief JSON API, and a month to test and iterate. Have a look at this BookMachine article to see how easy it is: bookmachine.org/2015/01/28/publishers-guide-apis.
True, 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 Bibliocloud’s, of course). Still, you can use them to draw a line against the relentless outsourcing of skills. Our industry has been outsourcing everything we possibly can for years. By mastering code, we have a chance to take back control.
Also, we have a chance to reshape our personnel policies. One of the many lovely things about coding is that it’s a 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 parents who can work between school runs and then after children’s bedtimes. So if you’re interested in improving your company’s flexible working capabilities while generating new revenue streams and increasing your creative output, don’t just learn to code; get your staff to learn to code too.
Emma Barnes has spent 12 years at the helm of Snowbooks, an award-winning, independent trade publisher, and she now offers Bibliocloud, a FutureBook award-winning “all-in-one publishing solution.” A version of this article appeared in The Bookseller’s Futurebook (see thebookseller.com/futurebook/emma-barnes-its-us-industry-who-need-be-able-code). To learn more: email@example.com and bibliocloud.com.