Skeptical
Measured doubt that refuses to commit ahead of the evidence and asks what would actually change the picture.
Skeptical
Section titled “Skeptical”Skeptical tone is the register of measured doubt. It is not contrarian, and it is not dismissive. It is the tone of a reader who has noticed that the evidence does not yet support the claim and is unwilling to pretend otherwise. The skeptical writer asks “what would change my mind?” rather than treating the question as already settled in either direction.
The defining move of skeptical tone is naming what is NOT yet established. Where candid states uncomfortable truths and matter-of-fact states what is true, skeptical states what remains unproven, what the data does not actually support, and what we would need to see before committing. It is comfortable with sentences like “the evidence is thin here” and “this could be true, but we have not shown it.”
Skeptical tone is essential in research summaries, vendor evaluations, post-mortems where the root cause is contested, and any context where premature certainty would be a more serious error than acknowledged uncertainty. It signals epistemic humility without performing helplessness. The writer is engaged with the question, not refusing to engage.
Markers
Section titled “Markers”- Explicit gaps named: “we do not yet have evidence for X” or “this has not been established”
- Falsification framing: “what would we need to see to believe this?”
- Hedges tied to specific evidence, not generic softening: “given only N=12, this is suggestive at best”
- Distinction between absence of evidence and evidence of absence
- Counter-hypotheses surfaced rather than dismissed
- Conditional claims: “if X holds, then Y - but we have not verified X”
When to use
Section titled “When to use”Research summaries, vendor evaluations before commitment, contested post-mortems, strategic memos resting on unverified assumptions, and peer review contexts where the writer’s job is to test the claim rather than transmit it.
When not to use
Section titled “When not to use”Pastoral or devotional writing, celebratory updates, operational instructions where the reader needs to act, persuasion contexts where measured doubt reads as weakness, and crisis communication where the audience needs direction.
Pairs well with
Section titled “Pairs well with”researcher, pragmatic-architect, candid
Often confused with
Section titled “Often confused with”candid: Candid states a truth the writer has identified and believes - it just refuses to soften it. Skeptical states that the truth has NOT yet been identified, that the evidence is incomplete, that the claim is unproven. Candid is the tone of conviction delivered honestly. Skeptical is the tone of conviction withheld until the evidence arrives.
Instruction
Section titled “Instruction”Write in a skeptical tone. You are not dismissing the claim, and you are not endorsing it. Youare noticing where the evidence is thin and saying so. Name the specific gap: what has not beenshown, what assumption has not been verified, what alternative explanation has not been ruledout. Use the question "what would change my mind?" as a structural device. Tie hedges tospecific evidence rather than generic softening. Treat counter-hypotheses as worth surfacing,not as threats to swat down. The reader should finish with a clear picture of what is and isnot established.Related
Section titled “Related”Pairs well with
Section titled “Pairs well with”Researcher, Pragmatic Architect, Candid
Avoid with
Section titled “Avoid with”Pastoral, Reverent, Celebratory
Often confused with
Section titled “Often confused with”Examples
Section titled “Examples”The case for switching to async is real. India is at 3.2/5 attendance because 9:30pm is 9:30pm, and no amount of culture work fixes that. But before we commit, I want to be honest about what the 30-day trial can and cannot tell us.
What is established: the current standup hurts our India engineers. The 14-minute meeting with 4 minutes of signal is documented. Status not persisting is documented. These are the things I am sure of.
What is not established: that async standups will fix what we think they will fix. Thirty days is two sprint cycles. In thirty days we will know whether people post their updates and whether the Thursday session feels useful. We will not know whether async standups produce better coordination, fewer dropped handoffs, or higher India retention. Those are the outcomes we actually care about, and they take a quarter or two to show up.
I would also push on what “trial success” means. If thirty days in we have mixed results - say, 80% of engineers posting consistently, but two missed handoffs and one India engineer saying they feel less connected - what do we conclude? My worry is that we will read that result through whatever lens we already hold. The people who wanted async will see the 80%. The people who wanted sync will see the handoffs.
I am not arguing against the change. I am arguing for naming, before we start, what evidence would actually move us. What posting rate is the floor? What does “the Thursday session works” mean concretely - decisions made, blockers cleared, or just attendance? And what would make us roll it back?
If we cannot answer those questions now, the trial is mostly a vote of preferences with a calendar attached to it. Let us decide what we are measuring before we measure it.
The morning routine genre asks you to believe several things at once: that there is one right way to start a day, that the people selling the way have found it, and that the difference between your life and theirs is the routine. I want to take those apart, because most of what gets sold here is folk wisdom wearing a stopwatch.
What is reasonably well-established. Bright light in the first hour or two after waking helps entrain your circadian rhythm; this is real and the effect size is meaningful. Drinking water after a night of not drinking water is fine, though framing it as “rehydration” oversells the cup. Some physical activity in the morning correlates with better mood for that day in many studies, though the direction of causation is messier than headlines suggest.
What is not established. That checking your phone first thing causes a reactive day. That you must wake before 6am to be productive. That the first hour is uniquely valuable compared to the second or the third. That there is a universal morning routine. Most of these claims rest on testimonials from people who would be successful with or without a routine, and survivorship is doing a lot of work in the genre.
So if you are tempted to start a morning routine because someone on the internet told you their hour of journaling and cold plunges changed their life, the honest answer is: maybe. It changed theirs, possibly. It is not clear it will change yours.
What is worth trying, on weaker evidence: getting some natural light early, doing something that moves your body for ten minutes, and not opening work email until you have done one thing for yourself. That is a thin claim, but it is a thin claim I can defend. Anything more elaborate is a hypothesis you are running on yourself, which is fine - just call it that.
Skeptical on: Choosing between Postgres and DynamoDB
Section titled “Skeptical on: Choosing between Postgres and DynamoDB”Before Wednesday, I want to flag what I think is not yet established in this decision, because we are about to make a commitment based on assumptions that have not been tested.
The 500K events per day launch number. We do not yet have evidence for this. It is a product estimate from Priya’s team based on the notifications roadmap, not a measurement against a deployed system. The actual launch number could be 200K. It could be 1.5M. We have not done a sensitivity analysis that tells us at what point the decision would flip. If the real number is 5x our estimate from day one, we are not having the same conversation. What would change my mind: a tighter bound on the launch volume, or a stated commitment that we will treat the number as uncertain and design for a range.
The 10x Slack-partnership scenario. This is being treated as a planning constraint, but the underlying probability is unverified. We have not asked the BD team what their actual close confidence is. We have not asked what the volume profile would look like in the first three months versus the steady state. The 10x number itself is, as far as I can tell, an order-of-magnitude estimate, not a forecast. We are sizing a database decision off it.
The migration cost estimate of 3 to 6 weeks. This has not been verified against a real migration. It is Ana’s read based on the Redis migration eighteen months ago, which had different access patterns and a smaller dataset. I would want at least one engineer to write the migration runbook at a sketch level before we treat 3 to 6 weeks as a reliable number.
Marcus’s load test on Postgres at 2x launch volume. The 18ms p99 number is real, but it was run against an empty notifications table on dev hardware. We have not tested the cold-cache, partitioned, production-shaped scenario. The number is suggestive at best.
The on-call concern about a second database. This is presented as a hard constraint, but we have not actually polled the rotation. Two of the four on-call engineers have prior DynamoDB experience and may have different views than the rotation lead.
I am not arguing against either option. I am arguing that before we commit on Wednesday, we should be honest about which inputs are measurements and which are estimates dressed as measurements. If we still pick Postgres, we should pick it knowing we are committing on probabilistic grounds, not on settled facts.
- Ana