How to Effectively Mentor New Technical Writers, Part 1: The Writing
Writing is timeless. Writing communicates. Writing has power. However, bad writing confuses. Bad writing misleads. And, perhaps most poignantly, bad writing gets rejected. The difference between good and bad writing can make or break a paper submission; a career; a movement…
In the technical circles I participate in — computer vision, robotics, medical imaging, machine learning — many key deadlines loom in the coming weeks. Unless you know something I do not, it’s way too late to conceive new ideas for these deadlines, but it’s not too late to perfect the writing around your good ideas! Here’s to a successful ECCV, MICCAI, IROS, or wherever-else paper submission.
For some background, I’ve published about 150 technical papers in good peer-reviewed venues. I’ve had maybe 300 more rejected! That’s, what, 500 papers I’ve participated in writing over the last twenty years, if you include the journal articles resubmissions too. I’ve honed in a few best practices while doing that (and gone a bit gray and failed to sufficiently exercise to avoid back problems).
This brief essay will arrive in two parts. This first part describes my experiences with concrete mentor-to-mentee approaches to teaching good technical writing. And, for doing so in a way that can also generate a strong level of output without rendering you burnt out. Next week, in Part 2, I will discuss an effective strategy for ranking a group of possible technical manuscripts for maximal potential to your team’s output; in other words, as the deadlines loom, you cannot spend a sufficient amount of time with each of the mentees (students or postdocs most likely) in your group, so you must choose.
Let’s get to it — I have my own papers to write, edit, and mentor these days as well!
Approaches to Mentoring New Technical Writers
Your mentee — your student, your postdoc, your junior collaborator — charges into your office. “Here’s the paper,” they say. Proud expectations of imminent praise shine on their smiling face, as if all time has stopped and you must stop everything to appreciate their good work. “Great,” you say. You’ve been meeting with them for months; you know what the paper should say. You know the results. You know the method. You know the context.
But, you also fear the paper does not articulate those things. Well, you expect the paper tries to articulate those things, but doesn’t deliver in quite the way it should. You’ve been there before and you will be there again. Here are some strategies I’ve seen for taking that first draft and both improving it while teaching your mentee how to write more effectively.
The No-op Approach
The No-op approach is when you do one of two things. First, you basically take over. You take the paper — or these days you login into Overleaf — and start essentially from scratch. You probably end up re-using the references file and the experiments the mentee prepared, but your basic mindset is that the paper (in its current form) is useless, and you need to redo the whole thing, assuming you have the time for that (see Part 2 coming next week). When you’re done, you show the paper to the mentee.
Second, you do nothing. You take the paper and quickly realize the paper is not viable as you skim through it. This happens, for various reasons. You have responsibility in this as well. The right thing to do is stop the submission of the paper and then revisit the project it after the deadline, holistically. Some folks unfortunately would let the paper go through the submission and review process, hoping the reviews will be instructive to the mentee. But, that’s the wrong thing to do. Not only does it burden the overloaded reviewer community with work you already know is below-bar, it also delays the mentee by months. Reviewers are not mentors for your mentee.
I recognize it may be awkward to start with the No-op approach in this essay, but it’s relevant and happens more than you think, especially when you have multiple mentees and a fixed amount of time. But, obviously, although the “take-over” no-op may end up with a publication, which is an ultimate goal, it does nothing by way of teaching your mentee. Okay, fine, it does a little — they saw their draft and then they saw your final version and can learn from that, but it’s unlikely to be effective (and you more than likely crushed their ego, which will have repercussions for the future).
Classic Redlining
The second and arguably most common approach to mentoring new technical writers is where you basically do what you experienced yourself in secondary school: the mentee “submits” the paper to you, physical or digital, and you act as the teacher working your way through it providing editorial-like commentary with colored ink (or digital comments, although I find these less instructive). I call this the redlining approach. It’s a fairly light lift on the mentor’s side — roughly the time to read the paper — and will lead to some improvements, both in the paper and the mentee’s writing prowess.
However, I find this approach somewhat ineffective. The main reason is that the types of edits that normally need to happen at this stage vary greatly, especially for a green technical writer. Some papers are suitable for redlining while others are not. The types of edits fall into three buckets. First, there are inevitable copyedits, some of which are pretty unique to technical writing. For example, no contractions, ubiquitous use of “we,” and the culling of obtuse, fancy words that just take up space, to name a few.
Second are what I think of as “super copyedits.” These are localizable edits to a particular section or paragraph that bring the technical narrative into a communication style effective for the domain and topic. One example is the avoidance of what I call “defensive writing.” This is something I’ve noticed early writers do when they are unsure about how to describe a particular technical idea, or they have doubts about the idea itself (yes, rather common). Whereas a good description of a technical method simply gets to the point, clearly describing what was done through crisp language and solid equations, a defensively written description begins with the reasons why something was done even before it was described. Not only does this lead to hard-to-understand prose, it never passes the sniff test for the reviewer.
Another example of a super copyedit, which I learned from Frank Dellaert while collaborating on a paper in 2014, is the importance of the first sentence of each paragraph. Technical papers need to convey their key ideas swiftly and succinctly as there are many new papers to get through. One way to do this is to ensure that the first sentence of each paragraph clearly lays out the argument, to enable a reader to grok the paper’s key ideas only by reading these paragraph-first-sentences. Simple and effective.
Third are structural argument edits. Technical papers — like most nonfiction writing — must make a clear and effective logical argument. In my experience, this is both the most important part of technical writing and the hardest to mentor. Here, you may need to restructure the entire paper. You may need to move sections around. You may need to remove entire sections — writing is nonlinear after all. It’s common, for example, that a new writer will make two key mistakes: 1) they will write the paper according to how they did the work, from start to finish; 2) they will include every nuanced detail of what they did. Both are generally ill-advised. It’s critical to abstract the key arguments and contributions, presenting them clearly and early.
Redlining is effective for copyedits and perhaps some forms of super copyedits, but it is quite difficult for structural argument edits. Even if you take the care to not only mark up the paper but also talk through each redline with your mentee, which is imperative anyway, I have found that the essence of my structural argument recommendations often were ignored, whether intentionally or not. Maybe it’s due to the overwhelming nature of receiving the draft back with so many redlines that it’s hard for the new writer to rank their value. Maybe it’s something else.
Ultimately, redlining is significantly better than the No-op approach for both improving a paper itself and for teaching effective technical writing to a mentee. However, it’s not nearly as effective a mentoring approach as the third and final method, side-by-side cowriting.
Side-by-side Cowriting
What I’ve found to yield the best results for effective mentoring of technical writing is to work very closely together, side-by-side, at the computer terminal and work through the paper. But, you drive, as the mentor. The first time I did this was after multiple redlining sessions with a paper that had huge potential, but the sequential redline-edits and subsequent discussions were not achieving the structural argument flow that I thought the paper needed in order to thrive.
So, I took a leap with the mentee. I invited the student, in this case, to sit next to me at my workstation. I fired up the text editor and pdf viewer — this was long before contemporary tools like Overleaf — and began to walk through the paper. Side-by-side cowriting was born!
My approach to this is “bottom-up,” meaning that, together, we walk through the paper, making simple copyedits initially. During this process, I am careful to point out what I see as the key elements to the argument and how they flow. I will often have a second text buffer open to note these key points. Side note: I have found this to also be an effective means of teaching your mentee proper LaTeX syntax, styles, and functionality.
Only after touching every section in the paper, do we go back and consider structural argument revisions, even though this is the whole point — effective structural argumentation is definitively the hardest part of learning strong technical writing. I am careful to note various flaws in the current argument structure and how I think it can be improved. We decide, together, on improvements to the argument, clearly stating rationale (sometimes even in “comments” in the text file itself).
Then, together, with me still driving, we work through the revisions to the structural argument. Yes, I do the writing in front of the mentee, live. During this time, certain super copyedits will also work their way into the session, naturally. We again, work through the full paper, often rendering it unrecognizable afterwards to when we started, in a good way. Realizing there are likely more copyedits to do, certain new figures may be needed, or other things, we end the session at this point, moving to the redlining or a digital-collaborative approach afterwards for the final touches.
It is important, of course, to note that side-by-side cowriting is most effective after you have read and thought about the paper in some current form. Starting from scratch and writing the paper together may be tempting, but I imagine that would be less effective as there was no “active” part of the work for the mentee where they considered the paper flow and put it in a draft. In other words, without the mentee putting in the effort first, I doubt they would find a side-by-side session any more effective at learning how to write than, say, reading another paper someone else wrote. But, I could be wrong about that.
Side-by-side cowriting takes time. You and the mentee need to have the time to make the session effective. It’s a commitment on both of your parts. Furthermore, one final note is to avoid negative and insulting remarks. Early technical writers often make some naive mistakes. That’s natural. If you put them in a defensive posture, the quality of the session will degrade. I know you don’t mean to be negative or make insulting remarks; just watch your tongue.
Closing
Learning effective technical writing is difficult and takes practice. Mentoring new technical writers likewise is difficult and takes practice. I hope these strategies make both of these easier as you work through paper revisions for near and distant deadlines.
I’d love to hear if these approaches have worked for you; or maybe you have a different approach. There are other elements to becoming an effective technical writer that are not mentioned here as well. For example, I often encourage my mentees to practice writing on a daily basis whether or not they are concretely working on a certain manuscript. Not only does this practice improve their writing, but the act of writing brings clarity to thought.
Next week, in the second part of this two-part series, I will describe some strategies I have developed over the years for choosing which paper draft to work with from a pool of possibilities as a deadline looms and time is limited.
Acknowledgements
Thank you to the past and current mentees that have taught me so much about writing. Thank you to my friends and colleagues who read early versions of this article and inspired powerful changes, especially Michele Brinich.
Biography
Jason Corso is Professor of Robotics, Electrical Engineering and Computer Science at the University of Michigan and Co-Founder / Chief Science Officer of the AI startup Voxel51. He received his PhD and MSE degrees at Johns Hopkins University in 2005 and 2002, respectively, and a BS Degree with honors from Loyola University Maryland in 2000, all in Computer Science. He is the recipient of the University of Michigan EECS Outstanding Achievement Award 2018, Google Faculty Research Award 2015, Army Research Office Young Investigator Award 2010, National Science Foundation CAREER award 2009, SUNY Buffalo Young Investigator Award 2011, a member of the 2009 DARPA Computer Science Study Group, and a recipient of the Link Foundation Fellowship in Advanced Simulation and Training 2003. Corso has authored more than 150 peer-reviewed papers and hundreds of thousands of lines of open-source code on topics of his interest including computer vision, robotics, data science, and general computing. He is a member of the AAAI, ACM, MAA and a senior member of the IEEE.
Disclaimer
This article is provided for informational purposes only. It is not to be taken as legal or other advice in any way. The views expressed are those of the author only and not his employer or any other institution. The author does not assume and hereby disclaims any liability to any party for any loss, damage, or disruption caused by the content, errors, or omissions, whether such errors or omissions result from accident, negligence, or any other cause.
Copyright 2024 by Jason J. Corso. All Rights Reserved.
No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher, except in the case of brief quotations embodied in critical reviews and certain other noncommercial uses permitted by copyright law. For permission requests, write to the publisher via direct message on X/Twitter at _JasonCorso_.
