Tag: Geoff Hart

Posted on

Book Review: The Sense of Style

geoff-Australia-croppedby Geoff Hart

Pinker, Steven. 2014. The Sense of Style: The Thinking Person’s Guide to Writing in the 21st Century. Penguin, 359 p.

We editors love our style guides and accumulate them by the dozen so we can seek insights to solve vexing editorial problems. But if we’re honest, we’ll admit that we return to some guides more than others—usually the ones that support our preferences and prejudices. Even for those references, we sometimes wonder whether certain recommendations make sense, or whether they’re just rules for the sake of rules—the author’s prejudices carved in stone, as in Theodore Bernstein’s eponymous “Miss Thistlebottom” or even The Elements of Style, which William Strunk began carving in stone nearly a century ago. Continue reading “Book Review: The Sense of Style”

Posted on

Editing Science Manuscripts with a Humanities Background

by Geoff Hartgeoff-Australia-cropped

I’m often asked whether someone with a humanities background can build a career editing science manuscripts. The answer, as so often in life, is yes…and no. The yes part is easy: English is English in any discipline, and if you’re a skilled editor, you can edit the basic grammar and syntax of English in just about any field without fully understanding the subject matter. The no part is more complex, and a clue to that complexity emerges from answering the inverse of this question: Can an editor with a scientific background edit humanities papers? Continue reading “Editing Science Manuscripts with a Humanities Background”

Posted on

Book Review: Wildcard Cookbook for Microsoft Word

Geoff Hart

Lyon, J. 2015. Wildcard Cookbook for Microsoft Word. The Editorium. 104 p. incl. index

Wildcard Cookbook cover with borderYears ago, Word-guru Jack Lyon released a freebie ebook, Advanced Find and Replace for Word, which explained everything you needed to know to master Microsoft Word’s find and replace features. It’s still available from his website (http://www.editorium.com/freebies.htm), so you might wonder about the need for a new book on the subject. However, there are three good reasons to consider Jack’s new book, Wildcard Cookbook for Microsoft Word: the text has been thoroughly updated and debugged for versions up to Word 2013; Continue reading “Book Review: Wildcard Cookbook for Microsoft Word”

Posted on

Managing the Chaos of Freelancing by Taking Control of Your Schedule

Geoff Hart

As freelancers, we all face the problem of feast or famine: sometimes we’re overwhelmed with work, and can hardly find time to think, let alone keep up with our other responsibilities, but other times dust gathers on our computers while we wait for new work to arrive. Clearly, marketing our services and finding new clients is important to avoid the “famine” part of the freelance lifestyle, but what do you do when too much work is arriving?

As a freelance editor, my work primarily involves a large number of small jobs rather than a small number of large projects over the course of the year. In this article, I’ll use this situation, which many other freelancers are familiar with, to provide some suggestions on how to manage your work schedule more effectively and attain a slightly more sane work life. The advice I’ll provide is equally suitable for freelancers who work on a few large projects, since even the largest projects can be broken down into smaller and more manageable chunks. (Indeed, the really big projects can’t be managed any other way.) The same strategies apply, but with an obvious modification: you’ll need to budget time at the end for cleaning up and finalizing the whole project.

There’s no foolproof solution to the chaos of freelancing, since life sometimes happens all at once and there’s nothing whatsoever we can do about it. But there are several tricks that let us juggle life and work considerably better than if we give up and simply accept whatever life throws at us. One of the first and most powerful solutions involves gaining more control over our schedules. Doing so requires only four simple steps:

  • Learn how much work you can complete within a normal-length day.
  • Use some form of calendar to reserve dates for anticipated work and your known commitments.
  • Always build some slack time into your schedule.
  • Develop a support system.

 

Learn how much work you can complete per day

Tracking your productivity is important, because it’s the only way you’ll ever be able to know how long a job will take and thus, how many days you’ll need to reserve for a given job. This knowledge is what lets you schedule your work. Each job is at least slightly different from the work you’ve done previously, but over time, you’ll gradually get a feel for your range of productivities, including both your long-term average and the worst-case scenario. A conservative approach to scheduling your work relies on using the worst-case productivity, since that way you can be reasonably confident you’ll finish ahead of schedule. Basing your schedule on your average productivity may be more realistic in the long run, but it also means that you’ll end up working under significant deadline pressure for half of your jobs and severe deadline pressure for a significant number of jobs.

If you track productivity separately for each client or each type of product, you can further refine your estimates. Best of all, if you get a chance to examine the whole job (e.g., the full text of a manuscript to be edited or a carefully defined functional specification for software) before you are asked to provide a quotation, you can base your estimate on the actual work you’ll be doing and come up with a much better estimate for that specific job. However, there’s a common gotcha to be aware of: early chapters in a book that you’ll be editing or the initial product features you’ll be documenting in a help system tend to have been developed early in the project, while the author or developer was still well-rested, excited by the project, and not facing insane deadlines. Later parts of the job often take longer than early parts because of creative fatigue, loss of interest, or simple lack of time to do the job right. So try to examine the whole project, not just one or two initial components, before you create an estimate.

The first step to gaining control of your work life is to learn the trick of estimating how long a job is going to take each time a client contacts you with more work. For suggestions on simple ways to track your productivity, I’ve provided two resources on my Web site:

 

Use some form of calendar to reserve dates

Once you know how long a job will take, the next step is to schedule the work. Doing so requires some form of calendar, whether you implement it on paper or in software. (Different strokes for different folks!) Basically, your goal is to recognize that there are only so many working hours in a week, and that all your work must be fitted into those available time slots. Once a slot is full, it’s no longer available for other work, and finding a way to account for this in your schedule is the key to regulating your workflow better.

In the previous step, I asked you to determine how much time a job will take. Now your goal is to look at your calendar and find the first day when you can begin that work. Mark the day (or days) on your calendar as “Reserved for [name of job]” so you won’t double-book those days for other work. One of the biggest mistakes freelancers make is failing to reserve dates for future work on those rare and happy occasions when a client gives us advance warning about when a job will arrive. If you have clients that predictably send you work such as annual reports, quarterly newsletters, or annual funding proposals at specific times of year, reserve those days each time you start marking up your calendar for a new year, and add a note in your reminders program a month before these periods so you can contact your client and confirm whether the work will arrive on schedule.

Don’t forget to include down-time and other non-work time commitments that will reduce the number of hours available for work. If you know you’ll be away or unavailable for part of a day, mark that part of the calendar as unavailable. Include doctor appointments, family gatherings, meetings, or anything else that will prevent you from working. Don’t neglect the obvious: for example, my first calendars were clearly marked “no work today, idiot!” on weekends and holidays because early in my freelance career, I was constantly working through the weekend and wondering why. As it happened, I’d simply neglected to block in those days as unavailable for work. (Sometimes I’m thick as a brick.)

Reserve all your known commitments (e.g., an hour a day for exercise or watching your favorite TV show) before you start allocating your time for the coming month. You won’t always be able to honor every commitment, but you’ve got a much better chance of success if you’re at least willing to try to give your real life equal priority to your work life. For longer allocations of time, such as vacations, add a note in your reminders program to notify all your main clients well in advance so they can plan around your schedule. (Many won’t bother, but each one that does is one less client likely to cause problems around that time.) One useful, though mildly unethical, approach involves telling clients you’re leaving a couple days earlier than you really are leaving. This way, if any emergencies arrive at the last minute, you still have time to handle them—or to find someone else who can do so. (More on the latter topic in the penultimate section of this article.)

Paper works adequately for calendars, but software solutions provide far more flexibility when it comes to rearranging your schedule. What software should you use? Options range from behemoths such as Microsoft Project to smaller and nimbler tools such as the task and calendar tools built into Microsoft’s Outlook or Apple’s iCal. Everyone eventually finds an approach that suits their unique needs, and the key is to invest some time experimenting until you find an approach that works well for you. For example, I’ve found an approach that, though kludgy and inelegant, works better for me than more complex and powerful solutions: I use iCal for reminders and small notes, but I use nested folders on my computer’s desktop to organize my work life. You can see what this approach looks like in Figure 1. The key concept behind my approach is that I use a single “Work” folder to gather all my work together in one place, and use Macintosh aliases (”shortcuts” in Windows) that point to the actual folders that hold the work for each project. Adding the date at the start of each folder name lets me schedule the work.

Figure 1. Using nested folders to organize your work schedule.
Image

Each month, I create a new series of named folders to reserve non-work days for weekends, holidays, and other times I won’t be available for work. For a weekend, a typical folder might be named “September 12-14 no work”. (Note that I’ve also marked most Fridays as unavailable for work. We’ll come back to that point in the next section.) Similarly, the screenshot shows a planned absence in the form of a working vacation during which I’ll be giving a workshop to a local STC chapter and then taking a few days of vacation: “October 12-20 no work (Phoenix trip)”. Folders representing dates when I’m not available for work are highlighted in red to distinguish them from folders representing work.

In Figure 1, you’ll see two different types of work folder: Folders such as “September 8–808078 Harada alias” represent a project I’ve already received and that is ready for editing when time permits, but no later than that date, whereas the folder “September 9–808061 Harashima (long review)” is a placeholder for a job that hasn’t yet arrived but that is due to arrive on the specified date. I’ll replace that one with an alias to the real folder once the files are on my hard disk. Folders that contain the word “alias” (the Macintosh version of Windows shortcuts) point to the actual working directory, thereby providing direct access to that directory without having to click my way several levels deep into my hard drive. This is important for me because I have clients in dozens of countries, and several large clients in two countries, requiring a strongly nested folder hierarchy on my hard drive.

Note that I’ve also used a yellow-highlighted folder that does nothing but separate ongoing tasks (such as the newsletter that I publish for STC’s Scientific Communication SIG(external link) and a list of presentations I’m currently working on) from the actual paying work. Because most operating systems sort names beginning with a hyphen before names beginning with letters, adding a hyphen to the names moves these folders to the top of the list. Other useful tricks such as adding a number before each name lets you take advantage of the operating system’s default ordering rules.

The resulting display provides an “at a glance” list of the work that needs to be done, and when it needs to be completed. Using a consistent naming scheme lets me use the built-in display options on my computer to place the work in correct order, but there’s an obvious problem: although the order of the folders is correct within any given month, you can see that my absence in October displays above (before) the work that must be completed in September. I could solve this problem by working in icon view instead of text view, since that would let me manually drag the folders into the correct order rather than being constrained by the operating system’s sorting preferences. I’ve found that I prefer the text view, and can live with the tradeoffs.

When I finish a job, I simply delete the alias pointing towards it, which has no effect on the actual folder that contains the project, and move on to the next project on the list. When new work arrives, I can see at a glance when I’ll be able to fit it into my schedule, and I can immediately propose that deadline to the client. If urgent work arrives, with a tight deadline, I can see (based on the dates in the work folder) which projects can be pushed back a day or two. For example, the folder “September 9 (due 18) 808062 Wada alias” tells me that I should try to get the job done by the 9th, but that I can let it slip by up to 9 days if more urgent work arrives unexpectedly. In the next two sections, I’ll discuss how to handle such surprises.

Always build some slack time into the schedule

When a client contacts you to discuss new work, learn to always ask them two questions:

  • When would you like to receive this job?
  • When do you really need to receive it?

Most of the time, there’s a significant gap between the two. When you record the job on your calendar, carefully record both dates. If unexpected or more urgent work arrives, knowing the true deadline provides an opportunity to juggle your schedule (i.e., push back the date on a less-urgent job) so you can fit in the new work.

This approach is a specific example of a more general principle: always build in a day or two per week of empty time that you can use when a job takes longer than expected or something urgent arrives. The more flexible the schedules of your clients and the more predictable your workflow, the less empty space you’ll need to set aside. Over time, you’ll gradually get a feel for how much work is likely to arrive in a typical week. For example, my major client typically sends me two to three jobs per week, and more than that during busy periods. Knowing this, I no longer accept more than two or three jobs from other clients in any given week because doing so might leave me unavailable to that primary client. If my major client is less busy than usual, it’s easy for me to complete other work earlier than originally scheduled or accept work I’d otherwise have to decline, thus giving my other clients a pleasant surprise.

Of course, whether to do work earlier than scheduled is a bit of a judgment call. If you’re as busy as I am, you’ll find that it’s a wise choice, because you never know for sure what will arrive on your desk next week, and freeing up time now by finishing next week’s work early makes it less likely that you’ll have to turn away work or pull an all-nighter. On the other hand, sometimes you simply need a day off to decompress, and the risk of longer work days next week isn’t the worst alternative.

As I noted in the previous section, I’ve implemented my own advice by marking my Fridays as unavailable for work. This serves two purposes. First, I’m growing sufficiently old and prosperous that free time is becoming more valuable to me than a few extra dollars. During slow periods, this means that I can often take a 3-day weekend and use the extra time to work on my own writing. Second, this automatically gives me one day per week of flex time that I can allocate to rush jobs or unexpectedly long jobs that require more time than I budgeted. I still often end up working most Fridays, particularly when I know that I’ll be leaving for a long trip and need to store away a bit of extra money to cover my lack of earnings during that period, but asking clients when they really need a job returned often lets me defer a job until the following week. Then, if I do need to work on a Friday, or if I know something big is coming the following week, I use the extra hours on Friday to avoid a serious work crunch the following week.

Develop a support system

All of this is great in theory, but in practice, sometimes everything hits the fan simultaneously and there’s simply too much work for any one mortal to handle. Pulling an all-nighter or working a 60-hour week is sometimes possible, but it’s not a good long-term survival strategy, even if you’re young enough to survive what programmers glibly refer to as a “death march”. (I no longer am.) Yet there’s always the fear that if you turn away a client because you’re too busy, they’ll never come back to you. Fortunately, there’s a reasonably effective solution.

That solution involves finding one or more colleagues you can trust to do work that’s up to your personal standards and who also won’t steal your clients. Yes, such people exist; I’m one of them. In those periods when you have some downtime, spend some time finding two or more colleagues who are willing to do this kind of work and who you can trust. Discuss the possibility of covering for each other during rush periods, with an explicit but informal verbal agreement that you won’t steal each other’s clients. (You can also make this a formal legal contract if you want more reassurance, but starting your relationship by making it clear that you don’t trust your colleague without a signed contract is not an auspicious beginning.) You may still lose an occasional client this way, but if you choose wisely, an ethical colleague won’t steal your clients and everyone will sleep a bit easier knowing they have someone to cover for them. Better still, an insanely busy period for one of your colleagues may coincide with a slow period for you. If you hit a dry spell, write to these colleagues and let them know. They may be happy to send you some of their work.

I work this way and refer potential clients to a few colleagues purely as a friendly gesture: I don’t charge them any money for this service, and I don’t count up their debts to me. I’ve been blessed with more than enough work, and have several colleagues who aren’t so fortunate and who could use a few extra billable hours. The benefit of this approach to me is that I’m not responsible for the quality of their work, and I make this quite clear to the clients when I give them the referral: “Here’s someone who can handle this work for you. I will not be supervising their work, but they’ve been doing this work long enough that you can feel confident in their expertise.” If you’re more entrepreneurial than I am, you can also subcontract such jobs, and then do quality control on the subcontractor’s work to ensure that it’s up to your standards. Personally, I find this way too much overhead, but it might be a very good solution for you, particularly if you’re still building your client list and need a bit of extra income.

Parting thoughts

I started this article by noting that this approach can be modified to cover a range of other situations. For example, what can you do if you receive offers for two large projects that must be worked on simultaneously? Typical examples might be when two publishers ask you to edit large textbooks simultaneously, or when a software developer asks you to document two large modules of a larger program at the same time. Although it’s clearly more efficient to focus on one project at a time, it’s often appropriate to budget half your work week for each project, and switch horses every Wednesday at noon. Each job will take roughly twice as long as if you worked on only one project at a time, but if you designed your initial scheduling estimates to account for this situation when you accepted the work, you’ll often still be able to complete both jobs on schedule. This is particularly true for software documentation early in the development process, when many parts of the software are being delayed or constantly revised, and you may not have enough work to devote a full week to the product. Things become dicier towards the end of the job, as the software begins to stabilize, more features are complete, and deadlines tighten, but it’s unusual for this to happen at exactly the same time for projects from different clients. More often, different parts of each project progress at different rates, and a slow period for one project will overlap a work crunch for the other project; in that case, you can adjust your schedule to fit in more of the crunch project and less of the slower project. This can also happen with large books, particularly when multiple authors are contributing chapters over a period of several months.

For this approach to work, you need to discover factors that might impose the same deadline or a non-negotiable deadline on two large projects. In software documentation, this might happen when two programs must be released at the same trade fair, such as INTEROP(external link) or in time for the annual tax preparation season. For books, you might need to complete a project sufficiently far in advance that the book will be available at the start of the school year, in time for the Christmas book-buying season, or a big annual book fair. The only way to discover such pressures is to ask your clients whether any such factors might affect their delivery schedule for the product. (Note that I said their schedule, not your schedule. Clients can sometimes be amazingly clueless about how your schedule relates to their schedule, leading to unpleasant surprises.) For some additional tips on learning about organizational schedules, consult the “survival skills” part of my article on Improving your editing efficiency(external link).

Learning to schedule your life more sanely also has strong ties to what may be your most crucial task as a freelancer: establishing a slush fund to cover your expenses those times when the work stops flowing or illness prevents you from working. (This also helps you to afford periodic vacations.) This isn’t optional if you freelance: make it a priority to build up 3 to 6 months worth of savings that you can tap during slow periods or illnesses, even if it means giving up beer and movies for a couple of months to save that money. If you have a family to support, consider buying disability insurance to cover you against illnesses; other forms of income-replacement insurance may be available, so ask an insurance broker about your options. Knowing that your slush fund is full lets you sacrifice work on the occasional Friday, whereas knowing that it’s underfunded or that you’ll be drawing it down soon (e.g., to pay a quarterly tax installment) reminds you to work longer weeks. For some tips on this, see my article Tax tip: a personal savings plan that works(external link).

The freelance life isn’t always unpredictable, and is sometimes unpredictable in a very stressful way. But the first step in mitigating that stress is to take steps to gain some control over your schedule. This article covers a few basic strategies you can use to improve your control. Your own work situation will clearly differ from mine, requiring various modifications to the approach I’ve proposed, and there are other stresses I haven’t covered that require different solutions. But as this article shows, the important thing is to decide that you’re willing to devote a little time to developing strategies that will minimize those stresses—and these strategies don’t need to be particularly complicated. Such simple steps can take you a long way towards a more enjoyable freelance career.

Previously published as: Hart, G. 2008. Managing the chaos of freelancing by taking control of your schedule. http://www.stcsig.org/cic/pages/links.htm#Consult(external link)

Posted on

Editorial Ethics: The Role of the Editor Before Peer Review

Geoff Hart

Editors who work with authors before a manuscript is sent for review face certain challenges. Since we’re often the first to see a manuscript, we sometimes encounter problems we must help solve before they come back to bite the author.

These problems fall into a variety of categories, of which I see three repeatedly in my work:

  • Content
  • Logic
  • Plagiarism

In this article, I’ll discuss the nature of these problems, provide examples from my own career as a science editor, and suggest how similar problems might arise in other types of editing. I’ll conclude with some thoughts on how to confront the problems in an efficient, positive manner.

Problems with the content

Over the years, I’ve found that the more editing work I do, the more poorly designed scientific studies I discover. Once the science is complete, often after several years of fieldwork, there’s nothing much that can be done about the problems with the study. Instead, I have to deal with the consequences: something that may appear unpublishable, at least at first glance, because of seemingly fatal flaws in the experimental design. The equivalent in other branches of technical communication might be working with beginner authors or with professionals such as engineers for whom writing is a distant last in their list of priorities—or skills. The situation may be compounded by tight deadlines that prevent the authors from going back and fixing things.

As an editor, I can’t solve these problems, and in some cases, it’s doubtful whether I have the expertise to justify trying. What I can do is try to ensure that the flaws are not hidden and to suggest coping strategies that might mitigate the flaws. For example, I routinely advise authors that it’s wise to be open and honest about flaws in their study rather than trying to conceal those flaws. The peer reviewers chosen by science journals are generally every bit as smart as the author; indeed, they’re specially chosen for their expertise in a subject, and for their willingness to pounce on the slightest flaw in a paper. Many also look carefully for any appearance of unethical behavior, and will pounce even harder on authors who are trying to conceal a serious flaw or claim better results than their data justify. An author who, despite my advice, insists on concealing flaws in their research, inevitably ends up wasting several months waiting for the results of the peer review, the reviewer will force them to do what I told them to do in the first place and resubmit the manuscript for another round of review, hoping that the changes will now be acceptable to the reviewer. Why not save those months by stating up front that the research needs to be confirmed with additional data and specifying any flaws that must be addressed and resolved through future research? All scientists understand and accept the fact that it’s sometimes necessary to discover better ways to do research by screwing up an initial study.

Similar situations arise in other forms of technical communication. Take, for example, the autonumbering feature in Microsoft Word, which is broadly known to have stopped working more than 10 years ago. Microsoft’s refusal to fix this buggy feature is understandable; the bug is rooted so deeply in the plumbing of Word that trying to fix it might destabilize other, more important features of the software, which is something Microsoft simply can’t afford to do. An even more serious problem lies in the Master Document feature, which can actually cause serious file corruption and data loss (http://word.mvps.org/FAQs/General/WhyMasterDocsCorrupt.htm(external link)) — unlike the autonumbering bug, which causes only frustration and wasted time. Refusing to acknowledge these problems is one thing. But retaining the features both in the software and in the user documentation is unethical. Well-known solutions exist to both bugs, using nothing more than the features already present in Word. That being the case, why not recommend using these solutions instead of solutions that don’t work? That would be a more ethical way to proceed. Unfortunately, this example illustrates the problem faced by many editors: we lack the power to do anything more than raise a problem and propose a solution, and very few of us have the luxury of being able to resign and go elsewhere if that solution is not accepted.

Problems with logic

Every so often, we find ourselves in the happy situation of knowing more than our author, and having a chance to save an author from looking foolish. One paper I edited by an eminent Asian scientist proposed a perfectly plausible explanation for the author’s experimental results. There was just one small problem: the author had neglected a simpler explanation that was every bit as logical, and failing to at least mention that alternative explanation would have humiliated the author before an audience of their peers. (This knowledge was the kind of thing any graduate student should have been aware of, and that any peer reviewer would leap upon as an explanation. I’ve been deliberately vague here in describing the problem because I would hate for the author in question to come across this article.) It took me nearly half an hour to frame an explanation of the problem in such a way as to spare the author loss of face, and it was a great pleasure in subsequent years to see the author including my explanation in his other papers.

In scientific publishing, it’s the responsibility of journal reviewers to reject bad science or faulty logic, so when I’m right and an author still ignores my advice, I can usually be confident they’ll receive similar advice from someone (i.e., the journal) with the authority to force them to take the comment seriously. I can satisfy my ethical responsibilities by raising the problem, explaining its consequences, and doing my best to persuade the author to deal with it honestly and well; I know that if I don’t succeed, someone else will do the job for me. (“Giving up” would be less ethically acceptable when you’re the last person who will see the manuscript before it is published, but as in my previous example, sometimes we have no choice but to accept that we can’t change the situation.) In other branches of technical communication, we may lack this kind of built-in quality control process, and it becomes a considerably more serious problem. If we know a product is unusable or potentially even dangerous, and we cannot persuade its developers to fix the problem, the problem may appear only once the product hits the market—at which point the real world has its say: purchasers reject the project, leading to potentially large lost sales, or possibly someone is injured and the lawyers get involved, leading to potentially large punitive fines. In such cases, ethics force us to at least consider going around a recalcitrant author or developer and making our case to their manager. Sometimes we may even need to ask ourselves whether we should leak a problem to the press to ensure that action is taken before a problem arises, not after.

Potential plagiarism

Most of us encounter a greater or lesser degree of plagiarism at some point in our careers. That’s particularly true if we work with authors for whom English is a second language, since they may lack the skill to create fluent English sentences by themselves and thus have a greater incentive to simply copy someone else’s wording. Other authors, including those for whom English is a first language, simply don’t understand copyright, and believe that it’s acceptable to create an entire document out of other people’s sentences so long as they attribute the source of the text. In most cases, it’s not; at a minimum, direct quotations should appear between paired quotation marks, and an entire manuscript filled with thickets of quotation marks would, at best, look unusual. In each case, we must be alert to the potential problems that may arise—ranging from simple embarrassment to serious legal consequences.

In one particularly memorable case, an author I was working for decided to try publishing essentially identical papers in two journals. (This is often referred to as self-plagiarism.) Journals, predictably, aren’t fond of this practice because it deprives them of unique content when another journal publishes the same paper; it’s also seen as a sly and inappropriate way to pad the list of publications in one’s résumé. When I recognized what was happening, I informed the author of the problem, and explained that whether or not he agreed with my take on the ethics of the situation, it was an unwise trick to play; he was writing in a specialized field where the odds were high that the same peer reviewers would be chosen by both journals. The author ignored my advice, and sure enough, was caught. Both papers were rejected. In addition, one journal warned the author that all future articles he submitted would be carefully screened.

In fields such as science, much of the discourse is built upon citing other people’s studies and comparing one’s own results with those studies. This is standard practice and covered under the doctrine of fair use. So long as an author attributes the original author’s words or data by citing the source, they’re generally following the letter of the law and the standard practice of their discipline. In such cases, we can often reach a compromise in which we modify some of the original wording (as is expected in our role as editor) to create a paraphrase of the original words and ensure that the source is cited. This allows the author to keep their words, satisfy ethics by acknowledging the source of the words, and avoid potential legal entanglements.

Depending on the nature of the job, it’s not necessarily our formal responsibility (as part of our job description or a contract signed with a client) to go looking for such problems. But even if it isn’t, it’s our responsibility to inform the author of such problems when we find them. Finding them often isn’t all that hard. For example, when working with many of my foreign authors, quoted text often stands out clearly from its surroundings because it has an entirely different voice from the rest of the paper and uses words that (based on the word use in the rest of the manuscript) I wouldn’t expect the author to have in their vocabulary. Given the number of papers currently available online, particularly as “pre-publication” versions that authors post on their own Web sites before they sign over copyright to a publisher, a quick Google of the suspicious phrase often turns up its source.

Often, we cannot force the author to do anything about this, and often we can find ourselves in deep waters if we try too hard. A few years ago, a friend nearly got herself fired when she reported that a senior manager at her company had plagiarized something in a way that was almost certain to lead to legal action against the company; by raising the issue and pursuing it in a highly ethical manner, she saved her employer from a significant problem, but in so doing, stepped on some powerful and unforgiving toes.

Breaking the bad news diplomatically

As editors, we rarely have the authority to force an author to fix a problem, and even when we do, “force” is rarely the right solution. Instead, it’s better to work with the author in such a way that we’re seen as an ally, not an obstacle. As illustrated in my examples (ignoring a field of inquiry in a literature review, an inadequate study design, plagiarism), the solution often lies in explaining the problem in such a way that its importance and the consequences are clear to the author, then providing suggestions that help the author solve the problem. If we make our solution sufficiently easy to accept, then it’s easier for authors to accept the solution than it is to fight us over the issue. In the case of plagiarism, wording such as the following might suffice:

“While I was researching concept to ensure that I understood what you were saying, I noticed that this complete sentence was taken, without modification, from reference. Although this practice is borderline acceptable if you cite the original source, it is considered plagiarism by many publishers, and may cause you serious trouble during the review process. For example, there is a significant risk that the author of the paper you are quoting will be one of the peer reviewers selected by the journal, and when they recognize their own words, they are likely to ask the journal to reject your paper and possibly even reject future papers that you submit. My advice is to rewrite the sentence as follows proposed new wording, rewrite it in your own words, or place the entire sentence in quotation marks; whichever solution you choose, you must provide a literature citation that defines the source of the text. Reviewers like to see their own work quoted, and are more likely to accept your manuscript if you do so.”

The goal is to carefully raise the issue, always with an emphasis on helping the author avoid trouble. Sometimes, you can’t succeed, as in the case of self-plagiarism that I described. In that case, it may be acceptable to allow the standard quality control process to solve the problem for you; in my example, the journal’s peer review process filled that need, but in the workplace, a quiet word to one of the managers or others who will sign off on a review can at least focus their attention on the problem. In other cases, the solution requires us to understand what factors will make the author take our advice seriously.

For most of us, it’s easy to believe that the consequences of such ethical questions are small potatoes in the larger scheme of things, and to pass responsibility for solving the problems to someone else. The temptation to do so is even stronger when we’re under deadline pressure or when we fear that we’ll get ourselves in trouble by making too much noise. Unfortunately, this abdication of our responsibility sometimes leads to very serious consequences indeed. The loss of the space shuttle Challenger and death of all its crew (http://en.wikipedia.org/wiki/Space_Shuttle_Challenger_Disaster(external link)) illustrates the consequences of a failure to make the necessary effort. The Challenger disaster had many causes, and there have been many detailed examinations of the causes of the disaster. I’m not an authority on the consensus opinion of all these studies, however I recently came across an intriguing explanation that hasn’t been explored perhaps as deeply as it should have been. In this case, the author challenged the conventional explanation that the engineers did not clearly explain the risk of launching the shuttle, instead proposing that the managers who made the decision were governed by economic considerations (they needed a successful launch to demonstrate the reliability of their rocket engines and secure additional contracts). Is this true? Possibly. But I find it hard to believe that any manager could have ignored a recommendation in which the consequences were clear:

“We all believe that if you launch the shuttle, you are likely to kill all its astronauts. The technical reasons for this are spelled out in Appendix 1. That’s bad enough, but you will also set back manned space exploration for many months, if not years [the actual delay was nearly 3 years], and will do irreparable damage to our company’s reputation, ensuring the loss of the contracts you hope to gain by launching the shuttle tomorrow despite our warnings. In this context, we are confident that delaying the launch by 1 to 2 additional days will be a minor problem, and we recommend that the launch be delayed.”

As in the case of my friend who nearly lost her job for blowing the whistle on plagiarism, this wording would not have gained the engineers any friends, but it would have saved several lives and protected the company against considerable lost income too, thus soothing some of the sting of the painfully direct wording.

If you’re lucky, most ethical problems that you face as an editor will be far less severe. But as I’ve illustrated in this article, it’s unwise (not to mention unethical) to simply assume someone else will spot and fix ethical problems for us.