Swizec Teller - What I learned writing a lousy tech book

A tech author’s path from blog post to published book turned into a lesson in how nonfiction quality gets shaped—often painfully—by contracts, deadlines, and layers of editing. After landing a deal to write a visualization-focused JavaScript book, Swizec Teller spent roughly 770 hours over about 66 days producing an initial manuscript, only to have the publisher demand major changes: the book needed to be shorter, more consistent, and more technically correct. The result was a book that Teller ultimately described as “awesome,” but only after multiple full rewrites and months of structural and technical feedback.

The story begins in 2012 after Teller posted early experiments with d3.js, a JavaScript library for visualizations. A recruiter-like email arrived from an Indian contact pitching a book opportunity to teach others how to draw “pretty pictures.” Teller accepted despite having never written anything longer than a blog post. The contract process took two months, with the publisher taking copyright control and limiting Teller’s ability to reuse material—he estimated he could quote only about 10% under fair use. The deal also included a “right of first refusal” clause, meaning any future book proposals had to be reviewed by the publisher first.

Writing itself followed a repeatable cycle: build a meaningful, simple example from the API documentation, code it to prove it works, then write the explanation around that already-working code. Teller emphasized that the hardest part was choosing the first chapter’s example—everything must be explainable, exercise the right parts of the technology, and avoid relying on concepts that will only appear later. He credited the quality of open-source documentation (specifically d3.js) for helping him learn quickly enough to write.

The first major disruption came from length. Teller delivered about 180 pages when the target was around 120, and the publisher pushed for a reduction of roughly 60 pages. That forced a near-total rewrite: he preserved the core content but removed jokes, stylistic turns of phrase, and other personality-heavy language to make the book shorter and clearer. He also had to correct errors flagged by editors, including technical mistakes that required sending chapters back repeatedly.

Even after the manuscript was “done,” technical editors returned with feedback that required further changes—examples that didn’t work as described, incorrect ordering of concepts, and explanations that didn’t match how the code actually behaves. Teller resisted some structural changes because he was exhausted, and he later suggested that this fatigue likely contributed to the book ending up “a bit crappy” in places, even if the most engaging examples kept him sane.

The final stages included copyediting and production checks—ensuring acronyms were used consistently, code introductions were clear, and printed formatting fit the page. Marketing, however, remained opaque: Teller received royalty reports but no visible buzz or measurable impact. His takeaway was blunt: publishing is hard, editors can be relentless, and the economics can be underwhelming, but getting through the process is a remarkable achievement. He also contrasted traditional publishing with self-publishing, arguing that self-publishing can be more flexible and potentially more profitable, yet requires discipline to actually finish.