As both a publisher and a programmer, I’m a member of a very select club. I’ve been struck by many similarities between the worlds of code and publishing. And I believe that being able to identify and act upon them has made me a better publisher.

I wrote this article about programming for DBW in February 2015. Read the full article at Digital Book World.

As both a publisher and a programmer, I’m a member of a very select club.

It consists of both those who started out as coders and went into publishing and those who did the reverse. I’m in the latter group, having co-founded a little indie press called Snowbooks in 2003. When I needed a system to run the company and found the software on the market both hugely expensive and horrible to use, I buckled down and learned to code. The result was my own back-office publishing management software, called Bibliocloud (which, delightfully, lots of publishers now use).

Admittedly, it took about a decade. But along the way, though, I’ve been struck by many similarities between the worlds of code and publishing. And I believe that being able to identify and act upon them has made me a better publisher.

Coding has a fairly long learning curve. With about 10,000 hours under my belt, I’d put now myself at the ‘adequately competent’ stage on a spectrum of capability that starts at ‘complete novice.’ The other main developer of Bibliocloud—a chap with more than twenty-five years’ experience at Oracle—is right up at the ‘super-productive expert’ level at the top. From where I am at the moment, though, I’m good enough to see the beauty in code, just as I can see the beauty in any writing.

You may never have written code, but you’ve read books. I bet you’ve appreciated the clarity that comes from brevity, or the careful crafting of a narrative flow, or the finely-edited end-result of a piece of prose, honed and whittled and buffed to perfection. So it is with code.

Writing—whether code or prose—is a craft, an art. Code, perhaps even more so than prose, is an expression of the author’s personality and philosophy. Some publishers turn their hands to novel writing. I don’t have a novel in me, but I did have a two-hundred-thousand-line Ruby on Rails application, it turns out.

Some code, to me at least, even reads quite literally like poetry. Here’s a Ruby method:

def self.highpriceband

where price > 10

end

=> Book.highpriceband

Read it out loud and it’s almost a haiku:

def self, dot high price band,

where price is greater than ten

end; call Book dot high price band.

If there are similarities in writing—whether it’s code, prose, scholarship or even poetry—there are also comparisons to be drawn in how we get it ready for publication or deployment.

Some code can be dashed out, fit to prove a point or get to the Minimum Viable Product stage. I look with some cynicism upon weekend-long hackathons, knowing from experience how much reflection, effort, testing, iteration and planning is needed to produce a really strong, dependable piece of code. In the same way, we have bursts of hurried activity in publishing: We’ll wallop out a series to fit with something newsworthy, or with a new course, or some other time-based tie-in.

But the best publishing comes from a strategy—from well-thought-out, well-planned, purposeful publishing. From bringing forth books because we know there’s a market for them. From publishing into a space we understand, and by using our in-depth knowledge of genres and insights from audience research to reach our readers on their own terms.

In fact, that’s one area where some programmers could learn from publishers. More apps and start-ups would succeed if they came from a real understanding of the market, rather than because the programmer thought the code would be interesting and fun to work on. That said, many programmers seem to be great at understanding why they’re doing something and continuously asking whether it’s a good way of doing things.

I like what coding has done to my brain. After thousands of hours of forcing it to do new things, I can more skillfully break down a problem into its parts, work through each part one by one and build or rebuild a solution. Mental agility is something you have to work hard at, and that’s true as well for organizations struggling to innovate and iterate quickly without falling to pieces. Coding is great for this.

Programmers, I would say, are more naturally inclined toward long-term productivity than publishers. We’re lazy and tend to get bored easily. We would rather spend a week writing some code to automate a ten-minute task than repeat it every week for a year. And so programmers have some conventions: DRY—don’t repeat yourself—is a good one; YAGNI—you ain’t gonna need it—helps you to figure out which code should be written and which is optional.

Convention over configuration—a way of getting the basics organized and routine so you can focus on the interesting, creative, new aspects of things. If publishers had zero tolerance for repetition and boring administrative tasks, what would the industry look like? And how would publishers’ organizations reflect that internally?

Having admired convention, there’s nothing to stop individual coders going right against convention and doing something totally different. The Linux operating system, the programming language Ruby, the web development framework Rails all came about because one person decided there was a better way to do something.

There’s an all-pervading attitude of continual improvement in programming. Take a look at Github, the code repository used by most programmers to save every iteration of their work. Repositories have thousands of incremental changes and edits. Programmers naturally hone and whittle and constantly improve. They automate the dull stuff so they can think about the bigger picture.

Yet within both sectors, there’s an attitude that prizes craftsmanship and best practices, proving these impulses—to innovate boldly and to hold small, familiar things precious—can be powerfully complementary, not mutually exclusive.

Since code is also the thing that generates what users know as software, we can think of code as a metaphor for the way we go about producing our books. The way it typically works today, programmers write the code, which then runs to produce a user interface, like a website, generated from HTML behind the scenes. In one, you can have horrible, clunky code producing a fairly decent-looking user interface, to an extent—but push it too much and it’ll slow down and generate errors, and it won’t scale well.

On the other hand, lovely, elegant, thoughtful code produces solid, dependable, beautiful software. With publishing, I think that you can get out what customers experience as a serviceable book (print or digital), where the content is great and the production value high, yet if the process of getting that book out was horrible and confused—if it was all swan on the surface but frantic paddling going on underneath—then that’s not scalable or sustainable, and there are bigger problems that need addressing. You should take as much pride in the way you produce books as the books themselves.

All the value and characteristics I’ve discussed—clear thinking, automation, productivity, continual improvement and craftsmanship—are baked into programming’s core. But these aren’t just skills we can extract and apply to our own world. The best way to develop these attributes—if they sound like things you indeed want to value—is to practice code. Become a developer. Face the intricacies, the struggles, the delicious, aggravating complexities that code, like nothing else, provides.

When you know what you can do with code—when you know what’s possible, when it’s obvious that you should automate something or integrate with another system or write a new protocol for describing an interesting way to reach readers—even (and especially!) if you need to ask more practiced programmers for help—you’ll have the strengths of programming on your side.

Archives

    Most popular

  1. Ruby code and why you should care
  2. A quick look at data visualisation and analysis
  3. Learning how to code, the long way around
  4. It's us in the industry who need to be able to code
  5. Menial publishing jobs are destroying our future
  6. A manifesto for skills
  7. Company news

  8. New website
  9. 2018 Customer survey report
  10. 2017 in review
  11. Prizes galore
  12. And now we are five
  13. Sara O'Connor to join the team!
  14. Product news

  15. 'Continuing to solve real problems': Futurebook 40, London Book Fair 2018 and the Works page
  16. How many authors is too many?
  17. Better ONIX fragments
  18. Advanced advance information!
  19. Schedules page
  20. Publishers hack their own bibliographic data
  21. Case studies

  22. Burleigh Dodds Science Publishing
  23. Zed Books
  24. IOP Publishing
  25. Code

  26. What publishers need to know about Ruby on Rails
  27. A publisher’s guide to APIs
  28. A day in the life of a programmer
  29. How APIs can make publishing more efficient
  30. eCommerce

  31. To go direct, publishers must mean business
  32. Why publishers must use direct sales
  33. Inbound marketing
  34. Don’t outsource your publishing business away
  35. Who has the balance of power over data?
  36. The business case for going direct
  37. ONIX

  38. A hidden benefit
  39. Thema Subject Codes Update November 2017
  40. ONIX. Not very standard
  41. Three ways to do more with ONIX
  42. A non-technical, beginners’ guide to ONIX for Books
  43. How to create a catalogue automatically using ONIX and InDesign
  44. ONIX Changes
  45. BIC, Thema and artificial intelligence...
  46. Skills

  47. Publishers can learn a few things from programmers
  48. Mechanical sympathy
  49. A taste of code
  50. Embrace the code
  51. Strategy

  52. The right tool for the job
  53. The search for publishing's holy grails
  54. Decisions, decisions
  55. Rejuvenation
  56. No computer system can fix a broken publisher
  57. Responsibility, Authority, Capability
  58. Start with Why – How to refine your publishing mission
  59. Creative industries and the division of labour
  60. The real price of a strategy shift
  61. Technical debt
  62. Why ‘easy’ publishing solutions hardly ever are
  63. Five things I've learned since moving into enterprise product management
  64. Managing expectations
  65. A company of one's own.
  66. Sometimes, size matters