what it's like to write a book
So, what’s the book about? In short: testing software. More specifically, it’s about testing a piece of software by remote control: clicking icons using code instead of fingers.
There’s a whole other blog for talking about the technical fine points. By contrast, this post is going to look at the warm, fuzzy side. We’re going to talk about what it’s like to be on this side of a keyboard cranking out a book.
why?
First of all, why on Earth would someone put himself through this? Late nights, endless revisions, (potentially) scathing criticism—why? The answer is different for everyone, I suppose, but it seems like a measure of obsession usually comes into play.
I didn’t so much write this book as try to hold onto reality while it wrote me. It clawed its way, growling and gurgling, out of my insides and onto the pages. I don’t think I could’ve stopped it if I’d wanted to.
And sometimes, that was the only thing keeping the whole enterprise going. When the text is bogged down in rewrites and just isn’t working, when the last thing you want to do after (or before!) a crushing day on the job is more computer crap, and when all the distractions of the Internet are right there, momentum is the only thing keeping a book from sliding into “one day there’ll be a book.”
So anyway, I wrote it because it needed writing.
when?
In 2004, I needed a book on software testing. There wasn’t one. I mean, there were a bunch, but none on testing a program’s user interface. Well, okay, there was one, but I couldn’t use it.
A couple of years later at FOSCON, I heard a prominent technical press was doing a title on using my favorite programming language (Ruby) for testing. First, though, they had to teach the language itself, and so that book morphed into a great Ruby tutorial. Testers were still a big part of the audience, but the emphasis was on learning to program.
So I wrote the publisher and said, “Hey, have you guys thought of covering user interface testing as sort of an add-on topic?” Well, they’re big on doing stuff for yourself, so instead of saying, “Sounds like a nice idea,” or “We’ll get right on it,” they said, “Why don’t you write it?”
Gulp.
how?
Since they’re a technical press doing mostly programming books, it makes sense that the Pragmatic Programmers have a programmer-friendly setup. Writers get to use the same tools to keep track of their writing that they’d normally use on a programming project to keep track of their code. Every change you’ve ever made is recorded. Want to borrow a sentence from that paragraph you wrote three weeks ago but deleted last Friday? No problem.
Also, the way you mix and match narrative text and program source code is nice. A lot of programming books used to be written by cut and paste. If an author wanted to talk about an example program, he’d write the program and then paste the text into the book— usually piecemeal, with a snippet of code, some explanatory text, more code, and so on.
Every time he changed the program, he’d have to remember which parts he changed, and then re-paste them into the book. If he forgot one piece or missed something, the final printed book would contain an incorrect program.
Here, it’s different. You write your program, and then decorate it with little comments that say things like, “This is the start of the login window.” Instead of pasting code into your book, you just insert a little marker that says, “Put the code for the login window here.” The publishing software takes care of the rest.
Speaking of publishing—every time you electronically send your changes to the publisher, their system automatically generates print-quality PDF for you. You’ll see your words and your programs almost exactly as they’ll appear in the final book.
what?
That’s it for the mechanics. What’s it like to actually write this stuff? Hard, that’s what it’s like. I don’t know how real authors do this. This project nearly ate me up. I’d either be up into the wee hours of the morning after the gals had gone to bed, or up at the wee hours of the morning to get a good start before the gals would wake up.
All in all, the early riser approach works a little better, because there’s a hard deadline: once the whole household was up, work on the book was pretty much impossible. But we’re fighting biology here: Deeses are notorious night owls.
So a typical late night or early morning would involve bashing out a few more paragraphs, hacking some code, running into a brick wall, consulting the Internet on a technical question, and getting distracted by reddit.
Remember a few paragraphs back, when I said the system remembers everything you do? That’s extremely helpful, but also extremely embarrassing. Every crap paragraph that left my fingers is preserved for all eternity. And there were a lot of crap paragraphs. Folks like Ray Bradbury and Julia Cameron talk about this all the time, but it’s quite another thing to see in real life. “Dear God, I’ll take care of the quantity, and you take care of the quality.” It took a whole hell of a lot of the former before muchg of the latter seeped in, let me tell ya.
More to come. Watch this space for updates.