3 ms·

My main workflow improvement over the course of my PhD has been making my papers reproducible. This means: I clone a github repo, then I execute a single comman

by lqr 5y ago

My main workflow improvement over the course of my PhD has been making my papers reproducible. This means: I clone a github repo, then I execute a single command to re-run all computations, re-generate all figures and tables, and compile the final paper. Any manual step like "resize the figure window until the proportions look good", or "run script A, then run script B", or "upload this file to Overleaf" creates an opportunity for your results (figures and tables) to become out of sync with your source code. This can cause big problems. I use Makefiles, Anaconda, and Github CI to accomplish this [1], but the techniques don't matter. The point is the end goal. More broadly, in research it's always tempting to do things quick and dirty. Conference deadlines loom. Code bases are usually small and short-lived. But in my experience, your 4-months-later future self will appreciate tests, documentation, etc. just as much as your 4-years-later future self. You can still be quick and dirty when it comes to project scope. This is where you get most of the speedup anyway. Go ahead write a function that doesn't handle edge cases, but add a comment about it! [1] https://github.com/jpreiss/reproducible_papers https://github.com/jpreiss/reproducible_papers

josephdviviano 5y ago
^ this! your repo should have script(s) in it that re-generate, entirely, all of the binary results files that can be fed into some notebook to automatically generate the figures you put directly into your overleaf. Ditto for tables saved as text outputs. Also, write tests. No one will force you to, but it will save you from finding a bug a month before a conference deadline or during the review process, which can cost you way way more time than just writing the test. For lit reviews, I just do it in overleaf + bibtex. I wasted a lot of time with reference managers that I never seemed to use when I was actually writing my papers. When you read a paper you think you will need to cite, write two sentences describing the result and put a reference in an overleaf. That will serve as a great cognitive map when you're trying to find "that thing you read last year" but can't remember the names. Best part of this is your toolchain is light and flexible (these days I just use git, vscode, conda, and overleaf), and you will have clean github repos to show off when you're looking for the next step post-PhD.

by lqr 5y ago

josephdviviano 5y ago

^ this! your repo should have script(s) in it that re-generate, entirely, all of the binary results files that can be fed into some notebook to automatically generate the figures you put directly into your overleaf. Ditto for tables saved as text outputs. Also, write tests. No one will force you to, but it will save you from finding a bug a month before a conference deadline or during the review process, which can cost you way way more time than just writing the test. For lit reviews, I just do it in overleaf + bibtex. I wasted a lot of time with reference managers that I never seemed to use when I was actually writing my papers. When you read a paper you think you will need to cite, write two sentences describing the result and put a reference in an overleaf. That will serve as a great cognitive map when you're trying to find "that thing you read last year" but can't remember the names. Best part of this is your toolchain is light and flexible (these days I just use git, vscode, conda, and overleaf), and you will have clean github repos to show off when you're looking for the next step post-PhD.