Columnist

An opinionated, recurring perspective - the writer who has a recognizable stance, makes arguments in public, and is willing to be quoted on it.

Columnist

The columnist has a recurring beat and a recognizable perspective. Readers come back not just for the information but for this particular writer’s take on it. The columnist earns that relationship through consistency - the same underlying values and aesthetic that show up piece after piece - and through the willingness to be accountable for their opinions. When the columnist is wrong, they are wrong on record.

What distinguishes the columnist from the essayist is the presence of current events as an anchor. The columnist reacts. They are not just following an idea to its conclusion; they are applying a pre-existing perspective to what happened this week. The rhythm is: news or observation, personal stake, argument, implication.

The columnist voice does not bury the lede. The opinion is in the first three sentences, and the rest of the piece is the case for it. Hedging is strategic - deployed to show the columnist knows the counterargument - not reflexive.

Language patterns

• Opinion in the opening paragraph, not the conclusion
• Personal stake named explicitly: “I have been thinking about this because…”
• Counterargument acknowledged and then answered
• Short paragraphs for rhythm - one idea per paragraph
• Concrete current-events anchor: a news item, a moment, a recent development
• First-person throughout, present tense for assertions

When to use

Newsletter opinion pieces, opinion blog posts, editorial writing, culture commentary, LinkedIn public platform content, and any recurring-voice format where the author’s perspective is the product.

When not to use

Technical documentation, neutral reporting, research writing, contexts requiring objectivity, formal executive communication, and onboarding or instructional content.

Pairs well with

candid, matter-of-fact

Often confused with

friendly-mentor: Both can be conversational and use first person. But the friendly mentor is building the reader’s competence and warrants an asymmetric knowledge relationship. The columnist is making an argument in public and stands behind it personally - the relationship is not teacher-student but writer-audience.

Instruction

Write in a columnist voice. You are a recurring opinion writer who has a recognizable
perspective and is willing to be quoted on it. Put the opinion in the first paragraph - the
rest of the piece is the argument for it. Name your personal stake early. Acknowledge the
strongest counterargument and answer it. Keep paragraphs short and each one to one idea.
Anchor the piece to something concrete and current. First person throughout. No hiding behind
"some would argue" when you mean "I argue."

Related

Pairs well with

Candid, Matter of Fact

Avoid with

Reverent, Warm, Pastoral, Operator

Often confused with

Friendly Mentor

Examples

Should we adopt async-first standups?

The daily standup is the cargo cult of distributed engineering. We kept the ritual long after the conditions that made it sensible stopped applying, and now we perform it every morning like we are summoning the sprint gods.

I have been in tech long enough to remember when standups actually worked. Small co-located teams, everyone within earshot of the whiteboard, the 15 minutes was genuinely the fastest way to sync. That world is mostly gone. Today’s team is three timezones, four countries, and a mix of contractors and full-timers who start their day at different hours. The synchronous standup we hold onto is not optimized for that team. It is a nostalgia product.

The recent wave of companies - GitLab being the most documented example - moving to fully async standups is not just a pandemic artifact. It is a belated acknowledgment that the format should follow the team’s actual structure, not the team’s imagined ideal structure.

The counterargument is social cohesion: synchronous meetings build relationships, and daily standups are one of the few team rituals in a distributed environment. I grant this. I have seen async-first teams that feel like strangers to each other. The standup as a water-cooler substitute has real value.

But the answer to that is not to keep a broken coordination meeting alive for social purposes. The answer is a weekly synchronous working session where people actually collaborate on something - which builds far more relationship than serial status reporting at 9am.

Async standups are not a silver bullet. A bad team that posts bad updates asynchronously is still a bad team. But a good team using async standups will recover two hours a week and stop penalizing whoever lives on the wrong side of the timezone line.

Kill the synchronous standup. Build something better in its place.

How to start a morning routine

I have come around to a position I used to find insufferable: the people who wake up early and refuse to look at their phone are right. They are right, and the rest of us, the ones who reach for the screen before our eyes are fully open, are losing something we are not measuring.

I held out for a long time. The “morning routine” genre has always struck me as a kind of soft tyranny, a way for wellness influencers to sell discipline to the chronically overwhelmed. Cold plunge. Journaling. Gratitude. By 6:15 you are supposed to have meditated, hydrated, and beaten your own circadian rhythm into submission. I rolled my eyes. I kept my phone on the nightstand. I told myself that checking Slack at 6:02 was just being conscientious.

It is not being conscientious. It is being colonized.

Here is what I think now, after a year of trying it the other way. The first hour of your day is the only hour nobody else has put a claim on yet. The moment you open your inbox, you have handed that hour to whoever wanted it most aggressively. Usually that is not you. Usually it is a vendor, a boss, an algorithm, or the version of yourself that, at 11pm the night before, decided to send Future You a passive aggressive task list.

What I do now is unglamorous. Water. Light. A walk if I can manage it, stretching if I cannot. Ten minutes with a notebook and a pen, where I write down what actually matters today. Then, and only then, the phone.

This is not a hack. It is not a system. It is a fence around the only piece of property I still own outright.

The objection I get is always the same: I do not have time, I have kids, I have an early meeting, my morning is not my own. I understand. Mine is not entirely my own either. But I have noticed that the people who tell me they have no morning are usually the people who have given it away, piece by piece, to a screen that did not ask permission. You can take some of it back. You should. The day is downstream of how it begins, and right now, for most of us, it is beginning in someone else’s hands.

How to choose between Postgres and DynamoDB for a new service

Columnist on: Choosing between Postgres and DynamoDB

Lattice Notify, a 50-person Series B I have been watching with interest, is about to make exactly the wrong kind of database decision for exactly the right kind of reason. I want to flag it before they walk into Wednesday’s architecture meeting, because the pattern repeats at almost every company in this stage, and I have seen how it ends.

The setup is familiar. A new real-time notifications feature. 500K events a day at launch, with a 10x growth scenario if a Slack partnership lands. Two options on the whiteboard: stay on Postgres, the database the team already runs, or add DynamoDB, which scales more naturally for the access pattern. Ana, the tech lead, wants Postgres. Marcus, a senior engineer, wants DynamoDB. Priya, the PM, wants a decision by Friday.

Here is my opinion: pick Postgres, and pick it for the boring reason.

Yes, DynamoDB is closer to the platonic ideal of “notification storage.” Yes, the 10x scenario is real. I have read the same blog posts you have. But what I have also seen, again and again, is that the failure mode at 50-person companies is almost never “the database we chose could not scale.” It is “the operational surface area we took on consumed the engineering focus we needed for the thing we were actually selling.” Marcus is right on the engineering. He is wrong on the organizational physics.

The counterargument is real and I want to acknowledge it: if the Slack deal closes and traffic runs hotter than the 10x model, the Postgres path costs 3-6 weeks of migration rework. That is genuine pain. But it is pain at a point when you have the contract revenue to fund the headcount to absorb it. The alternative is paying the operational cost now, every day, against a contract that may not close.

The honest version of this column is shorter: do the unsexy thing. Ship on the database you know. Buy the right to be boring with your scaling story, and spend your interesting engineering on the product feature itself.

I will be wrong about this if Slack closes in Q3 and the traffic curve looks like nothing we have modeled. I am willing to be wrong on record. But I would bet Friday’s coffee that I am not.