Keep a Weekly Research Log

Research gets messy surprisingly quickly. After a few weeks, it becomes difficult to remember which version you tested, why you abandoned an idea, or whether you have already tried the thing that just failed again.

A research log does not need to be polished. It just needs to leave enough of a trail that you, and anyone working with you, can understand what happened.

Where should I keep it?

Use whichever option you will actually keep updating.

An Obsidian vault is great but not easily shareable. A Google Doc is easy to share but not versioned. A Markdown file in Git is versioned but not as easy to edit on a phone.

I do not particularly care which one you choose. I care that the log is easy to find, updated regularly and connected to the evidence from your work.

An example structure for each week

## Week 1 — Day Month Year

### What I planned to do

- What was I trying to achieve this week?

### What I tried

- What did I actually do?
- Which method, configuration or version did I use?

### What happened

- What worked?
- What failed or behaved differently from what I expected?

### Evidence and artefacts

- Code snippets
- Plot, screenshot, photo or video
- Data or results

### Reflection

- What did I learn from the result?
- Why do I think it happened?
- Did this change my understanding or lead to a decision?

### Next steps

- What is the next specific thing I will try? (with emphasis on “specific”)

The headings matter more than the exact format. Keep entries short, but be specific. “Worked on ROS” will not help you later. “Replayed the recorded bag; the robot did not move as expected; the log shows a missing transform” will.

Try to update the log while the details are still fresh. Five minutes at the end of the week is much better than reconstructing a month of decisions the night before the final report or paper is due.