Updated: 6 days ago
Working in tech, I’ve often edited work by technologists who frequently write about topics I have no direct experience with, but genuine curiosity and independent research have made it possible for me to follow along. (I mean, seriously: how can one individual confidently say that they have deep subject matter expertise in time-series data, or caching, or open-source Go interfaces for libvert, or building storage solutions with Ceph? Because I’ve had to edit pieces relating to all of these topics and more.) I’ve worked with writers who are extremely confident writers and others who aren’t. But the key to helping each of them produce their best work has been by truly listening to what they were trying to communicate in their writing, and carefully tweaking their work to get their message across to readers without disregarding the writer’s unique voice. It’s not easy work.
As an editor, my first job is to listen. I’m not the intended audience; I am, at best, an advocate for the reader. But I am both an avid reader and a writer. Writing is an incredibly vulnerable and laborious act—even for people who write a lot. I know what it’s like to spend a long amount of time getting one’s thoughts to paper and then going through a period of self-editing before sending a draft over to an editor. I know what it’s like to agonize about what the edits will look like and whether the editor will think I’m the worst writer ever. Because we write about the things we care about or are curious about, an editorial critique can feel more personal than other forms of criticism.
Keeping this in mind, and knowing how frustrating it is to read a book that has missed a step (or twelve), editing is a delicate dance between balancing the needs of the intended reader with that of the writer. My first pass involves a thorough read of the manuscript to acquaint myself with the topic and the writer’s voice. I’ll note a writer’s preferred spelling for specific words and their use of grammar. I’ll look at sections that might need to be fleshed out more or ones that need to be cut down. Then I’ll review the manuscript, line by line, reviewing my notes, editing sentences or sections, pointing out discrepancies to the writer, asking questions, or clarifying my editing choices. I like to sound approachable and friendly in my queries and have found the placement of an exclamation point here and there, an emoticon, or even highlighting a section and writing “I love this!” or “This is awesome!” is helpful. Yes, editors are there to make improvements. But it’s also incredibly helpful to point out to writers what they do well so they can do more of it.
The Human Side of Data
Every now and again, we are given the opportunity to work on a project (or projects) that forces us to level up. I was fortunate enough to get two such opportunities this year.
Over a period of six weeks this past August and September, I edited not one, but two books about data. The subjects themselves were very different—one is about time-series data written by a data scientist, and the other is a collection of data visualization projects from two very talented data visualization designers—but in both cases, I was out of my depth and overwhelmed by topics that felt abstract and foreign to me. But I wanted to do nothing less than a stellar job for both the authors and for their future readers.
These books were the most challenging I’ve edited in my entire career and not just because of the subject matter, but the scope. The book on time-series data is extraordinarily comprehensive and breaks down the topic into a series of very low-level, granular subsections. I did not actually edit the manuscript; I was brought on as a reader of the manuscript’s first draft. A manuscript might be reviewed by readers for further refinement before it’s ready for editing. In this role, I was responsible for ensuring the content was complete, technically accurate, and to explain what I thought about the subject matter, the audience, and determine how the book compared to similar titles on the market. I was not the most qualified for the task—I’m not a data scientist by any stretch of the imagination—but I did as much research as possible and was determined to give the writer constructive feedback that would help them improve their book. My job was not to edit but to help get the content to as close to complete and accurate as possible. I learned a lot about what it means to be a reader when my first reaction would be to edit. It forced me to slow down, listen, and not rush. (A difficult thing to do in the age of shrinking attention spans.)
A week after wrapping up my technical read for this manuscript, I started my pre-read for another assignment: editing a book co-authored by two data visualization designers. The book covers a yearlong collaborative dataviz project the authors worked on. Each month carried a different theme, and each designer selected—or in many cases, built—a complete dataset. They analyzed and visualized data using an assortment of technologies (honestly, an impressively long list). I never appreciated the vastness of data analysis and data visualization until I worked on this project; they coded and designed each visualization and spent considerable time producing the final results, which were even more wonderful to interact with once I knew how much work went into them.
The depth of information in each project, as well as working with two authors with very different writing styles, forced me to push myself as an editor and really tested the limits of my editorial prowess. First, I was looking at 24 chapters of content, each featuring any set of libraries, programming languages, and frameworks that needed to be noted and presented consistently across the entire volume. Then, there were different page counts from chapter-to-chapter; some chapters needed to be cut down substantially without sacrificing any important insights or observations. Finally, each author’s unique voice and writing style had to be preserved while aiming for clarity and consistency and without losing the reader in a myriad of details.
I spent 24 days doing back-to-back developmental edits. A developmental editor not only copy edits—they edit at the structural level. They look at the content holistically and address issues with tone, identify holes or gaps, point out areas that are superfluous and can safely be cut down or removed without affecting the piece, and offer guidance for fleshing out areas that would give the reader more information.
I referred to the Chicago Manual of Style more times than I had before (it was collecting dust before this project) and communicated with both writers almost daily over email and Gchat. I brought on a friend and fellow writer to assist in the final editing stages, and we—writers and editors—worked collectively to produce a version that remained true to the writers’ voices and contained wonderment that will excite readers.
How I Learn Through Editing
The entirety of the knowledge present in the world is far too vast to ever be truly captured. There will always be things we don’t know. As a technologist, I find this humbling and incredibly frustrating; yes, we’re in an industry that values and rewards an endless curiosity, but there will always be more to know. I’ve had to remind myself of this fact many times in my career. Learning to code on my friend’s couch was extraordinarily difficult. I brought many assumptions and hang-ups and biases around what it meant to be “technical” and “analytical”, and these characteristics were in diametric opposition to everything I thought myself to be. But nevertheless, I’ve learned. I’ve amassed some knowledge since those early days on that couch. My career trajectory looks way different than what I imagined it would be, but my journey has taught me that there is no one way to be “technical” any more than there’s only one way to be “creative”. Editing is something I thoroughly enjoy, and in helping a writer refine their voice, I’m gifted the opportunity to learn something new.
While I was editing these volumes, I never imagined that I’d soon be in a position where I’d have to interact with data in a more meaningful way. A few weeks after wrapping up these projects, I moved to a growth engineering team at my company. I’m the PM on the experimentation program and data is the foundation of any experimentation program and, while I’m not visualizing datasets or looking at time-series data, I’m now dipping my toes into statistics and SQL.
Like this post? Sign up for my Developer Content Digest newsletter.