Writing scientific reports and articles is difficult. Too often, it is treated as a skill that can only be developed via repetition, feedback, and iteration. While practice and editing are two important components of learning to write technically, having a series of explicit principles laid out—guidelines, not rules, as Captain Barbossa of Pirates of the Caribbean is fond of saying—can be helpful, particularly for beginning writers. In this essay, I will introduce some of the starting points for technical writing and give some tips and tricks for beginners.
To begin, some definitions. An important definition is the idea of a “unit of discourse,” an idea I was first introduced to in Gopen & Swan’s inimitable 1990 article, The Science of Scientific Writing. Put simply, a unit of discourse is anything in a piece of writing that has a start and an end: a sentence, a paragraph, a subsection, a section, or the whole paper itself. Another definition is that of “the hourglass technique,” which refers in its most general and commonly used form to the idea of a paper as an hourglass, which goes from big picture (abstract/introduction) to “small picture” (methods/results) back to big picture (discussion/conclusions.)
From my previous sentence, you may have gleaned the answer to the question I posed in my title: a paper is like a fractal because it is composed of smaller and smaller parts that are essentially self-similar to the whole. You can zoom in or zoom out and ideally the form of the paper will still be that of an “hourglass.” How does this work in more concrete terms? Well – the paper itself has an abstract, giving you the big picture, and then it has sections that support the crude big picture in the abstract, and then it has conclusions, which bring back the big picture. But each section is like this as well, generally, at least in a full-blown paper: the section usually begins with an overview paragraph and then has subsections that go into greater detail, each of them providing support for the main point expressed in the overview. But each PARAGRAPH is like this as well! The first sentence of the paragraph should express the main point of that paragraph, then you should give details that support that point, then the final sentence should sum things up and maybe set you up logically for the following paragraph.
How can you put this into practice when you’re starting to do scientific writing? There are a few ways. First, if your brain is amenable to this sort of scaffolding work: creating an outline or skeleton can be helpful before you start filling in the full sentences. For example, you could fill out an hourglass template (see Fig. 1) for the paper, populate it with hourglass templates for each section, and populate those templates with hourglass templates for each paragraph. Alternately, if you’re the kind of person who works best with a stream-of-consciousness approach, you could use the template only for the whole paper and then keep it open beside you as you write out each section.
Figure 1. Hourglass template in an illustrative format. This template can be used to lay out any unit of discourse. The obligatory core should be found in any of them, regardless of whether your unit of discourse is a paragraph or an entire paper. The optional biggest picture points are used more commonly in whole-paper planning and in specific types of units, such as the abstract, the introduction, or a concluding paragraph.
As useful as it is for initial manuscript writing, the hourglass really shines in editing. Failure to follow the hourglass is a prime reason why papers can be hard to follow. It’s very easy to focus on all the details and forget to pull out the main points, because, when we’re doing the science, our day-to-day is mostly concerned with the details and with making certain all the details are correct. Keeping track of the details is very important, but using the hourglass will help the reader understand how those details fit together to make a coherent experiment and a coherent story.
Two good ways to use the hourglass when you’re editing are (i) see if you can fill out the hourglass template at each unit-of-discourse level with the draft after it’s been written and (ii) read through the “fat layers” of the hourglass at each level to diagnose issues. I would use the first technique particularly if you’re a “seat-of-the-pants” writer who didn’t start with a full outline. I recommend everyone use the second technique. To do this, highlight your title, your section titles, your subsection titles, and the first sentence of each paragraph. Reading only through those, ask yourself: does the story make sense? Don’t worry about whether it’s well-supported—after all, you’re ignoring the basic details that should support the point—can you understand what the author is trying to say? [RM4.1]Then, take note of places where the story doesn’t make sense—where there’s a contradiction, a logical gap, or just something that doesn’t feel quite right. For each of these “hiccups,” ask yourself whether the problem is that you have written your units of discourse in the wrong order, or whether the problem is that your big-picture description is really a detail and doesn’t properly convey the overall point that you wanted it to. This will tell you whether you should shake up your overall organization, write more informative big picture statements, or swap out your high-level piece of information for something that was left hidden in the details. As a note, lack of information in big picture statements is a particularly common problem in subsection headings, where people will write things like “Data Analysis” or “Analysis of Protein Behavior With X Tool” instead of telling the reader what they think the big takeaway should be, e.g. “Proteins Containing Charged Residues Are More Extended as Measured by Shape Parameter Analysis.”
At this point, I hope everyone shares my mental conception of a paper as a very wordy Sierpinski gasket. To summarize: every unit of discourse in your paper, from the whole thing right down to the individual paragraphs, should take the shape of an hourglass. You can use the hourglass motif to guide your initial writing, but it’s particularly effective if you apply it to diagnose structural issues when moving from a first draft to a second or subsequent draft. Go forth and create self-similarity!
References
Gopen, George D., and Judith A. Swan. “The science of scientific writing.” American scientist 78.6 (1990): 550-558.
https://writingcenter.uconn.edu/writing-in-biology-3/
In November 2025, I traveled to Ottawa as a representative of the Science Meets Parliament initiative, in which scholars from across Canada meet with senators and MPs to build connections between academe and government.
Today, I posted my personal reflection on it.
Exciting news from the Mansbach Lab! We’re thrilled to announce that our Principal Investigator has been selected as a delegate for Science Meets Parliament 2025 this November.
About Science Meets Parliament
Science Meets Parliament is a flagship program that brings together leading researchers, scientists, and policymakers to strengthen the connection between scientific research and government policy.
Being selected as a delegate is a significant recognition of our lab’s contributions to the scientific community and highlights the importance of our research in informing evidence-based policy decisions.
Learn more about the program: Science Meets Parliament 2025
Congratulations on this well-deserved selection!
A PhD student on our team, Vrinda Nair, has published an excellent article on Proteins as Biomarkers for Proteo.ca!
In this piece, Vrinda explores how proteins serve as crucial molecular indicators in medical diagnosis and treatment, acting as the unsung heroes that help clinicians make informed decisions about patient care.
Key Highlights:
The article delves into:
- How proteins function as reliable biomarkers in disease detection
- The role of protein biomarkers in personalized medicine
- Current applications and future potential in clinical diagnostics
- The intersection of proteomics research and practical healthcare solutions
This work showcases the important translational aspects of our research and demonstrates how fundamental protein science directly impacts patient outcomes.
Read the full article: Proteins as Biomarkers: The Heroes Behind the Scenes of Diagnosis and Treatment
Congratulations to Vrinda for this excellent science communication piece that makes complex proteomics research accessible to a broader audience!
Like many PIs, I am perpetually in search of sources of funding, especially right now, given everything that’s happening in the U.S. (I am fortunate to be in Canada, but I have collaborators in the States, so while I am certainly less impacted by the goings-on, I am still impacted.) I happened to come across a large company whose program offered a fairly substantial sum of research funding for about a year. It did seem to align with my research interests, so I took a slightly deeper look, including at the agreement for if nominated to receive this funding. Some of this was pretty standard stuff—coming to an intellectual property agreement, providing quarterly reports, etc. And then we came to the section on Open Source Software. Now, I do need to disclaim that I don’t know if this is standard or not (I wouldn’t really be surprised if it is).
The section on Open Source Software was pretty brief, noting only that one should only use or create software with a license listed by the Open Source Initiative and should not use or create software subject to a list of specific licenses, including… “Any of the JSON ‘do no evil’ licenses.”
What.
I had to read that again. I’m usually a pretty straightforward open source person, so I primarily stick to the MIT license, just because that’s what I know. A bit of googling around informed me that the JSON ‘do no evil’ license is, let’s say…contentious in the field of Open Source Software, as explained, for example, in this article, because it includes the phrase, “This software shall be used for Good, not Evil.”
Now listen, I get that “Good” and “Evil” aren’t defined in the license, and I even understand why that might give a legal team a headache. But on the other hand—really? It’s being referred to as “troublesome,” a “fly in the ointment,” and the simple explanation is, “Actually, defined or not, this clause is enough to disqualify the JSON License as an open source license per se. Point 6 of the Open Source Initiative (OSI) definition of an open source license is “No Discrimination Against Fields of Endeavour,” which would include evil ones.”
But…typically we do try to discriminate against evil fields of endeavor, and for good reason. (The old “paradox of tolerance” in which you can tolerate anything but intolerance.) The way this is phrased is tongue-in-cheek, of course, because the whole thing is tongue-in-cheek (notably, IBM has an exemption from the Do-No-Evil Clause).
Should it be, though?
Yes, “good” and “evil” are ambiguous concepts at best, and, yes, a focus on a binaristic good/evil divide is rather Western-centric. But at the same time, the STEM fields in general, and software engineering in specific, are absolutely not exempt from moral implications. What’s worse, they have a long and storied history of trying to pretend that they are. Computers are “unbiased” (no, they’re not [1]), algorithms never make mistakes (yes they do), algorithms certainly don’t cheat (yes they do), large language models aren’t bullshit artists (yes, they are [2]).
There is a tendency to believe that if something isn’t easily and clearly measurable, it isn’t the purview of software development. This leads to an old boys’ club mentality, to a desire to go-fast-break-shit, and to laugh and joke about pesky useless indefinable notions of moral integrity and good and evil.
But we, as a civilization, do define attempt to define moral integrity and we do attempt to define good and evil—at least to the extent of having laws that generally attempt to enforce some level of good. Those laws aren’t always beneficial; sometimes they’re pretty harmful. It’s still better than not trying at all.
But how can we possibly correctly assess the moral value of our work? Surely it isn’t possible to do, since, after all, “good” and “evil” are such grey, loaded, complex concepts. Wouldn’t it be better just to stick to things we can measure? Why not just build a language model that’s only trained on slurs? We can’t measure emotional pain.
I think we all know by now that my answer is going to be a resounding NO. Not all questions have a single, correct answer; some questions don’t have answers at all. That doesn’t mean there isn’t value in the act of asking them. Of course you should consider the ramifications of a language model that spews hate speech—and I don’t just mean the optics of it.
So maybe: don’t laugh at the question. Don’t act like you’re above asking what the impact of your work will be, and whether it will cause harm. There is no shortcut for this. Morality, integrity, and harm are all questions of context. Questions of history, philosophy, and ethics, and similar apply differently under different circumstances.
There is no one right answer to every question. The question is still important. I’m not expecting software engineers to personally solve the ills of the world. Hell, I even agree that sometimes you do need to use that software for evil—there is such a thing as a ‘necessary evil,’ after all. I just think that maybe it’s worth taking an hour or two to decide whether your software usage is good, evil, or morally neutral, and writing up a paragraph justification.
And then possibly I won’t click in to see that a big corporation is explicitly telling me that to work with them I have to be all right with not using a ‘do no evil’ software license without a trace of self-awareness or irony.
(Anyone remember when Google’s motto was “don’t be evil”? Yeah, me neither…)
References and Acknowledgements
[1] O’Neil, Cathy. Weapons of math destruction: How big data increases inequality and threatens democracy. Crown, 2017
[2] Hicks, Michael Townsen, James Humphries, and Joe Slater. “ChatGPT is bullshit.” Ethics and Information Technology 26.2 (2024): 1-10.
With thanks to Mari Magen for invaluable feedback