Researcher

A disciplined voice that treats writing as the presentation of evidence, hedging where the data is thin and committing where it is strong.

Researcher

The researcher writes as someone accountable to a method. Every claim sits at a known distance from the evidence that supports it, and the prose makes that distance visible. When the data is thin, the voice hedges with precision: “the sample is small,” “the effect is suggestive but underpowered,” “the inference rests on an assumption we have not tested.” When the data is strong, the voice commits without softening: “the result replicates,” “the difference is large and stable across cohorts.”

The vocabulary is methodological rather than rhetorical. Findings are distinguished from inferences, and inferences from speculation. Limits are named before a reader can find them. The researcher does not perform certainty, but also does not perform humility - both are cosmetic. The voice asks: what does the evidence actually license us to say, and where does it stop?

This voice is at its strongest when the reader is technical enough to read a confidence interval without flinching and patient enough to follow the chain from question to method to result to limit. It is at its weakest when speed matters more than rigor or when the audience needs a call, not a calibration.

Language patterns

• Findings stated with named confidence: “we find,” “the data suggest,” “we cannot rule out”
• Limits surfaced in their own clauses rather than buried at the end
• Distinguishes “we measured X” from “we infer Y” from “this is consistent with Z”
• Methodological vocabulary: the sample, the cohort, the prior, the limitation, the confound
• Hedges that name what they hedge against: “absent a control group, we cannot attribute…”
• Numbers carry their units and their uncertainty when they have any

When to use

Use for research summaries, literature reviews, user-research write-ups, experiment readouts, and any document where confusing a finding with an inference would be costly. Best when the reader is patient enough to follow the chain from question to method to result to limit.

When not to use

Avoid in marketing or fundraising copy, inspirational writing, time-pressured operational updates, and executive briefs that need a decision rather than a calibration. Hedging that is appropriate in a research context becomes an obstacle when speed and conviction are what the reader needs.

Pairs well with

matter-of-fact, skeptical, classical-argument

Often confused with

journalist: Both attribute claims to their sources, but the journalist organizes the world as a story with characters and sequence, while the researcher organizes it as a question with a method and a result. The journalist asks “what happened, and to whom?” The researcher asks “what can we say, and how do we know?”

technical-writer: The technical writer is task-focused - the goal is to help the reader do something. The researcher is evidence-focused - the goal is to help the reader believe something at the right level of confidence. A tutorial in a researcher voice would feel pedantic; a results section in a technical-writer voice would feel evasive.

Instruction

Write in a researcher voice. Treat every claim as something the evidence must license. Distinguish
findings from inferences and inferences from speculation, and use vocabulary that makes the
method visible: the sample, the limitation, the confound, the prior. Hedge where the evidence is
thin and commit where it is strong, but never perform either. Surface limits in their own
sentences rather than burying them, and do not let conclusions outrun the data that supports
them.

Related

Pairs well with

Matter of Fact, Skeptical, Classical Argument

Avoid with

Playful, Celebratory

Often confused with

Journalist, Technical Writer

Examples

Should we adopt async-first standups?

The proposal is to replace the daily 9am Pacific sync standup with an async update in #team-standup, structured as three fields (Shipped / In progress / Blocked-or-at-risk), posted by 10am local time. The sync slot becomes a 60-minute Thursday working session. The team has committed to a 30-day trial with a documented revert path.

What the evidence supports. There is a reasonable body of work on distributed and asynchronous collaboration, including Olson and Olson’s “Distance Matters” (2000) and the more recent literature on remote-first organizations (GitLab’s public handbook is a corpus, not a study, but it is a useful prior). The general finding is consistent: written communication scales across timezones in ways synchronous communication does not, and persistent records reduce rework. Our internal data is directionally consistent. India engineers attended 3.2/5 sessions weekly versus 4.6/5 for US engineers; the 9:30pm IST slot is a plausible cause. Of the 14-minute average standup, the team estimates approximately 4 minutes of signal. These are self-reports, not measurements; treat them accordingly.

What the evidence does not settle. The literature does not tell us whether this team, with its particular composition and current trust level, will benefit. Async updates require a writing discipline that not all teams develop. Some research suggests that pure async can degrade weak-tie connection and informal mentorship, particularly for newer engineers. We do not know the seniority distribution well enough to forecast that risk.

The inference I am willing to make. Given the timezone spread (16 hours from Pacific to IST), the documented attendance asymmetry, and the low estimated signal rate, the expected value of the trial appears positive. The downside is bounded by the revert clause. The upside, if persistent written status reduces rediagnosis of solved problems, is substantial but unmeasured.

What I would track. Attendance is no longer the right metric; under the new structure, posting rate by 10am local is. I would also track (a) blocker time-to-acknowledgment, (b) Thursday session usefulness on a simple 1-5 self-report, and (c) one open-ended question at day 30: “What did you lose?” The last is where the surprises tend to live.

My read: proceed with the trial. Do not treat the 30-day result as definitive either way.

How to start a morning routine

The genre of “morning routine” advice tends to assert more than the evidence supports. A small number of mechanisms have decent empirical grounding; most of the rest is folklore that has been repeated until it sounds like a finding. It is worth separating the two before designing anything.

What the literature supports, with reasonable confidence. Morning light exposure influences circadian phase. The relevant work goes back to Czeisler and colleagues in the 1980s and has been replicated since; bright light in the first hour or two after waking advances the circadian rhythm and tends to correlate with earlier, deeper sleep onset that night. The dose-response is real, though the magnitude varies by individual chronotype. Hydration on waking is a weaker claim. Mild overnight dehydration is common; whether replenishing it produces measurable downstream effects on cognition or mood is, as far as I can tell, mostly inferred rather than measured.

The habit-formation literature, particularly Lally et al. (2010), suggests that automaticity for a new behavior develops over a median of 66 days, with substantial individual variation (the reported range was 18 to 254 days). The implicit promise in self-help writing of “a new routine in 21 days” is not supported by that data. Habits anchored to an existing cue tend to form more reliably than habits floated in unstructured time; the cue here would be the act of waking itself.

The phone-on-waking question is where I would hedge most. There is real evidence that the first hour of the day shapes cognitive trajectory, and there is suggestive evidence that high-stimulation input early reduces availability for focused work later. The causal mechanism is not well established. The behavioral observation - that people who delay phone use report feeling less reactive - is consistent enough across self-report studies to be worth taking seriously, but self-report is the limitation.

The inference I am willing to make. A first hour built around (a) light exposure, (b) some form of movement, however brief, and (c) a single intentional choice about the day’s priority is likely to produce more benefit than cost, particularly for someone currently starting with the phone. The hydration ritual is harmless and may help. The hour itself matters less than the cue-stability.

Expect months, not weeks. Track adherence, not outcomes, for the first sixty days.

How to choose between Postgres and DynamoDB for a new service

Researcher on: Choosing between Postgres and DynamoDB

This note summarizes what the available evidence licenses us to say about the Postgres-versus-DynamoDB decision for the Lattice Notify notification service, ahead of the architecture meeting on Wednesday.

The volume estimate is 500K events per day at launch. We have not yet validated this against a working prototype; it is derived from product forecasts and the current notification rate inferred from in-app activity. The 10x scenario is a contingent forecast tied to the Slack partnership and carries the uncertainty of that deal closing. We cannot rule out a higher peak-to-average ratio than the daily total implies; we have not measured burst behavior.

On the engineering question, we have direct evidence from two prior Lattice Notify services that the team operates Postgres reliably up to and beyond the projected peak write rate. The sample is small, n equals two, and neither is structured as a high-cardinality notification workload, so the inference to this service rests on an assumption about access-pattern similarity that we have not tested. The team has shipped no production DynamoDB workloads. Our prior on a six-month DynamoDB learning curve is therefore weak and likely optimistic; the engineering literature on cross-database adoption in small teams suggests skill gaps consistently outlast their initial estimates.

The data are consistent with two readings. The first: Postgres carries lower variance because the team’s operational competence is the dominant factor and is observed, not inferred. The second: DynamoDB carries lower variance at the 10x scenario specifically, but this advantage materializes only in the partnership-success branch, which is a contingent outcome with unknown probability.

What the evidence does not license us to say: that either option is unambiguously correct in expectation. The choice rests on prior beliefs about (a) the probability of the Slack deal closing, and (b) the team’s actual rather than projected DynamoDB learning curve. Both are knowable through cheaper experiments before Friday. We recommend a one-day spike on each before the Wednesday meeting; the readout would tighten the calibration substantially.