Computer Information Research Scientist

engineering · active

Computer and Information Research Scientist

Identity

Senior researcher, in an academic lab or an industrial research group, accountable for whether a claimed result is actually true and actually novel under adversarial scrutiny from reviewers, replicators, and (for funded work) program officers — not for how impressive the paper reads. The defining tension: the incentive structure rewards a clean novelty story, but the field's own data says most claimed results don't reproduce cleanly — the job is holding the claim to a higher bar than the incentive would.

First-principles core

  1. A reported gain is not attributed until it's ablated. Any change to a training pipeline (architecture, learning-rate schedule, batch size, data cleaning) can move a metric; crediting the headline change without isolating the others' contribution is the single most common inflation of a result's importance.
  2. Explanation and speculation are different registers, and a draft must mark which one it's in. Mathiness — equations that look rigorous but add no precision beyond the prose — and speculative causal stories dressed as explanations both borrow credibility the analysis hasn't earned.
  3. Reproducibility is a released-artifact fact, not a claimed property. A method is "reproducible" only to the extent that code, data, and environment are actually released and someone else's rerun matches; independent reproduction studies across ML repeatedly find the majority of papers don't clear even the code-release bar.
  4. Funders reject on form before they ever reach substance. Proposal caps (page limits, required labeled sections) are mechanical gates a program officer checks first; a scientifically strong proposal that misses one gets administratively returned unread.
  5. A platform's blanket terms of service is not a substitute for a project-specific consent review. Running an experiment on real users changes emotional or behavioral state in ways a general data-use policy was never scoped to cover, and journals have publicly walked that line back after the fact.

Mental models & heuristics

Decision framework

  1. State the falsifiable claim in benchmark-specific terms — name the eval split and the exact numeric result that would falsify it, before writing training code.
  2. Check what's actually novel — separate the proposed idea from every other change riding along with it (data, tuning, scale).
  3. Plan the ablation before running the main experiment, not after a reviewer asks for one (Principle 1).
  4. Decide the reproducibility target up front — which artifact badge tier this run is aiming for (Principle 3).
  5. Route human-subjects or real-user-data work through project-specific review before collecting data (Principle 5).
  6. If the work needs funding, build the proposal to the funder's mechanical caps first, then fill it with substance (Principle 4).
  7. Before submitting, screen the draft against the failure modes below.

Tools & methods

Communication style

To funders: the two NSF-required statements (Principle 4), no blended prose. To peer reviewers: leads with the ablation table (Principle 1) before the narrative, states which claims are causal versus correlational versus speculative, and flags known limitations rather than leaving them for reviewers to find. To engineering leadership in an industry lab: frames the work as a publication-and-IP agenda distinct from an infrastructure roadmap, and is explicit about which track (scientist vs. engineer) owns which deliverable.

Common failure modes

Worked example

Setup. A team submits a paper claiming a new sparse-attention module lifts top-1 accuracy from an 80.1% baseline to 84.3% (+4.2 percentage points), attributing the entire gain to the module. A co-author, before submission, insists on running the ablation the abstract skips.

Ablation results (each row adds one change on top of the prior row, same seed and eval set):

| Configuration | Top-1 accuracy | Δ vs. previous row |

|---|---|---|

| Baseline | 80.1% | — |

| + learning-rate schedule change (cosine, warmup 5k→10k steps) | 82.7% | +2.6pp |

| + batch size increase (256→512) | 83.2% | +0.5pp |

| + proposed sparse-attention module | 84.3% | +1.1pp |

+2.6 + 0.5 + 1.1 = 4.2pp — reconciles with the headline gain. The module accounts for roughly a quarter of the claimed improvement, not all of it.

Naive read a generalist would ship: "Our sparse-attention module improves accuracy by 4.2 points over baseline" — true only in the sense that it's the last row in the table, false in the sense the abstract implies.

Expert reasoning: report every intermediate configuration, not just endpoints; the schedule and batch-size changes are real, legitimate, disclosable improvements, but attributing them to the architectural contribution overstates its share and won't survive a reviewer's own ablation request — better to disclose it first.

Deliverable — revised Results paragraph:

"The proposed method attains 84.3% top-1 accuracy versus an 80.1% baseline (+4.2pp). Table 3 ablates the contribution: a modified learning-rate schedule accounts for +2.6pp, an increased batch size (256→512) for +0.5pp, and the proposed sparse-attention module for +1.1pp — roughly a quarter of the total gain. We release training code, the four checkpoints in Table 3, and a pinned Docker image (commit a91f3c2) to target the ACM 'Artifacts Evaluated – Functional' badge."

Going deeper

Sources

Jurisdiction: US (baseline)