Finding and Starting a Book Project
I published my first technical book, Backbone.js Testing,
in July, 2013. Now that I am coming down off the high of actually getting the
book out to the world, I thought that I would take a little bit of time to
reflect on my journey and write a series of posts about the adventures and
tribulations of writing a technical book.
In this first post, I will look back on how I got roped into becoming an author,
planning and scoping a prospective book outline, and signing a contract to begin
work on the book.
Why Write a Book?
Writing a book is an enormous time commitment, puts pressure on your personal
and work obligations, and has little or no chance of being financially a
worthwhile endeavor.
So, why do it?
The short answer is that I liked the proposed topic, I was already
interested in writing, and Packt Publishing had some fortuitous timing in
pitching the project.
A good, challenging topic
Frontend web application testing has been a topic of keen interest and
frustration for me for quite some time. Historically, testing JavaScript in web
pages has been an arduous task, with very few good options and enormous amount
of pain in any solution. At the same time, there is enormous need for this type
of testing as more and more logic is pushed from a traditional backend
application (e.g., a Django or Rails app) to the frontend.
In my day-to-day work over the past few years, I’ve noticed that the biggest
holes in application test coverage and sources of most actual bugs have been
in frontend JavaScript code. Accordingly, I have now spent a good amount of
time implementing and writing about testing on the client side. In 2011,
I wrote two posts on an early frontend testing
solution I came up with using Env.js and Rhino. The technologies were
unreliable and hacked together, but at that point, at least it was something.
Fast-forwarding to today, with the rapid rise of Node.js on the backend and a
whole host of new and exciting browser libraries, there are a lot more options
for frontend testing. At Curiosity Media, we had a large Backbone.js web
application that we were able to get a solid, modern test harness around using
Mocha, Chai and Sinon.JS.
I missed writing
By way of a bit more background, software engineering is my second career.
Before becoming a full-time geek, I was an intellectual property attorney,
focusing on mostly computer software and hardware matters.
While some folks think that the life of a lawyer mostly involves standing up
and arguing in court (e.g., “I object!”), the reality is that as a junior
associate attorney, you spend nearly all of your time reading and writing legal
documents of some type or another. Moreover, as a patent attorney, most of your
time is spent writing patent applications and related legal documents.
And, patent writing is essentially technical writing, albeit with a bit of a
legal bent.
So, coming back to my current life as a software engineer, while I occasionally
write blog posts and articles, it had been several years since any substantive
writing project. And, I kind of missed it.
And, it seemed like the right time
With that background, Packt Publishing had the good timing to
approach me with a book proposal for testing Backbone.js applications in late
October of 2012.
I’m not sure the process was particularly selective in my case, as Packt has a
reputation for somewhat aggressive recruitment strategies for book authors and
reviewers (e.g., they send a lot of emails). But, the subject matter was a good
fit for my frontend testing interests, and the book size seemed to make the
project tractable.
