Retrospective: High Performance Browser Networking

This past Friday the first print copies of High Performance Browser Networking landed on my desk. After carrying it in my head for the past year, it was an interesting feeling to finally hold something tangible: a sense of relief, excitement, and "man, I hope they like it."

With the book in hand, I could finally put a mental checkmark on it, which also prompted a retrospective into the entire process from start to finish. A self-professed quantified self geek that I am, it should not surprise you to know that I've kept a detailed log along the way. Not knowing what I was getting myself into when I first started, it's interesting to now look back at the lessons learned and patterns that emerged. Let's take a look...

Writing HPBN by the numbers

Chapter Writing (hours) Research + Review (hours) Words
Primer on Latency and Bandwidth752,930
Building Blocks of TCP25155,533
Building Blocks of UDP1282,759
Transport Layer Security (TLS)27387,362
Introduction to Wireless Networks10162,763
Mobile Networks6414311,133
Optimizing for Mobile Networks9214,015
Brief History of HTTP762,475
Primer on Web Performance37164,943
HTTP 1.X28155,156
HTTP 2.X37466,464
Optimizing Application Delivery23154,776
Primer on Browser Networking531,618
Server-Sent Events (SSE)6111,681

In total, I've spent 412 hours staring into my text editor. This number is exact and based on RescueTime logging the foreground window. The research and review time was a harder one to track, since that involved online and offline time (e.g., reading books, research papers, etc.), but I'm confident of the data: writing time resolution is down to minutes, research and review are down to hours, with a total of 918 hours and 90,056 words.

Alas, writing, research, and review are not the end of it. RescueTime tells me that I've spent 46 hours iterating on feedback from early release iterations - discussions, followup, and so on. I've also logged 29 hours in OmniGraffle, creating and adjusting all the diagrams. Finally, I've spent 9 hours fiddling with the tooling - waiting for builds, configuration, debugging errors, etc. All said and done the grand total adds up to just north of 1,000 hours.

Taking it a day at a time

The whole process from getting the nod from the O'Reilly team, to handing off the content to the production crew took 381 days. In that time, my Git repository tells me that I've had 239 days with at least one commit, plus another 32 days where I didn't touch the repo but still spent time working on the book: 271 active days.

I wouldn't call myself a morning person, but writing in the evenings after a full day at work didn't yield the results I wanted. Instead, as the Git commit log shows, I've tried to carve out a dedicated chunk of time each morning. Typically, that meant 7-9AM on weekdays, and 8-noon on weekends (hence the commit spikes between 12-2PM). The drop in number of commits on Tuesday/Thursday is interesting as that was not intentional - looking back it seems to coincide with higher amount of time spent on research and review.

  • 1.72 hours (writing) / day
  • 1.59 pages / day or 0.92 pages / hour
  • 377 words / day or 219 words / hour

Reminding myself that a "shitty first draft" should be the initial goal was a continuous struggle - 200 words/hour is not a fast clip. Then again, seeing another page or two appear at the end of the PDF was a great reward and all I was aiming for each day. My best day ever was 11 pages — a full weeks work in one day! Of course, then I had to rewrite most of it. Conversely, there were plenty of days where all I managed was a paragraph or two.

Lessons learned along the way

Collecting above data along the way proved to be a valuable feedback mechanism - e.g. focusing on working in the mornings, setting realistic expectations, and tracking progress. Case in point, my early delivery estimates were off by months and by the end I could project down to a week. Also, a few other interesting lessons learned:

  • Consistency is key - things get in the way (e.g. work, travel, etc.), but showing up is key.
  • Getting early feedback is invaluable - O'Reilly's Atlas toolchain worked really well.
  • Incremental milestones and deadlines are a necessary forcing function.
  • Nothing helps clarify your thinking and expose the flaws and inconsistencies than attempting to put it down on paper in simple terms.

Last point in particular is one of the reasons I keep this blog - writing helps me understand the topic in a way that reading and talking about it never does. Working on HPBN forced me to clarify a lot of important details I've overlooked before; relearn topics I thought I understood but really didn't; learn a lot of new material.

With all that said, ultimately you'll have to be the judge on whether the book actually delivers - hope you learn a useful thing or two as well! Speaking of which, do check it out, and if you do, please leave a review!

Ilya GrigorikIlya Grigorik is a web performance engineer at Google, co-chair of the W3C Web Performance working group, and author of High Performance Browser Networking (O'Reilly) book — follow on Twitter, Google+.