The Method Is Not the Package: A Note on Writing Your Research Paper

You may have written a sentence like this:

“We used scikit-learn to cluster the patients into subgroups.”

It reads fine. It’s honest. It’s also, on its own, a methodological gap that reviewers will catch.

The problem: the tool is not the method

A software package is an implementation. It is not a method. When you write “we used scikit-learn,” you’ve told the reader which hammer you picked up, but not what you actually did with it. Did you run k-means? DBSCAN? Hierarchical clustering with Ward linkage? scikit-learn implements all of these, and each rests on different assumptions, has different failure modes, and answers a different question about your data.

The same is true almost everywhere in computational research:

• “We analyzed the data with pandas” tells the reader nothing about what statistical test was applied.
• “We used PyTorch to model the relationship” doesn’t say whether that’s a linear regression, a random forest, or a transformer.
• “We visualized the results in R” says nothing about whether you ran a t-test, ANOVA, or a mixed-effects model before making the plot.

If a reviewer — or a reader trying to reproduce your work five years from now — can’t reconstruct what you did from your methods section alone!

The fix: method first, package second

The structure that solves this is simple, and once you internalize it, it becomes automatic:

1. Name the method. State the statistical or computational technique you used, in plain terms. “We performed a paired t-test to compare pre- and post-treatment scores.” “We fit a random forest classifier to predict outcome status.”
2. Cite it, if it’s not a classical technique. If you used the standard Pearson correlation coefficient, no one needs a citation — it’s been in every statistics textbook for a century. But if you used a less universally known method — a specific variant of a mixed model, a particular dimensionality-reduction technique, a newer algorithm from the last decade — cite the paper that introduced or validated it. This tells the reader why the method is appropriate and gives them a path to understand it in depth if they want to.
3. Then, and only then, name the implementation. “…as implemented in the lme4 package in R (Bates et al., 2015).” “…using the RandomForestClassifier class from scikit-learn (Pedregosa et al., 2011).” This tells the reader exactly how to reproduce your analysis, down to the software version if you’re being careful.

Notice the order. Method, then citation for the method (if needed), then package. Not the reverse.

A worked example

Weak version:

“Missing values were handled using the missForest package in R.”

This tells the reader a package name, but not what missForest actually does. Is it single imputation or multiple imputation? Mean imputation or something model-based? A reviewer working on missing data methodology will want to know.

Stronger version:

“Missing values were imputed using a random-forest-based iterative imputation procedure (Stekhoven & Bühlmann, 2012), implemented via the missForest package in R (v1.5).”

Now the reader knows the actual statistical approach, has a citation to the method’s origin paper if they want to understand its assumptions, and knows exactly which software and version to use to reproduce it.

Why this matters more than it seems to

This isn’t pedantry for its own sake. A few concrete reasons it matters:

Reproducibility. Someone trying to replicate your analysis in a different language or environment needs to know the algorithm, not just the library call. Packages get deprecated, change their defaults between versions, or don’t exist in every language — the method persists regardless.

Credit. Citing the method gives credit to the researchers who developed and validated the underlying technique, which is often intellectually separate from — and predates — whoever wrote the software wrapper around it.

Reviewer trust. When a methods section names the technique and its provenance clearly, it signals that you understand why you chose that approach, not just that you found a function that ran without errors. This is often the difference between a methods section that invites scrutiny and one that survives it.

Your own future self. Two years from now, when you’re writing the discussion section of your next paper or defending your dissertation, “which method did I actually use here?” is a much easier question to answer if your original paper documented the method, not just the package name.

A quick mental checklist

Before you finalize a methods section, ask yourself for every analysis step:

• Have I named the actual technique, not just the tool?
• If it’s not a classical, universally-known method, have I cited the paper that introduced or validated it?
• Have I named the specific implementation (package, function, version) after establishing the method — as a reproducibility detail, not as the headline?

If you can answer yes to all three, your methods section is doing what it’s supposed to do: letting someone else understand, evaluate, and reproduce what you did — not just what you clicked.