There is a lot of well-informed literature regarding how to choose your research topic, how to conduct the literature review, how to write the thesis or a paper, and there would be no point in me covering them all over again. But, in most cases as I’ve seen with my colleagues, lack of foresight regarding your writing process, and the general ambiguity of research process will harm your productivity greatly even if you follow such instructions to-the-teeth. Unless of course, you know what to prepare for! This works out well in some cases (speaking from experience). While the head-scratching phase of what to pursue for research is going on, there’s a lot of practical progress to make and fortunately, you can cross them off quite easily, very early on. Here are some practical tips you’d better be aware of before starting your writing.

I will start off with tools, and get to some writing/researching tips in a later post.

Choosing your tools

Word processor vs Text editor

There’s the obvious choice, which came with your operating system of choice. But wait, there are some very specific issues to think of when it comes to a large document which is alive. What do I mean by “alive”? Let me list some possible concerns.

Continuous editing on a daily basis: Your finished product will be the result of many edits. Each research paper you read will update your view on something you’ve written previously. You do not want to be editing a bulky document which takes forever to load and scroll.
Version Controlling: Honestly, is that inbuilt version control going to be enough for you? Also, how do you know you haven’t accidentally made a type in a perfectly proof-read section of your document? Here, “git diff” or “git diff –color-words” could be your friend my friend.
Alignment readjustments: A byproduct of continuous editing would be formatting updates. Large table? Landscape it! Oh but then your page numbering is broken. Oh that picture you referenced on page X is now on page Y, and it’s only partially visible.
Maintaining multiple lists with different styles: There’s the reference list, which you may have to integrate with an external tool unless you like manually inputting reference data taking precious time from your actual writing process. There’s the list of figures, there’s the list of tables, abbreviations, appendices, equation lists, and any other custom glossaries you’d like to have.
Maintaining multiple sections separately: You would have to combine them manually once you’re done. You would never get an idea of what horrors that might bring. Honestly has copy pasting large chunks of formatted text ever been that smooth?
Commenting and notes to self: This is one major perk that is not present in any word processing software. Of course there are comments, but what of formatted text that needs to be commented until you find another research paper that asserts your statement? What about Todo annotations you can search and edit later, what about other such keyword based notes you can add for yourself inside the text itself, just a simply search away!
Writing Environment: Do you really want to stare at Times New Roman all day long? I mean, really??

These are just some nuances of word processing software. So what’s the answer?

LaTeX and a text editor you’re comfortable with, of course. Using latex will never go amiss. The point here is that you need a more granular control over an alive document which needs branching off, and through version controlling and a review before permanent commitment. (This is actually same for something like your CV. It has to adjust to each job).

You will have to start learning Latex. It’s a wonderful language that will make you suffer when it comes to setting it up locally. But there’s always online latex editors such as Overleaf which will simplify that process. Still, you would have to get a paid subscription for git integration so it won’t all be roses. If you do set it up locally, you do this once and everything else would be very easy. I personally use overleaf for assignments, and use the local git repository for thesis document.

To sell this a little bit more, let me tell you a story. A thesis template being of a known standard, I scoured our university website for one, and adjusted my styling properties accordingly way before I’ve even chosen a research topic. This was a slightly old template, and a few days before the submission date, my supervisor asked me to update it in some aspects. Because I had set it up on latex, I barely had to look at the document after doing the required change.

Perks and Idiosyncrasies of LaTeX

Includes are excellent. You can section your research into multiple topics and embed them in a page seamlessly. The frontmatter and backmatter can be left untouched. You can version control to your heart’s content. You can include CSV files by themselves! Even in case of images, you just change the file itself and you’re done.
Speaking of commenting, it was highly useful to use a function for Todo and other kinds of notes to yourself, which is visible at the editing phase, but you conveniently make invisible during the exporting pdf document phase.
One thing I like about latex is it has a package for everything.. Until it doesn’t. So I’m still quite early in my research based endeavors and it has served me faithfully. One occasion I remember being let down is breaking a table across multiple pages with a specific formatting requirement. Apologies for the vagueness.
Collaboration and reviewing can be taken to a whole new level with LaTex and Git. I mean, your supervisor can review changes are they are being made. (They can, but they probably won’t. Maybe you could at least outsource proof-reading this way.).
Decouple styling with actual viewing experience. Of course this is done through the Text Editor, while LaTex keeps the styling just the way you want it to be printed.

Reference Maintenance

What should we expect from a reference manager?

Recording the progress: What you’ve read, are reading, will be reading.
Highlighting important aspects, ability for inline comments
Syncing partially read/annotated documents between multiple devices
Maintaining reference property data.
Grouping of research papers when working on multiple projects
Exporting (preferably automatically) the collective references you plan to include as your bibliography.

Of course the reference property data maintenance can be done simply by obtaining the BibTex reference (.bib file) from Google Scholar itself. But I would recommend using something like Mendeley, and here’s why.

Pros and Cons of Mendeley

Maintaining individual PDF files with annotations is going to be a nightmare. It could result in conflicts. Mendeley solves this, to a certain extent by abstracting annotations to a different level.
You can organize and section your research accordingly.
Some PDF files can obtain automatic references from the database, so your missing reference properties could be filled automatically. Beware though, depending on the PDF file used, sometimes garbage values will be updated
You can comfortably keep a sometimes automatically updating bibtex export file, which you can easily integrate to LaTeX. But this is only exported to one location, so it could be problematic when simultaneously working on multiple projects.
You cannot use handwritten annotations. This is one of the biggest drawbacks, but I can’t call it a drawback given how had it has been made to casually write on pdf files by existing editors. You can of course open the file externally and write on it. Mendeley Desktop version supports this. But it will screw up the automatic reference data updates from their database.
Although I haven’t used it for collaborations, it has features for it if needed.
Some word processing software integration is supported by Mendeley, but it might carry a little overhead.

My Build Environment

So, as I mentioned above, I am enjoying a well maintained writing environment. To give a little more insight into what that looks like, behold! Following is my directory structure, more or less.

│   .gitconfig
│   .gitignore
│   main.tex
├───bib
│       write-done.bib
│       write-to.bib
│       research.bib
├───build
│       pdflatex_bib.bat
│       removefields.rsc
├───data
│   │   img.png
│   │   tabular_data.csv
│   └───diagrams
│           original_img.drawio
├───functions
│       university_styles.tex
│       user_defined.tex
├───input_files
│       backmatter.tex
│       frontmatter.tex
├───sections
│   │   abstract.tex
│   │   title.tex
│   └───frontmatter
│           acknowledgment.tex
│           cover.tex
│           declaration.tex
│           dedication.tex
│           table_lists.tex
├───target
└───TeX_files
    │   abbreviations.tex
    │   appendices.tex
    │   chapter01.tex
    │   chapter02.tex
    ├───appendices
    │       appendix01.tex
    ├───chapter01
    │       chapter01_01.tex
    │       chapter01_02.tex
    ├───chapter02
    └───chapter03

I compile these files into the “target” folder and copy the final PDF back to the working directory for the TexWorks to render. To do this and some other optimizations, I use a windows batch file. But moving on to setting all this up,

Install Git
Install MikTeX
Optionally, download Bibtool, compile and add to path. You do not need to do this unless you find you have very specific requirements that can’t be easily achieved by Biber or Bibtex directives. These can be integrated through MikTeX.
Use MikTex-console with Admin rights to download any needed packages.
Compile main.tex using TexWorks/TexMaker or any preferred tool
For a text editor, you could use something such as Atom or Sublime Text. I prefer atom, and both editors have Latex Snippets packages you can download to make your life easier. A Latex editor itself such as TexWorks would serve just fine, but I prefer more control over editor color and font schemes. It’s a long, long editing process and you need to make yourself comfortable for it.

So in case for some reason you end up using Bibtool, (I use it to reformat/reorder my entries for more clarity in git commits, and to remove some unnecessary fields Mendeley populates.), you will have to set up a batch file and add the needed executables to the path, or call it through TexWork Typesetting like I do. So my batch file contains the following. Arguments 1 and 2 are fullname and basename of the file, main.tex vs main

bibtool.exe -q -s -r build\removefields.rsc -i bib\write-done.bib -o bib\research.bib
miktex-pdftex.exe -synctex=1 -undump=pdflatex -aux-directory="target"  "%1"
biber.exe --output-directory "target" "%2"
makeglossaries.exe  -d "target" "%2"
miktex-pdftex.exe -synctex=1 -undump=pdflatex -aux-directory="target"  "%1"
miktex-pdftex.exe -synctex=1 -undump=pdflatex -aux-directory="target"  "%1"

TexMaker is used by me for one purpose only, which is counting the words in the compiled document. Yes, I understand it’s overkill but Tex Editors count the latex code as well and god forbid there’s an easier way for PDF readers to calculate this. Last but not least, I get rid of all the warnings and most errors by replicating the troublesome code in Overleaf. It is a very useful tool when the whole debugging process requires recompilation over and over.

So this concludes the end of the tools section. I will move on to some practical tips such as research logging, and continuous editing and in which scenarios they became useful in a follow up post.

The goal here is not to convince you to use the tools I have recommended. The goal is to show you that a little forethought can save you a lot of trouble down the road. You can make a conscious choice about the unnecessary problems you think are not worth your time when you’re pressed for it, and solve them preemptively. In any case, any tool you use should simply make your delivery lean and comfortable to you.