Post from http://www.danieluk.net
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.high_price_band
where price > 10
end
=> Book.high_price_band
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.
Digital Book World
Publishers Can Learn a Few Things from Programmers http://www.danieluk.net/news/publishers-can-learn-a-few-things-from-programmers-2/ #Books, #Content, #Publishing, #Software, #World
As both a publisher and a programmer, I’m a member of a very select club.
