Posted by Jacob Harris
Wed, 13 Dec 2006 13:56:00 GMT
And now for the second post in this minor series All The News Fit To Serve wherein the blogger attempts to parlay a passing knowledge of the newspaper business into an exploration of how newspapers might change in the Web age. As it should go without saying, these are my opinions, and do not reflect any thinking at my employer or any actual strategy being taken there. Just needed to clear that up. That said, on with the show! This post’s theme: advertising, or how “old media” is not so much different than new media when it comes to bringing home the bacon.
Analyzing the newspaper business today is a study in contrasts. On the one hand, print circulation continues to decline and the recent drop suggested a more extreme decline may be in the future. Net wisdom decries newspapers as ailing dinosaurs doomed to extinction by 2014.
On the other hand, papers still enjoy healthy profit margins and often monopoly status in local markets that gives them an advantage in covering a local area unmatched by anyone. Still, newspapers have seen some unsettling drops in readership and the decline in classifieds might be a troubling portent. On the other hand, newspapers are far from finsished and the warning signs have actually helped some papers to retrench and repair wasteful processes. In terms of readership, ewspapers still enjoy esteemed and privileged positions in their local markets that are still worth a lot, but Wall Street is alarmed whenever at the anemic growth or even retreat many papers are suffering. Putting it more simply:
- The glass is half full
- But the water level is dropping at an accelerating rate
And now every paper is trying to figure out how to refill the glass. But why is declining readership such a concern for newspapers? It helps to understand how the business operates.
You might assume that papers are supported largely by subscription fees and the decline in print readership is troubling because of decline in that revenue. But for many papers, subscriptions only offset delivery and printing costs; indeed, it is possible for some small urban papers to even make a business giving away their product for free! Rather, subscriptions have the unusual property in that they are meaningless as money, but essential as a quantity. Because the real value of circulation is to set the advertising rates.
Like many Web sites, the dominant driver of revenue for newspapers is advertising. Of course, there are sometimes a few other minor revenue streams (licensing, royalties, books), but advertising is such a dominant revenue source that you can directly gauge the health of a paper by the advertising rates it can charge. And since the value of an advertising in a paper is largely determined by the size of the audience it reaches, advertising rates (and advertising profits) are directly influenced by the circulation of the paper. Advertising has been exceedingly good for newspapers – the total ad market for papers is estimated at $45 billion – but the writing is on the wall. Classifieds (another form of advertising) have already precipitously declined, and it’s only a matter of time before commercial advertisers follow suit. The party is over; this is why the papers are getting scared.
There is some good news on the horizon though. Internet readership of papers has been climbing steadily and ad rates are expected to continue increasing at a phenomenal rate – next year, internet advertising is expected to increase by 29% while traditional media advertising will increase only an anemic 1-2% – and some papers like the New York Times have built online web sites that reach a global audience and dwarf the readership of their printed versions. A lot of geeks read these trends and argue that papers should save themselves today by discarding the printed product and surviving off websites only, but such a move would only be suicide for any paper foolish enough to try it today.
The catch is for all its promise, Internet advertising is nowhere near the profitability of print advertising – optimistic estimates suggest it might be there in 10 years. This gap is simply stunning to casual pundits like me who think the Web is a ready equivalent to anything in traditional media. Why is this disparity so great? I think it has to do with a few different factors. One possibility is that Internet advertising is not attractive enough to traditional print advertisers yet, perhaps because of its perceived limitations (you just can’t buy a flashy three-page spread in the first few pages of the Magazine online). In addition,
unlike print advertising, no single entity has a monopoly in a local ad market on the Internet. Which belies another difference between the two ad markets: the print version is local, the web version is global. I think it will take a while for some advertisers to want to reach the latter.
All is not bad for for Web advertising however. As stated before, web ads are able to reach sheer numbers of people inconceivable for any print publication today and at all times of the day and night, so some profits might be made in volume. Newspapers could also conceivably farm out web advertising to outside sources too who might have a better chance selling to Internet-savvy advertisers (Google is certainly hoping for this). The main advantage of online advertising in the long run will prove to be demographics however, and how intelligently newspapers are able to target them. The audience for a print ad can only be considered as an aggregate average, since the same ad goes to every subscriber, be they rich or poor, urban or suburban, dog owners and/or video game players and/or coffee drinkers. But the beauty of Internet advertising is that you can target the ads to the consumers more likely to respond to them – I am still talking about marketing to aggregate groups and not individuals (that gets a little too much into privacy), but the groups are much smaller here. This might make Internet advertising rates eventually exceed those of print ads. Newspapers would be foolish to ignore this opportunity. Which is why every newspaper at this point seems to require users to register. As an anonymous reader, you’re worth so very little to advertisers; as a 27-year old female from the Midwest, you (as part of an advertising group) might be worth much more. More readers and better marketing might help to make up for the decline in print readership.
But the real kicker is that for many newspapers, the website will never be able to close the gap.
Online readership growth for any paper must eventually reach a stable plateau where it starts to level off. How do you increase readership to greater levels beyond that? One possibility is to increase the paper’s website to be more than the news. The New York Times has followed this idea and unveiled sites for interactive applications like movies, travel, and home finance. Another possibility it acquiring outside media sites like About.com (NY Times) and Slate (Washington Post). This helps to some degree, but it can also seem like developing portals in an age where portals are no longer relevant. Personally, I think the opposite approach might be the wave of the future. Stop expecting your readers to live their online lives at your websites and distribute your content to them all over the web. But that’s a topic for the next post.
Posted in Web, Newspapers | Tags advertising, newspapers | 1 comment
Posted by Jacob Harris
Wed, 29 Nov 2006 21:01:00 GMT
Here in New York, it’s routine for people you’ve just met to ask you what you do for a living (we inquire about rent when we get to know each other better, about 10 minutes later). As interesting as it was at Alacra, most people’s eyes would start to glaze over when I summarized the various minutiae of reselling financial information online (I eventually learned to describe it through the metaphor of a grocery store). But everybody knows about the New York Times, and I can almost visualize the cascade of associative thoughts—complete with press passes tucked in fedoras, people shouting at each other in a news room, and the obligatory spinning newspaper transition. This then leads right into the next question: that’s the newspaper, but what do you do at Times Digital that’s so different and special? Not much for the moment, and that’s a problem.
The lion’s share of traffic to the New York Times Digital goes to www.nytimes.com, which is largely just a reformatting of the printed paper for a web audience. Sure there are some additional applications specific only to the website (eg, you can search through movie reviews and we now have videos), but you could easily miss them, since the focus on presenting a cohesive look that mirrors the printed product all but guarantees that anything truly exclusive to the website will never be allowed to stand out. Indeed, one might get the sense that the management of the Times thinks of the Web as merely another printing format, rather than a completely different medium in its own right. Despite the fact that online readership obliterates the print subscribers these days, I would honestly be surprised if any newspaper’s editorial board contained a member who only read the paper online and “understands” the web. Furthermore, even “understanding” the Web does not entail grokking how savvy readers browse the paper online—how many newspaper editors know what a tabbed browser is for instance? or why single column is preferable to users with scroll wheels on their mice? My guess is not many. These sort of blind spots are not much of a big deal to those who want to just maintain the status quo in a new marketplace (and how mostly see the online paper as merely a convenience for people on the go), but I think there are so many unique web-only opportunities being missed out that newspapers need to grasp. And I’m going to write the next few blog posts on some ways in which newspapers might uniquely evolve online. I think the problem is not so much the people, but the cultural mindset needs to evolve a new notion of what newspapers are and how the public interacts with them. In the next few posts I will explore some ways in which the notion of newspapers might change online and how that might affect the news of tomorrrow.
But first, a few disclaimers. I’m not singling out my employer only for ridicule. Many of the problems the Times faces in the Internet age (declining readership and a demographic that’s skewing older) are striking the industry as a whole. Also, unlike some smaller regional papers, the Times has been working hard to position itself as a global news brand both in print and online, which could make all the difference between success and failure in any new web ventures. And the paper side of the operations here does at least recognize that something must be done to reverse the slide in readership and profitability and integrate the web and newspaper operations more tightly (although they don’t quite know what that might be). But the New York Times does share much of the mindset current to the newspaper industry, and I do work here, so it’s too easy for me to single them out for examples indicative of newspapers as a whole.
Also, I am not a media analyst or expert in how the newspaper business works. I do not have a journalism background and I do not even have a lot of experience working in a newspaper environment. I have never visited a newsroom and even navigating the old building’s corridors to visit the credit union or get a photo ID left me as bewildered and confused as a tired old man. It’s possible I’ll gloss over something momentous or overstate something glib. But I do think I understand the Web and how people use it and I will treat the idea with more seriousness and depth than the usual buzzwords when geeks try to reinvent the newspaper business. Hopefully it’ll be good, but as always let me know how you feel in the comments.
And finally, I do believe there is a place for newspapers in the Web world and I am working here at the Times mainly because I am interested in being a part of developing new refinements of a business model that’s been unchanged for hundreds of years
That said, on with the show! Newspapers online are rather limited, what are the ways they can change and embrace the web? I will be following up with four further posts organized into distinct but overlapping themes:
Notice how I started the latter three with ‘D’ to be extra clever. Those will link to the further posts when they are published, but stay tuned and watch this space.
Posted in Web, Newspapers | Tags newspapers | 1 comment
Posted by Jacob Harris
Fri, 10 Nov 2006 21:39:00 GMT
So, if you’ve been checking on my blog lately, you might have noticed I’ve been rather lame about blogging lately (as opposed to before when I was somewhat lame). Sorry about that, I can promise I’ll try to change, but I have a lot of stuff going on in my life that doesn’t involve sitting in front of a computer. Mainly, this:
Yes, that’s right. I’m going to be a father for the first time (expected due date: May 9th). Now that we’ve passed beyond the first trimester superstitiousness and jitters, I want to tell the whole world. Thanks for reading, and hopefully I’ll write something else for you one of these days.
Posted in Meta | 4 comments
Posted by Jacob Harris
Wed, 27 Sep 2006 20:08:00 GMT
Wow, long time no blog. Work and home life have just sucked all the mental energy out of me lately. For those of you who still have kept me in your feedrolls or click here from time to time, I have a new set of slides presented for your personal enjoyment.
Last week—transfixed by the horror of an empty slate of speakers—I decided it was time to give another talk to the NYC.rb and so I spent a few days throwing together a presentation I titled Or You Can Cheat. It’s all about how you can write C extensions for Ruby and also how this something you shouldn’t undertake lightly. I have a very interesting approach to presentations: when I want to learn more about a subject, I throw together a presentation on it. I think the combination of casual interest and the abject fear of humiliation in front of my peers is a great personal motivational tool. This talk continues that trend, and while I can not claim to be a definitive expert on C extensions for Ruby, I certainly know a lot more about the subject now and I think you will too.
If you are interested, you can download the talk here
Or You Can Cheat (600K PDF)
This is a bit more silly and off-the-cuff than Rubyisms in Rails, and I really enjoyed it. There are a few references I should clarify though. First, there is the matter of arepas. The arepa is the official food of NYC.rb and it is a rite of passage here to take visiting Ruby eminences to our official supplier, the Caracas Arepa Bar. Asides from being addictively tasty, arepas serve as a perfect metaphor for Ruby extensions, in that they wrap the tasty ingredients inside a pragmatic corn flour shell. They really are that tasty. Yes, I also suppose I was a bit harsh calling Joel Spolsky a troll, but I had no other term to describe his wild extrapolation that current Ruby interpreter performance augurs that Ruby will always be slow, that Rails is a horrible web development framework, and how you should shackle your entire development environment around the slowest part. But he is right that Ruby currently is slow for some uses, and C exensions are a potent way to resolve those edge cases without throwing in the towel.
And yet, I hope you’re not dropping everything to write them.
Why the lukewarm recommendation? Well, I think Ruby performance has become an all-purpose scapegoat these days. In some cases, this is deserved (we need YARV. Now.), but it’s all too easy to blame Ruby when the real problem is your web server, your database, or some stupid algorithm you wrote that’s wildly inefficient. Rule all that out first before you dive into C extensions for Ruby. Because C is dangerous, C is tricky, and C is just plain no fun. C extensions can be like eating an arepa filled with broken glass if you aren’t careful. But they also are a useful tool for performance and especially for wrapping existing libraries and legacy code.
Which gets me wondering if there are any cool killer apps for C extensions and Ruby. Are there some cool open-source libraries that would be nice with Ruby bindings? How cool would could a combination of Starfish and RubyInline really be? Would we need to use C extensions to create rbsh, a Ruby shell? What other fun things could you do if you had nice Ruby tongs to keep that nasty C code at bay? Let me know if you have any awesome ideas and if you enjoyed these slides. And in return, I’ll try to see if I can actually blog again one of these days. Thanks.
Posted in Programming | Tags performance, presentation, ruby | no comments
Posted by Jacob Harris
Fri, 25 Aug 2006 23:02:00 GMT
Sorry for the silence. I was on vacation in Alaska recently, so I’ve not really been in the blogging mood. But here is a short note and plea for understanding.
Early reviews (okay, review as I’ve only had one; let me know if you’ve written one or want to do a review) of the ebook have been encouragingly favorable, but the biggest complaints I’ve gotten so far have been about the DRM. I have spoken to my publisher and she’s informed me this was a mistake that was corrected after the first day, and if you’ve been stung with a DRM-afflicted version, we will provide you with a DRM-free replacement. Furthermore, no books in the Ruby Shortcut series will have DRM.
The best way to do this would be to mail me directly and I will pass along your email address to my publisher to send you a replacement copy. My email address is harrisj @ schizopolis.net. It’s probably easier to just click that mailto link above though.
Sorry for the problems. This is a new direction for them and me, and I guess we still had a few kinks to work out. Thanks for your patience.
Posted in Books | Tags drm, rubyisms | no comments
Posted by Jacob Harris
Wed, 02 Aug 2006 16:46:00 GMT
I am pleased to announce that the digital shortcut PDF version (to purchase, you have to go to the Digital Shortcuts page or you can buy it from Safari Sorry!) of my Rubyisms in Rails presentation is finally available for purchase. At 54 pages in length for the low price of $9.99, I guarantee you’ll glean at least 18.5 cents of insight from each page (disclaimer: that’s a mean instructional value; although gorgeous, the title page is not particularly educational in itself).
In addition, the book is also now available in Safari Books Online, and possibly Amazon or other retailers as well. Also, be sure to check out the list of other upcoming Ruby titles.
So, what’s in it? If you’ve read the original presentation, you already have a sense of the scope of material I am covering here, but the shortcut allows me to focus on the material in greater depth. The result is a richer and more thorough examination of the examples presented in the original slides. If you are an intermediate to advanced Rails hacker, you probably know all this stuff already. But if you are a newcomer to Ruby through Rails, or you still find yourself still stuck coding PHP or Java-like Ruby, this ebook might help to align your thinking to the Ruby way.
Will I write another ebook? I’d say yes, but I’ll have to think up another interesting topic. But if you are ever thinking of creating a technical book, I’d recommend starting in a smaller dose like this first. As I discovered, even 54 pages can be a lot of work, and it’s better to test out your time commitments and abilities with something small before you start pitching large references. But that’s a topic for another blog posting. Make me happy: Buy the ebook or read it on Safari and give me your feedback. Thanks!
Update
Fixed purchase link to be go to Shortcuts page (where you can add to cart).
Posted in Books, Web Coding, Programming | Tags rails, ruby, rubyisms | 10 comments
Posted by Jacob Harris
Tue, 25 Jul 2006 17:37:00 GMT
Eight years. That’s how long I have worked at Alacra, starting fresh
out of school in the heady days of the first web boom. Eight years is
an astounding length of time to most programmers, conditioned to a
revolving door approach to employment, and it is a testament to what
an interesting and nurturing place Alacra is that I’ve been here this
long. Furthermore, I’m hardly an anomaly among the developers, most of
whom have been here well over five years too. It’s a place where
people like to stay, and it feels more like a family than an office
sometimes. But I am now leaving. Alacra’s been my only post-college
job, and it’s simply time for me to try something new.
Next week, I will start working at New York Times
Digital. Yes, that New York
Times that is delivered to about 1.5 million readers
in dead tree form. That number might seem impressive in itself, but
50 times that number of users read the online web version, meaning I
will be working on apparently the most popular online news site in the
world. Yow. No
pressure there. Seriously though, I am looking forward to the
challenges and I hope to learn a lot of new skills on the job. The new office building
will also be pretty sweet when it opens.
Still, the change is weird. It’s definitely been a strange two weeks
in this liminal zone, and I am filled with conflicting emotions. I am
sad about leaving all my colleagues at Alacra, but enthusiastic about the
opportunities ahead. It’s an exciting time.
Posted in Career | Tags alacra, nytimes | 3 comments
Posted by Jacob Harris
Mon, 03 Jul 2006 16:58:00 GMT
And now for something different (and shorter, for those recovering from the length of the last post). Insanely talented Internet prankster Rob Cockburn recently posted a short and sweet article Things I Figured Out, where he listed a bunch of interesting and slightly stupid revelations he’s had over the years. This has been followed by 15 pages of reader comments chronicling their own brilliant insights and forehead-slapping moments.
I think this is a brilliant idea for an article, and I’ve certainly had my moments of utter brilliance and sheer stupidity (even this blog probably has examples of both). So, I’m going to post a few of the things I’ve figured out on my own or, failing that, learned the hard way. But since this is a technical blog only, there will be no personal idiocy. Just technical things I now know better about now
- XML is Not For Everything Great for long data files, lousy for configuration files, downright terrible for love notes. It’s not one-size-fits-all.
- XML Is a Minute to Learn, a Lifetime to Master It’s easy to gloss over some of XML’s subtleties when you begin, but they’ll get you later if you aren’t careful. Sadly, very few resources articulate some of the things that’ll get you, but maybe there’s a future blog post about that.
- Somebody’s Done It Better Already I’m being glib here, but one of the joys of Open Source is that if you need a generic component, it’s best to look for someone who’s created it already. For instance, if you need a logger, you could write one on your own, but there are excellent libraries out there and your time is better spent writing stuff you can sell.
- HTTP Blows Away Raw Sockets Unless you absolutely, positively have no choice, there is no reason you should use raw sockets instead of HTTP protocol for remote services. Sure, it might be harder to set up in the short run, but it’s so much easier to debug and maintain in the long run this is a no-brainer. Especially since small, light, and fast HTTP parsing libraries are available for all.
- Often Too Much Is Worse Than Too Little Or as Donald Knuth put it, “Premature optimization is the root of all evil.” I’ve been stung so many times by trying to be clever, I’ve finally realized I should see if it’s slow before I try to fix what ain’t broke.
- Stored Procedures Are Evil DBAs swear by them because they’re supposed to control access and speed up performance. In reality, they move application logic out of your program into an awkward language (SQL) that will usually fall out of sync with your application and aren’t kept consistently in sourcesafe or migrations. Worse still, they’re the trenches for warfare between developers and operations.
- Developers Black-Box Way Too Much It’s too easy to leave this with a cliché admonition to “think outside the box,” but it’s sadly true. As developers, we’re taught early the useful technique of abstracting away complexity within black boxes. This is useful for that third-party API or calling operating systems, but it’s very easy to fall into that trap in your job (“we’ve always done it this way”) or your life (“I’ll just wait for career advancement to come to me”).
- Physical Contact Matters The Internet still hasn’t annihilated geography yet. And personal, physical presence still matters. Meeting people is so much better than emailing them. Which I guess is just a roundabout way of saying, yet again, I should’ve gone to Railsconf. Sorry!
- You’re Going to Screw Up The First Time. Just Accept It. It’s so easy to fall into the fear of not getting it right the first time, you never get started. Get over it. Accept you’re going to make mistakes the first time around and you’ll fix it later and do the best you can. And if you can, write unit tests to make it easier to clean it up when you start.
- Things Break Slowly, Rarely All at Once It’s rare you can pinpoint a single decision or piece of code where everything catastrophically failed. Instead, the road to failure and mediocrity is a gradual and painful process, of many small failures along the way. It’s hard to resist the downwards momentum, because it always seems feasible to reverse. I would like to see more project management texts that tell you how to stop digging that hole.
- If You Can’t Explain It, You Shouldn’t Do It. Sometimes I think half of IT operates by overwhelming your natural instincts and confusion with so much jargon, your brain just gives up. It’s a mysticism of sorts, but the wakeup to reality again is painful. My rule of thumb is if I can’t explain it in plain English using metaphors, and optionally table utensils, then it’s not worth doing. Because it most certainly will not be maintainable.
Okay, that’s all I have so far. But I’m sure the realizations will keep coming. Happy 4th of July everybody!
Posted in Project Management, Silly, Programming, Career | 1 comment
Posted by Jacob Harris
Wed, 21 Jun 2006 00:02:00 GMT
I’ve been thinking a lot about writing lately. There’s been a practical reason — I’ve written an ebook version of Rubyisms on Rails that I’ll tell you more about later — but my motivations are more abstract. I’ve been reading way too many technical books lately. Many have been good, but as one afternoon browsing the bookshelves will demonstrate, most are terrible. As Joel Spolsky exclaims in exasperation in the forward to the excellent book of software essays The Best Software Writing 1:
The software development world desperately needs better writing. If I have to read another 200-page book about some class library written by 16 separate people in broken ESL, I’m going to flip out. If I see another hardback book about object-oriented models written with dense faux-academic pretentiousness, I’m not going to shelve it any more in the Fog Creek library: it’s going right in the recycle bin. If I have to read another spirited attack on Microsoft’s buggy code by an enthusiastic nine-year-old Trekkie on Slashdot, I might just poke my eyes out with a sharpened pencil. Stop it, stop it, stop it!
For Spolsky, the most important ingredient missing from dull technical books is story. As he puts it, good tech writing captures your interest by creating a plausible or interesting story. The resulting text may be much more verbose — in an example, he spins out the insipid truism “a good team leader provides inspiration by setting a good example” into an involved 400 word story — but the story is what makes you want to keep reading more. Looking at some recent purchases, I can see the effectiveness in some notable recent books. In the simplest case, you can go far with a compelling example application you elaborate in each successive chapter like Enterprise Integration with Ruby does.
is built on the solid story of an example integrated in each chapter. It’s not necessary to have one big story, however. You can also structure your book as a sequence of independent smaller stories, as recent favorites Practices of an Agile Developer and The Art of Project Management did so well.
On a contrasting note, Amy Hoy in an article disparaging the suggestion that being a woman is what solely makes her a good writer, suggests another important ingredient is breasts voice. The way to make a technical article compelling is to make it personable. This is something that Joel hints at with his dig at “16 separate writers” and it is something certainly borne out by the selections in the book — practically every selection is a blog posting and is thus opionated, direct, and personal by their very nature — but Joel focuses more on what is being said than how it is said. Voice matters, and nobody has done as good a job asserting the importance of a personal tone than Amy has. But it’s hard for technical writers to understand. When we are first learning to write essays in elementary school, we’re taught to prize dispassionate objectivity above a personal voice. This is not to blame teachers; that makes a lot of sense when you’re teaching writing to fifth graders whose idea of an argument might run along the lines of “This book is bad because I didn’t like it,” and good writers learn eventually to balance their personal opinions and objective fact in essays. Unfortunately, nerds usually aren’t good writers, and I think too many books are written by developers too mortified to express their personalities (even if they could). But if you edit out your personality from your writing, you might as well do your readers a favor and delete the whole book. An example of books that benefit from voice are Martin Fowler’s classic Refactoring and the more recent book Refactoring Databases. Refactoring code is a discussion prone to tedium, but the books succeed because they sparkle with clarity and reflect the single voices of their authors.
Before I continue, I should clarify a few points. Joel’s emphasis on story and Amy’s on voice are not mutually exclusive: I can explicitly emphasize that something happened to me or something happened to me, but both voice and story exist in any compelling technical narrative. The second point is you can only do so much.
There will be always be some dullness that’s unavoidable in technical literature. It’s simply impossible to make some content interesting (ever read a truly fun man page ever?), and if you tried to make it fun, you’ll actually annoy your readers (“Hey kids! Let’s sing the arguments to GCC as a song!”). But a technical book is more than a listing of compiler options or valid function parameter or working code samples. Like introns in DNA, the bulk of any technical work is interstitial material that holds the boring stuff together. And that is where your writing should shine.
Which brings me to my point. I want to draw attention to another important ingredient that complements those two yet gets short shrift: metaphor. To see what I mean by metaphor in action, look at my DNA example from the previous paragraph (I know, technically it’s a simile). Assuming you knew what an intron is — in a book I obviously would explain it more explicitly than a blog post — that aside conjures up a rich web of allusion that clarifies the emphasis of the point (that the bulk of your book might not be technically explicit and yet still be meaningful for the whole). The beauty of metaphors is they evoke all sorts of mental associations in your readers that act like scaffolding (a metaphor) that helps your readers learn material by building upon concepts they’re innately familiar with. And they come with an expressive power that allow you to express complicated ideas succinctly through allusion (ie, instead of having to spell out what scaffolding is used for like I just did, you can just describe it as scaffolding and leave the reader’s brain to fill in the rest).
Metaphors are truly useful things, and since this is my soapbox (another metaphor!), I’ll declare that metaphors are woefully under-utilized in technical writing. I think one reason for this is technical writers are discouraged from metaphor to be more universal — if I make a metaphor specific to New York City, it might fall flat to a reader in Germany or India; not only would I have to explain my technical content, I’d have to explain my metaphor! You can avoid regionalism pretty easily though, so I think the biggest stumbling block is geeks themselves. Mainly, that same literal geek writer that sticks to the facts and recoils in horror from anything that smacks of poetry.
This is a dearth made more unfortunate because good metaphors reinforce both story and voice. If you are boring like me and have no personal experiences to relate, you can fabricate your narrative on the back of a metaphor instead. And your use of metaphor breaks your text out of the dry and technical and provides a place for your unique personal voice to be expressed.
To give an example of this in action, I recently had to explain the virtue of iterators in Ruby for the ebook on Rubyisms. I could describe how they work technically easy enough, but I felt that a metaphor was the best way to explain why iterators make more sense (and given the number of programmers still iterating through array elements in Java, this is something most programmers still don’t understand). So I brought out an unlikely metaphor to anchor why iterators are better: traveling crosscountry on local roads vs. highways.
I’ve described this book as a drive down local roads, but now it’s time to take to the highways. Highways are fascinating concepts. Although they seem like an inevitable part of the driving infrastructure, highways are actually quite new in the history of roads. As recently as the early 1900s for instance, a drive across the country was essentially the same as driving across town, navigating a dense network of local roads that would get you there eventually but not efficiently. Routes were not clearly demarcated, and road maps as we know them didn’t exist. Each driver would have to figure out their own routes, a challenge when navigation comprised only instructions like “take right at third fork in the road” or “turn left at the willow tree.” Of course, getting lost was inevitable. And accidents and mishaps were all too common on neglected backcountry roads. This might seem a cartoonish depiction of long-distance driving, but it’s that’s largely a reflection on just how fast, safe, predictable, and even boring intercity travel has become due to highways. And that’s because the highway changed the very nature of long-distance trips.
Highways are built not from asphalt and cement, but from limitations. Instead of connecting to every road, a highway runs largely isolated from local roads with only a scant selection of exits where new traffic can enter and leave. Highways never actually intersect directly with other roads except by exits and ramps, meaning traffic control mechanisms like rotaries and stop lights aren’t needed and traffic can move faster. This also has the additional effect of discouraging local traffic from taking the road, leaving the road for the serious long-haul motorists. Most significantly of all, highways simplify navigation. Rather than picking a route over local roads, the highway is a road that limits your route. To enter a highways is to largely surrender navigational choices: there are no turns or forks in the road to decide among; backtracking and U-turns are forbidden; your only option is to drive forward until you reach your exit. You can drive faster because you have less to decide, and you can navigate easier because you have less to consider. And so a trip from New York to Chicago used to be an impossible slog of endless directions. Now, it’s a largely mundane trip of only 3 highway segments (although admittedly, you stay on I-80 for an astonishing 750 miles of the way).
I then go on to explain that running through array elements by incrementing an integer index is a lot like driving cross country on local roads, prone to complexity, mishap and error. From there, an Iterator is a lot like a highway, less worrying about navigation, more involvement with the act of driving. I’m not posting this example to toot my horn in any way (and not as a teaser for the book, although it works that way). It’s just a nice recent case where I pulled a metaphor out of my writer’s toolbox.
From there, I was able to spin out the explicit technical reasons why it’s better to use iterators, but I feel I can succeed because the reader is able to relate to the scaffolding of highway driving, a metaphor well understood by much of my audience (sorry to readers in deepest Papua-New Guinea). I think you’ll agree it’s a lot more vivid to think of access violations as wrong turns and fencepost errors as navigational errors. You can’t help but learn the material because you already know it in some sense. Metaphors aren’t poetic navel-gazing, they’re a necessary ingredient to the book. So, mix them in sometime. I think you’ll like the taste.
Update: The book is coming out soon. I’ll post details when I know. Watch for an announcement soon. I promise!
Posted in Books | Tags metaphor, story, writing | 7 comments
Posted by Jacob Harris
Thu, 01 Jun 2006 16:10:00 GMT
Time for more quick little roundups of notes and followups on things I’ve mentioned before.
This is random, but I now have written for an alternative weekly. About six months ago, a friend of mine who lives in New Haven and writes for the New Haven Advocate told me they were thinking of starting a personal tech column (think of a snarkier Walt Mossberg or David Pogue), and he wanted to know if I was interested. The pay would be low of course (this is an alt. weekly), but visions of free electronics swag kept dancing in my head. Thus, I wrote a few audition columns before Christmas. The column idea was eighty-sixed, but one of my submissions apparently lived on. And it surfaced for last week’s issue as Against Palm Pilots or How one man lost his religion and re-discovered note-taking on paper. In which I lay out my long-running problems with the Palm and the happiness I’ve found instead with Moleskines and the Hipster PDA (Merlin, they left out the credit, but know it belongs all to you.) I like writing for a more general public audience, and I hope I will get to do more columns in the future.
I realize I should also have linked to the original book on Flow. For those who want to read more recent discussion on the subject, Lifehacker highlighted some good recent treatments from FastCompany and Metafilter on the book and application. And of course, 43 Folders has a nice roundup of links as well as a related discussion on zanshin. Scott Berkun touches on how Flow relates to sucky software. And so on.
The point here is people are doing Ruby on Rails not because it comes within some whiz-bang IDE (it doesn’t) or it has a bunch of wizards and graphical builder dohickeys (it doesn’t) or even because it promises productivity boosts (they’re there, but as a result). Rather, they’re excited because with only a text editor and a copy of Pickaxe by your side, you can do some amazing things and get into that state. And that makes you happy. And that makes you productive, because you actually want to do the work.
Wow, I was wondering about an uptick in my readership, and now I know I have Robby Russell to thank! harrisj loves Planet Argon! Seriously, Robby and his brave and fearless crew are doing some of the smartest and most honest coding and writing I’ve seen, and you should definitely read Robby Russell’s blog and and book Programming Rails when it comes out. I would also like to point out the excellent blogs of Jeremy Voorhis, Dave Gibbons, Jason Watkins and the rest of my fellow Planet Argon inhabitants.
One last thing. The Canon S400 that I revived through surgery died again thanks to an accidental coat check at the Van Gogh Museum in Amsterdam (the attendents seem to not so much hang coats as fling and kick them I guess). So, after a bit of a photographic drought, I now have a Panasonic Lumix DMC-FZ7, and I love it. There is something wonderful about the feel of it in your hand, and it takes much better pictures at a fraction of the price and weight of Digital SLRs.
Tags flow, gtd, newhaven, pdas, planetargon, robbyrussell | 1 comment
