1. About
  2. Features
  3. Explore

I have been working on a project for almost a year now. This project involves the implementation of a computational method to calculate material properties and the application to different material systems. I have also done original modifications to the method during the course of the implementation.

At the moment I am in the process of writing down the details of the implementation and the results of my calculations. I have envisioned that the best way to break down the large amount of work that has been done is to write three papers. Chronologically: 1) one with the improved methodology with pertinent application results, 2) another one with the implementation details and 3) a final one focusing only on application of the code to a very interesting set of systems.

I think that writing papers 2) and 3) will become easier as I can simply refer the reader for details to 1) and 1) & 2), respectively, but I am having quite a bit of trouble finding the right narrative for the first paper, since I want to focus on the big picture of the theory and methodology but the little details of the implementation seem to constantly get in the way. This comes in the way of "we are trying to achieve this big objective A but in the actual implementation we did things a little different by changing B1, B2, B3, ...". This would distract the reader from the main point and becomes extremely disruptive from the point of view of the narrative flow. But somehow, it feels wrong to leave these details out since readers would otherwise assume we use the previous approach, or would simply not know how exactly we carried out the work.

I am wondering what are useful and effective strategies to write papers that can be read smoothly when there is a lot of fine detail involved that has not been previously published.

1 Answer 1

My field is biomedical so comments may or may not work for you. In our works, sometimes protocols did change along the way and occasionally I need to explain that in the paper. Hopefully these comments are general enough to be useful to you.

The primary goal is to think from the gain of the reader and maximize the gain:pain ratio. You want the ratio to be high: transferring the most to them with them going through the least amount of effort to understand your work. With that reason in mind, here are some suggestions:

  1. Really, very few people reading scientific journals are interested in the step by step saga in how we reach there. I know it may come off harsh but what matters to the researchers during the development process can be drastically different from what matters to the readers. So, cast a critical look and weed out details that are not bringing any gain.

  2. Minimize the "we wanted to do this, but then we ended up with that..." frequency. Try not to start every single sentence with this kind of structure because they sound trivial and never-ending. Instead, I'd suggest setting up a section called "original plan" (to hint that something was changed) and give it a good introduction. Then, you can have a section called "Modifications" to briefly but sufficiently explain major design changes.

  3. One device I found very effective is a graphical schematic. You can consider a graph of the original scheme. Then in the Modification section, use the first graph as blueprint, slightly grey out the contents, and then insert modified components in 100% black. Consider indexing the changes on the graph, and then in the text you can simply explain them sequentially.