GD
Geodynamics

First time… publishing a paper

First time… publishing a paper

I can’t speak for anyone else, but finally getting a paper through comes with the great satisfaction of not having to deal with the project anymore. There’s a sense of relief, hope, and maybe excitement that the time that is now freed up can be used on other, new projects. Anyway, I am currently still in this honeymoon period so please don’t ruin it by telling me it will end soon. After recently surviving this process, I feel I should share the opinions I have formed, which are unique to everyone, but maybe you can relate, learn from or laugh at them.

There are many common pieces of advice which are completely true and will make your life easier in ways you can’t imagine, so best to follow them. Some of this advice includes “don’t compare yourself to others” and “research is hard” or “take a holiday for God’s sake”. Because I’m assuming you have heard this advice and many more pearls of wisdom before, I will not repeat them here and will try to give a more unique perspective focussed on three themes.

 

 

Publishing your first paper is a long and challenging journey where many mistakes are made and lessons learned. Image by Daniel Cheung.

We all have the spiel prepared in case anyone asks us about our work: a few sentences to sum up what our project is about. Depending on who I’m talking to mine is “I study blobs inside the Earth using waves generated by earthquakes”. What I have realised, dear reader, is that this is a bald-faced lie: I do not spend the majority of my time doing this. Yes, the overall goal and work are related to it, but if I’m being totally truthful, my answer should be: “I try and mostly fail to solve problems I didn’t think would be an issue when I first started”. I am partly joking with this but there is a serious point that ties into the “don’t compare yourself to others” advice. When you first set out on this PhD journey, you may hear many comments from supervisors and colleagues that make it seem quick and easy to solve your problems or (seemingly) minor tasks. When it inevitably doesn’t go so quickly or easily as anticipated, it can be disappointing and you feel are falling behind (partly because of your now raised expectations of how easy the task is to do). Well, those comments and expectations of the ease of tasks do not take into account the random bug in your code, or unforeseen issues with lab work. Basically, the lesson here is:

You probably spend most of your time dealing with issues you did not expect, but that’s OK

 

A flower-delivering dog. Hopefully, you will see one after submitting a paper! Image by Richard Brutyo.

Submitting a paper is really nerve-racking. You have managed to jump through all the hoops, negotiate many, many paper drafts with co-authors, and your battered body is finally ready to submit. Then all the doubts about your work come flooding through as you are desperate to make sure every box on the online form is correct. After all, you do not want to make a fool of yourself. You press the submit button and then…

ERROR: ANNOYING THING X IS INCORRECT

After several attempts, the nerves and attention to detail disappear and are replaced with nothing but anger and frustration at the system which is taking you all day to just send off a PDF manuscript. You can finally be free of this monkey (i.e., your PDF manuscript), but you often have to fight against a tide of a poorly designed web page. Afterwards, all you really want is a dog to bring you flowers. While I can’t guarantee this will happen, I can show you what it should look like (see figure on the right). Anyway, the lesson learned here is:

Submitting a paper might be just as frustrating as all the other problems involved in the project. Take your time, and the rest of the day off

 

Don’t get me wrong, they are worth listening to (every now and then). The point I really want to make here is that it is worth discussing your work with people outside of your supervisor/advisor/co-author group. I found there were real turning points in my project from discussions with people outside of my regular academic circle. Some of these discussions happened during conferences, which also provide a great way to test how you communicate your project in terms of figures and the “story” (go to conferences!). Other discussions came from one-to-one meetings. These more intense discussions highlighted aspects of the work I didn’t think of and framed them in a new context. These changed and improved my projects significantly. My final lesson for you is:

Discuss your work with as wide a range of people as possible

There you have it, reader, lessons I learned while working towards a first publication. It was a hard, frustrating, and long road, but that’s also why it’s so satisfying when you finally succeed!

 

 

On each first Monday of the month, The PhD Chronicles blog series gives a special place for PhD researchers to share their successes, challenges, and failures. Would you like to share your story? Contact us here.

Jamie is a PhD student at the School of Earth & Environment, University of Leeds. His research project aims at developing and implementing a new seismic technique to quantify the level of refraction of the ray path and identify multipathing to constrain the location and properties of sharp velocity boundaries in the Earth's mantle. Whenever possible, Jamie is involved in some type of science outreach including Pint of Science, the after-school science club, and PubHD.


Anna is PhD student at the Geophysical Fluid Dynamics group at ETH Zürich, Switzerland. With the use of numerical modelling, she studies the interior dynamics of the Earth and Venus. Anna is the Early Career Scientist representative for the Geodynamics Division of EGU, and the topical editor for The PhD Chronicles blog series for the division's website. She tweets under @AnnaGeosc.


Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*