A useful research note begins with a question

Technical research often starts with a vague uncertainty: why did a request fail, whether a tool supports a particular feature, or which approach is operationally simpler. Write a narrow question before collecting links. Otherwise it is easy to accumulate sources without reaching a usable conclusion.

For example, replace “Investigate HTTP/2” with “Does the reverse proxy preserve streaming uploads when the client negotiates HTTP/2?” This question suggests specific evidence, tools, and failure conditions.

Keep an evidence ledger

Separate the source's claim, what you observed, and your interpretation. Include versions, dates, and environmental constraints. A documentation example is not a performance measurement, and an anecdotal issue report is not a universal failure mode.

A small research record can use these headings:

# Question
# Sources and versions
# Hypothesis
# Reproduction steps
# Observations
# Interpretation
# Unresolved questions
# Next decision

The distinction between observation and interpretation is particularly important when investigating networks. A failed connection could result from DNS, NAT, TLS, application behavior, or policy filtering; one symptom rarely establishes the cause.

Make experiments reproducible

Record exact commands, sanitized configuration snippets, environment versions, and the expected output. Avoid copying tokens, access credentials, or personally identifying logs into a notebook. If a command could mutate a system, label it as a change rather than a diagnostic step.

Use a predictable naming convention for experiment directories and keep outputs beside the questions they address. Prefer small, falsifiable tests. Change one relevant variable at a time, and note when uncontrolled factors could affect the result.

Read critically without becoming cynical

Official documentation is usually the best starting point for a supported interface. Issue trackers reveal edge cases and regressions, but individual reports may omit context. Community discussion is valuable for discovering hypotheses, not for replacing verification.

When sources disagree, preserve the disagreement. Note the software versions, networks, or assumptions under which each claim was made. A conclusion can remain provisional without becoming useless.

End with a decision or next test

Research becomes actionable when it leaves behind a conclusion, an explicit unknown, or a planned test. Link the outcome to the relevant procedure or design decision. Revisit the note when the underlying software or environment changes; do not simulate maintenance with invented “updated” timestamps.

Notebook principle: good research makes uncertainty visible and narrows the next useful action.