↓ Skip to main content
Chemical Cognition Lab
Chemical Cognition Lab

5. Research & Projects

Last updated:

Problem first
#

We prioritize in this order: the problem, then the data, then the model. A clever model on a problem nobody cares about, or on data that can’t support it, won’t get far. When you describe a project, work through it in that order: the problem, the ML task, the data, the modelling, and how you’ll evaluate it.

New ideas
#

I’m open to research ideas. Sell me on them: why is it worth the time, and is it feasible? Anything can become a research paper; the work is finding an interesting way of telling the story. Common failure modes are getting too attached to one direction, not knowing the field well enough yet, and working in an environment that doesn’t support your interests. Talking to other researchers about their taste helps with all three.

De-risk your ideas
#

Learning to de-risk ideas is one of the most useful research skills you can build. The idea is “kill fast, learn fast”: test the core assumptions quickly, before investing months.

One exercise: list the likely bottlenecks, prioritize them, commit a fixed amount of time to exploring each, then decide whether to continue or punt. For example, if you want to fine-tune a large model, first time a single batch of your largest model on fake data. Does it fit in memory? Multiply by the number of batches and a guess for epochs. Is the time to train one model reasonable?

Balancing multiple projects
#

Once you’ve ramped up, I expect you to juggle two or three projects at a time. Research has natural ebbs and flows, whether you’re waiting on compute, collaborators, or paper reviews, and having more than one project helps fill those gaps. Still, there is real value in focusing on one thing at a time, and we try to walk that tightrope together.

Design docs
#

Any time you’re about to spend more than a week on something, write a short design doc first covering what you’re building, why, the alternatives, and how you’ll know it worked. Writing it down helps clarify your plan and gives others a chance to spot issues early. Good introductions: Design docs at Google and Things I learned at Google: design docs.

The project spreadsheet
#

We keep a project spreadsheet [TBD] with ideas, timelines, and who’s working on what. Seeing active and paused ideas in one place makes it easier to talk to people and find connections across projects.

Pivoting is normal
#

Recycling, punting, and pivoting on projects is normal. Sometimes ideas don’t work, and what matters is diagnosing that as early as possible.

Sometimes deadlines get met by sprinting. In general it’s better to plan ahead, but sprints happen. If you’re going to do one, be focused about it so you can actually meet the deadline.

Reproducibility and data
#

Our work should be reproducible, with good data management. I’m a big fan of Cookiecutter Data Science, an opinionated and sensible way of organizing projects, and our project template builds on it. A few of its opinions we follow:

  • Raw data is immutable. Never edit or overwrite it; code should take raw data to final results.
  • Data mostly stays out of git. GitHub rejects files over 100 MB, so keep data on lab or cloud storage.
  • Use notebooks for exploration and communication, and move reusable logic into source files.
  • Keep modelling organized: configs and hyperparameters in JSON or YAML, predictions and training logs saved alongside.
  • Build from the environment up, with an environment file (we use Mamba).

Be transparent with your work and show it: put it in a GitHub repo and make commits. We usually won’t look at your commits in detail until we’re publishing something. What matters more is that you have a consistent way of keeping track of your work.

Authorship
#

Authorship is a conversation to have early and often. It can be uncomfortable, but it’s better to be honest and not have regrets.

Multiple first authors are encouraged. Spread the wealth and be generous, but also be fair: we don’t add people just because they could be there. To be generous, you have to create those opportunities in the first place. Co-first author order can be decided loosely; even if it shouldn’t matter, the first position does. The last author is usually the PI, reflecting funding and supervision. In collaborations, that’s a discussion between the PIs.

Where we publish
#

Our archival venues are AI conferences (such as NeurIPS, ICML, and ICLR) and journals at the intersection of chemistry and machine learning (such as Nature Machine Intelligence, Chemical Science, Digital Discovery, and Journal of Chemical Information and Modeling). Workshops are usually non-archival unless they announce otherwise.

Preprints
#

I recommend always preprinting. It’s better for visibility, citations, and open access, and it’s a good milestone. Post when you’re close to submission and confident. The only risk I see is a false sense of being done.

Scooping
#

Scooping happens because good ideas occur to several people at once, and independent work also serves as replication. A nine- or ten-page paper only captures one angle of a problem anyway, so there’s usually room for multiple perspectives on the same idea.

Writing
#

Writing a paper takes deliberate setup. There’s no single formula, and what works for you may change over time, but here’s a sequence I recommend:

  1. Start with the figures. How would you want to tell the story?
  2. Write the structure: Introduction, Methods, Experiments and Results, Discussion.
  3. Write a 2 to 3 sentence pitch for your idea.
  4. Write bullet points inside each section for what you expect to cover.
  5. Fill in text, and repeat.

Start small, accept imperfect drafts, and build from there.

For tools, I recommend Google Docs for drafting (fast, simple, collaborative) with Paperpile for references: copy a DOI and let the software figure out the rest. When we’re close to submission, we export with BibTeX to LaTeX on Overleaf.

You can also write with other people. Pair writing works much like pair programming, since talking through your thoughts with someone else puts you in a different mode. Communal writing sessions add a bit of social accountability: set a concrete goal (“finish half a page of the introduction”), write for a fixed block of time with breaks, share progress at the end, and talk through whatever is making the section hard.

Resources:

Feedback timelines
#

These are ideals:

  • Workshops and conferences need at least two weeks once it’s clear you’re aiming for one, with multiple iterations.
  • Journal papers need at least a month to polish figures and writing.

In general, we want to iterate a lot. The more we iterate, the higher quality our work. This is one more reason consistent work matters.