Digest of Research Power Tools

Digested from Philipp Winter's Research Power Tools. I found it very insightful and applicable.

Outline

1. Organising

1. Incorporating new skills

2. Curate a todo list

3. Plan your day

4. Track your time

5. Log your progress

6. Take meeting notes

7. Persevere

1. Eat healthy food

2. Exercise regularly

3. Regular sleep schedule to ensure enough sleep

4. Get enough sun exposure - ensure a healthy circadian rhythm

5. Practice meditation

6. Procrastinate productively

2. Reading

1. Paper reading tips (omitted)

2. Adopt a reviewer mindset

3. Read and engage in actual peer review

4. Join or organize a reading group

5. Organise your reading

3. Learn about new papers

1. Skim conference proceedings

2. Sign up for Google Scholar

3. Use arXiv subscriptions

4. Circumvent paywalls

1. sci-hub.se

2. https://t.me/scihubot

3. whereisscihub.now.sh

5. Versioning

1. git

2. overleaf

6. Writing

1. Write consistently

2. Capitalise on creativity: “Inspiration is perishable – act on it immediately.” 

3. Living documents

4. Modular decomposition of a research paper

7. Write better

1. Delete unnecessary words.

2. Use active instead of passive voice.

3. Engage your audience.

4. Ask for feedback

8. Write Effectively

1. Use LaTeX comments

2. Balancing references (\usepackage{balance} )

3. Better tables

4. Backreferences

5. Self-contained diagrams

6. Others:

1. Use decimal separators to make large numbers easier to read.

2. Use a ~ to prevent dangling references.

3. Citations are not nouns.

4. Use proper LaTeX quotation marks.

5. Reference more specific parts of a paper if possible.

9. Programming

1. Avoid functions that do too many things at once

2. Document encountered issues

3. Organise your directory structure

4. Make your code public

5. Use libraries

6. …for data analysis

1. Use precise timestamps

2. Automate your processing pipeline

3. Make your processing pipeline verbose

4. Collect data as raw as possible

5. Linux tools for data analysis (omitted)

7. …for systems building

1. Consider adding tests

2. Consider a design principle

3. Tackle the riskiest component first

4. Learn to navigate large code bases

10. Communicating

1. …with the world

1. Publish preprints

2. Presenting

3. Science Twitter

4. Teach the public

2. …with collaborators

1. Socialise

2. Manage collaborators

3. Email etiquette:

1. prefix an email subject with “FYI:”, “Action needed:”, or "Need Help:"

4. Pick the right communication mode

5. Communicate openly

6. Communicate extensively

11. Ideas

1. What’s a good idea?

2. Types of ideas

1. Invent a new system

2. Break an existing system

3. Measure something complicated

4. Study a user population

5. Survey the field

6. Critique of an area

7. Build a large, real-world system

8. Groundbreaking work

3. Creating Ideas

1. Your mind needs input

2. Capitalize on your situation

3. Investigate anomalies

4. Become a person that has ideas

5. Read critically

6. Get your hands dirty

Other Digests

How to form good habits

In the book Atomic Habits (Clear 2018), James Clear provides insight into why that is: the key to forming good habits (and eliminating bad ones) is to

1. create an obvious cue to trigger an action,
2. make the action’s outcome attractive,
3. make the action easy to perform,
4. create a satisfying outcome.

How to construct a to-do list

To-do list: The trick is to make it a seamless part of your workflow.

1. Today
2. This Week
3. Eventually

A day without a schedule risks devolving into yak shaving: imagine you want to fix that annoying bug in your code that has been messing with your experiments. While thinking about how to best fix the bug, you notice that the function that contains it has poor documentation. So you spend a moment updating the documentation. While doing that, you realize that your functions follow an inconsistent documentation style, which really annoys the perfectionist in you. So you harmonize the way functions are documented in your code, and in the process, learn that the documentation tool you’re using has released a new version with convenient new features. However, your operating system doesn’t have the newest packages yet, so you set out to compile it manually. Three hours later, you find yourself hunched over your laptop, covered in sweat, finally with the new version of your documentation tool. That bug that you originally intended to fix? It’s still there.

Well-calibrated BS filter

Throughout my career, the smartest and most capable people in the room all shared one trait: they had a well-calibrated bullshit filter and would not fall for “smooth talkers.” We all need to strive for that.

Learn about new papers

Every conference cycle brings with it a new set of papers with the potential to affect your research. It’s important to stay up to date on these new papers because (i) you need to know if a research group has been working on the same problem, and has published before you (this is called getting “scooped”); (ii) you can learn about new research directions that you may want to pursue; and (iii) you may learn about ways to improve your own work, e.g., by building on better methods or datasets. My favorite ways to find out about new papers are to :

1. regularly skim conference proceedings
2. use arXiv subscriptions
3. set up Google Scholar notifications.

Treat research papers as living documents

I treat my research papers as living documents. One of the first things I do when starting a new research project is to create a paper.tex file. I use it to jot down bullet points about research ideas, how these ideas connect, and can ultimately be presented. These bullet points eventually turn into sentences, paragraphs, and then a finished paper. Once I start writing code or collecting measurement results, I try to distill key results and start thinking about a narrative.

Open-source your code!

Scooping is not the only issue. It is also intimidating to publish code – or anything, really. By making your brainchild available for everyone to inspect, you are exposing yourself and taking a risk. What if people will find your code inefficient and judge you for it? The good news is twofold. First, it is very uncommon to attract negative attention for publishing free software. Second, you do get used to publishing work. As intimidating as it may seem in the beginning, it does get easier, to a point where it is routine. The work output of my last two jobs at Brave Software and The Tor Project happened almost entirely in the open. We coordinate over email, IRC, and bug trackers and code is by default free. I have eventually grown used to this kind of philosophy but it used to be foreign and intimidating to me. Imposter syndrome is widespread, and few things are more intimidating than voicing an idea in public, surrounded by competent people who call bullshit when they see it.

Here’s another way to look at it: Free software is a community effort. You don’t get to complain about software that’s freely available. If you are unhappy with it, fix it. The software is free, after all. People have been unhappy with my research prototypes many times, and I am fortunate to have received numerous patches over the years. I was always flattered to learn that somebody cared enough about my software to write a patch for it. Maintaining a popular library or measurement tool can not only be fulfilling but provide you with a very real advantage: people will turn to you for help (and as a result, you may end up co-authoring papers) or at the very least cite your work in their papers. There aren’t a lot of people who publish their code proactively and doing so sets you apart from your peers.

Summary

1. To make your code more reliable and speed up the development process, use high-quality libraries.
2. To make your code more robust, consider adding unit tests.
3. To make your code more structured, consider following a design principle.
4. To make your work more useful to peers (and gain recognition), publish your code.

Summarize your project

I recommend that project pages have at least the following sections:

Project summary: Start with a paragraph that summarises your project. Similar to an abstract, it should convey (i) what problem your project solves, (ii) how it solves the problem, and (iii) what the results are. Try to write the project summary for a broad audience; write it the way you would explain your research to someone in another department, or to someone in the grocery store. In other words: use simple language and avoid jargon.

Datasets: If your research uses a dataset, then your project page should link to the data. You may not want to host datasets yourself, especially large ones. Consider using the Internet Archive to archive your dataset; link to your Internet Archive page from your project page.

Code: Your code matters because it allows others to reproduce your work. We, therefore, have an obligation to publish our code. Code is never perfect, so don’t ever be embarrassed about your code’s quality. No reasonable person will judge you by the quality of your code. As with datasets, there is no need to host code yourself: feel free to link to a GitHub or GitLab repository.

Papers: Papers are the main outcome of a research project, so we should all make our research papers and other write-ups available on our project pages. Be sure to make your paper openly accessible instead of linking to a paywalled portal. Research papers behind a paywall are injustice and prevent less wealthy scientists from engaging in the scientific discourse. If you are worried about the legal consequences of publishing a paper outside a paywall imposed by the publisher of record: don’t be. I have yet to hear of a single case of a scientist getting into trouble for making their own work available.

Contact information: Consider providing contact information to make it easy for fellow researchers to reach out to you. Try to use email addresses that will still work five years from now – even if this means using your personal address instead of your university email address.

Effective communication

Effective communication creates numerous opportunities by:

1. exposing your research to people who would otherwise not see it
2. saving time
3. “selling” your work
4. earning the respect of your collaborators.

Conferenceware

Analogous to freeware and shareware, there exists the term conferenceware – a mildly derogatory term that refers to the type of software that’s typically published as part of a research paper. Conferenceware is abandoned, outdated, poorly documented, and written in a haste. It’s often frustrating to use someone else’s conferenceware and worst of all: badly written code jeopardizes the correctness of the science. A simple bug can result in incorrect data and misleading conclusions.

Engage your audience

Never start your paper with something entirely obvious and uncreative like “The Internet has become the world’s biggest communication network.” You are more creative than that! Nobody expects pearls of wisdom at the very beginning of a paper, but actively try to make your paper as engaging to your reader as possible. Take a look at the introduction of a seminal paper in the field of cryptography (Diffie and Hellman 1976). Its first sentence is a classic.

Finally, keep in mind that good writing is often subjective, and not everyone will agree with my advice. I once got this feedback on one of my paper submissions:

First, authors abuse of questions in the paper. Writing a scientific paper is not writing a “thriller”. No suspense is required (this makes the reading pretty much annoying). We only have to write about facts.

Reviewer A

Reviewer A is the kind of person who starts their paper by pointing out how important the Internet has become. Don’t be like reviewer A. Bring some colour to your writing.