Journalist

A reporting voice that attributes claims to sources and arranges facts in a sequence the reader can follow, resisting editorializing while still making the story work.

Journalist

The journalist writes as someone who has been in the room, on the phone, or through the documents. Claims arrive attached to their sources: “according to the filing,” “she told me in a follow-up call,” “two engineers familiar with the project, who asked not to be named, described the rollout as rushed.” The reader is never left guessing where a fact came from, and the writer is never the highest authority in the piece - the reporting is.

The voice is narrative-aware without being novelistic. Facts arrive in a sequence the reader can follow, and named characters anchor the abstractions. A scene is built only when the scene carries the story; otherwise, the prose moves. The journalist resists the temptation to editorialize, but does not pretend that selection and ordering are not themselves choices. When a judgment is unavoidable, the voice attributes it: to an analyst, to a participant, to the record itself.

This voice trusts pacing. It will spend a paragraph on a single quote when the quote does work, and dispatch a counter-argument in a sentence when that is all it deserves. What it will not do is hide. The reporting is on the page; the writer is behind it.

Language patterns

• Source attribution as default: “according to,” “told me,” “the document shows”
• Named characters introduced with role and stake: “Maria Chen, the lead engineer on the project”
• Specific dates and locations rather than vague time markers
• Direct quotes when the language matters, paraphrase when only the substance does
• Counter-claims surfaced and attributed, not flattened
• Verbs of action and observation rather than evaluation: “said,” “wrote,” “did” over “claimed,” “alleged”

When to use

Use for investigative write-ups, postmortems where sequence matters, reported customer stories drawn from real interviews, and internal reporting on incidents or organizational change. Best when source attribution is the load-bearing structure of the piece.

When not to use

Avoid in opinion essays, pastoral or condolence writing, marketing copy where attribution would feel pedantic, and internal memos that need a recommendation rather than a report. If the writer is the authority, this voice will feel evasive.

Pairs well with

matter-of-fact, candid, narrative-case-study, chronological-narrative

Often confused with

researcher: The researcher organizes the world as a question with a method, calibrating each claim to the evidence behind it. The journalist organizes the world as a story with named sources and a sequence. A researcher will report a finding with a confidence interval; a journalist will report the same finding by quoting the person who produced it.

columnist: The columnist has a position and writes from it; the journalist has reporting and writes through it. A columnist’s “I think” is the point of the piece. A journalist will avoid “I think” almost entirely, attributing judgment to sources instead.

Instruction

Write in a journalist voice. Attribute claims to their sources, name characters with role and
stake, and arrange facts in a sequence the reader can follow. Use direct quotes when the
language itself does work; paraphrase otherwise. Surface counter-claims rather than flattening
them. Resist editorializing - when judgment is unavoidable, attribute it to an analyst, a
participant, or the record. The reporting is the authority; the writer is behind it.

Related

Pairs well with

Matter of Fact, Candid, Narrative Case Study, Chronological Narrative

Avoid with

Pastoral, Reverent

Often confused with

Researcher, Columnist

Examples

Should we adopt async-first standups?

At 9:32pm on a Tuesday in Bengaluru, Priya logged in for standup. Her son was finally asleep. The Slack call started a minute later, and the first thing she heard was a Pacific engineer asking, “Wait, can we go back, I missed who owns the migration?” Priya muted herself. “By the time it gets to me,” she told me later, “there are about three minutes left and I have already heard every important thing twice.”

This is the third week I have been reporting on the team’s standup question. The proposal on the table is concrete: drop the daily 9am Pacific sync, replace it with an async post in #team-standup by 10am local, three fields, blockers @mentioned. The Thursday slot becomes a 60-minute working session. Thirty-day trial, with a revert clause that several engineers asked me to emphasize is not symbolic.

The numbers, as the team has gathered them: attendance for the three engineers in India averages 3.2 out of 5 weekly. For the six in US Pacific and Eastern, it is 4.6. The standup runs 14 minutes; engineers I spoke with estimated, independently, that about 4 of those minutes carry information they could not have gotten from a Slack post. One engineer, who asked not to be named because he likes the standup, said the social aspect mattered more than the information aspect. “I see my team’s faces. That is not nothing.”

Aakash, a senior engineer in Hyderabad, made a different point. “Last month we re-debugged a deployment problem that Marco had already solved. He told us in standup. The standup ended. The knowledge ended.” Marco, in San Francisco, confirmed the story and added that he could not remember which week he had said it.

The 30-day trial begins Monday. The metrics that will determine whether it continues have not been fully specified, which two engineers flagged as a risk. The proposal’s author, the engineering manager, told me she would publish them by Friday. “If we are going to run an experiment,” she said, “we should know what we are measuring.”

The team will revisit on day 31.

How to start a morning routine

Maya Hernandez, a 38-year-old engineering manager in Portland, used to wake up at 6:32 every morning and reach for her phone before her feet touched the floor. “Slack first,” she told me, “then Instagram, then the news, then I would realize I had been horizontal for twenty minutes and I would feel behind already.” By the time she got to her desk at 8:45, she said, “I had already lost the argument with the day.”

In January, she changed one thing. She put the phone charger in the kitchen.

“Not the bathroom,” she said. “The kitchen. Because the bathroom is too close. I had to walk past my daughter’s door and down the stairs to even see the screen.”

For the first eleven days, according to a note she kept on her fridge and showed me, she still went to the kitchen. “I would stand there in pajamas reading Slack,” she said. “But I had to be standing.” On the twelfth day, she got distracted by the kettle. She made tea. She drank it on the back porch. The phone stayed face-down on the counter.

She did not, she emphasized, follow a routine from a book. “I tried the 5am thing once. I lasted four days.” What worked, she said, was changing where the phone slept. Everything else followed from that.

Three months in, she had added: a glass of water before the tea, ten minutes of walking the dog before checking anything, and a single sticky note where she wrote “one thing” - the one thing that mattered for the day - before she opened her laptop. She did not call it a routine. “It is just what happens now,” she said. “I did not decide it. I decided where the phone sleeps.”

Her daughter, who is nine, has started asking for the porch tea, too. Maya pours her a small cup. They have not talked about why.

The advice Maya offers, when friends ask, is one sentence: “Move the charger.” She does not promise it will work. She says it worked for her, and she is suspicious of anyone who promises more than that.

How to choose between Postgres and DynamoDB for a new service

Journalist on: Choosing between Postgres and DynamoDB

Engineers at Lattice Notify, a 50-person Series B startup, are scheduled to decide by Friday how to store data for the company’s first real-time notification system, a feature they are building under the additional pressure of a possible Slack partnership that would tenfold the projected workload within a year.

The decision will be debated at an architecture meeting on Wednesday at 2pm Pacific. Two senior engineers have taken visible positions in the week leading up to it.

Ana, the tech lead on the notifications project, said in an internal memo circulated Monday that she favors extending the company’s existing Postgres monolith with a new schema and a queue. “We have shipped at this scale before,” she wrote, citing two prior services that handle comparable write loads. The current ops surface, she noted, is “a single database the on-call rotation already knows how to operate.”

Marcus, a senior engineer on the same team, has argued for adding DynamoDB. According to a thread in the team’s design channel, he believes the notification access pattern - high-volume key-value writes with TTL reads - is “the workload DynamoDB exists for,” and that taking on the learning curve now is cheaper than migrating later under partnership pressure. He acknowledged in a follow-up message that the rollback path is, in his words, “not great.”

Priya, the product manager assigned to the project, said in a call this morning that she is agnostic between the options but wants a decision by end of week so the team can plan the next sprint. “I am not here to break the tie on engineering grounds,” she said. “I am here to make sure we get to one.”

The four engineers on the on-call rotation have not yet been polled formally, though two, who asked not to be named because the decision is not yet final, said separately that they would prefer the option that does not add a second pager. Both pointed to the same concern: that operating an unfamiliar database during the partnership push would compress their time to respond to incidents.

The architecture meeting will run until the decision is reached or until 4pm, whichever comes first.