The Long Run — Content Strategy

Publishing Cadence

Baseline:

1 long-form article every 10–14 days
2–3 LinkedIn posts per article, spread over time
Occasional short “bridge” pieces on LinkedIn only

This gives you:

Space to think
Room for ideas to land
Sustainability

You are not trying to “win the feed”.

Article Form

Target length: 1,500–2,000 words per article.

These are essays, not blog posts. Each article should:

Take time to develop ideas fully, not just state them
Explore multiple angles of the central theme
Use concrete examples and scenarios to ground abstract points
Allow space for reflection: sentences that let ideas breathe
Build through the piece, with later sections deepening earlier observations

Pacing: The writing should feel unhurried. Paragraphs can be substantial. Ideas can be revisited and examined from different angles. The reader should feel they’re thinking alongside the author, not being briefed.

Avoid: Listicle energy, rushed conclusions, compressing ideas into bullet points when prose would serve better, lots of short paragraphs. Paragraphs should be substantial; typically 4–8 sentences developing a single idea fully before moving on.

See articles 001 and 002 as reference for tone and length.

Writing Style Guidelines

Essay Structure (Not Listicle)

Avoid blog post patterns:

No bold lead sentences at the start of paragraphs (makes it feel like a listicle)
No bullet points where prose would work better
No visual structure cues (formatting should support reading flow, not scan-ability)

Essay flow:

Ideas develop within paragraphs, not across heading breaks
Transitional tissue between sections matters: show how ideas connect
Vary language when themes recur (avoid repeating exact phrases)
Let paragraphs do the work of organization, not formatting

Punctuation

Use:

Commas for natural pauses and list separation
Semicolons to connect related independent clauses
Colons to introduce examples or explanations

Avoid:

Em dashes (—) - use commas, semicolons, or colons instead
Excessive exclamation points
Ellipses (…) except in quoted material

Observational Tone (Phase A)

What works:

“We’re noticing…” / “We’re observing…”
“This is happening whether we think it should or not”
“Whether that’s good… those are open questions”

What doesn’t work:

“We’re finally free…” (too celebratory/resolved)
“We need to…” (prescriptive, Phase B/C territory)
Implying the shift is complete or unambiguously positive

Stay with the tension:

Acknowledge uncertainty explicitly
Signal that implications are still emerging
Resist resolving contradictions prematurely
The observation is the value, not the solution

Grounding Abstractions

Technical details illuminate:

Use specifics that make the shift visible (infrared heating, not just “sauna”)
Explain why details matter (“This is part of what makes it possible”)
Let technical precision serve narrative, not interrupt it

Match examples to role:

Architect: research, evaluation, supplier comparison, stakeholder engagement
Developer: refactoring, testing, implementation
Don’t mismatch role and work type

Use realistic timings:

AI research: 20-30 minutes (not hours)
Documentation: 30-45 minutes
Avoid inflating time to make continuity point; the speed is part of the shift

Multiple concrete contexts:

Show range (sauna, tube, between meetings, desk)
Demonstrates pattern, not one-off
Each context should add something, not just repeat

Article Development Process

Section-by-section iteration:

Get approval on one section before drafting the next
Allows course correction without large rewrites
Builds momentum through progressive completion

File organization:

Separate planning/outline from article content from the start
article-planning.md for meta content, notes, development plan
article.md for clean article content only
Prevents mixing outline with finished prose

Watch for duplication:

Old outline sections can persist alongside rewrites
Final pass specifically for continuity and exact phrase repetition
Delete superseded drafts when sections are rewritten

Final review checklist:

Continuity: do sections flow or jump?
Duplication: any exact phrases repeated?
Tone: observational throughout, or does it slip into prescription?
Structure: essay flow or listicle patterns?
Links: are there natural references to earlier articles that should be linked? (use relative links like /articles/002-work-continues-without-you)

Structural Arc

Phase A — Noticing the shift (Articles 1–5)

Name what’s changing without proposing solutions.

Phase B — Reframing the work (Articles 6–11)

Explore how roles, tools, and attention patterns evolve.

Phase C — Implications & tensions (Articles 12–16)

Examine what this breaks, complicates, or challenges.

You don’t need to announce these phases — they’re just for you.

Article Workflow

Articles live in two places:

Location	Purpose
`docs/articles/XXX/`	Planning & drafting workspace
`src/content/articles/XXX.md`	Astro content (what gets built)

Planning structure (`docs/articles/XXX/`)

Each article folder contains:

article.md — Outline, notes, draft content
checklist.md — Publication status and schedule
social.md — LinkedIn posts and social content

Publishing structure (`src/content/articles/XXX.md`)

When ready to stage an article:

Create src/content/articles/XXX-slug.md with frontmatter
Set status: draft initially
Copy content from docs/articles/XXX/article.md
Change to status: published when live

Required frontmatter fields:

title and subtitle — used in article header and meta tags
description — 2–3 sentences shown on the homepage listing. Write it in the same observational voice as the article: concrete and specific, not a generic summary. See docs/editorial.md for full guidance.

Always keep the next article staged as a draft. The series navigation shows “Part N coming [date]” by looking for draft articles. If the next article doesn’t exist in src/content/articles/, the “coming soon” link won’t appear.

Example: When working on article 002, ensure article 003 exists as a draft placeholder.

Linking to earlier articles

Add links to earlier articles when natural thematic connections exist. This helps readers follow the thread of ideas through the series.

When to link:

When mentioning a concept introduced in an earlier article
When building on or extending ideas from earlier work
When referencing patterns or examples from earlier articles

How to link:

Use relative links: /articles/002-work-continues-without-you
Link inline naturally within a sentence, not in separate “see also” blocks
Link the first mention of a concept, not every mention

Examples from the series:

Article 009 → Article 002: “the record of what happened while you were away”
Article 009 → Article 005: “Async work depends on continuity”
Article 006 → Article 004: “more intervention and refinement”
Article 007 → Article 006: “Reviewing code you didn’t write”

Check during final review: Are there natural references to earlier articles that should be linked?

Article Roadmap

Phase A: Noticing (Articles 1–5)

#	Title	Key Message
1	When does the desktop, or IDE, stop being the centre of development?	The IDE is still central, but not always most important. Work increasingly continues while we’re away.
2	What happens when work continues while you’re not there	CI, agents, pipelines change the rhythm of work. Progress is no longer tied to presence.
3	Development used to be synchronous	IDE-centric work assumed tight feedback loops. Async breaks that assumption in subtle ways.
4	The IDE as an intervention surface	The IDE shifts from “where work happens” to “where decisions are corrected and finalised”.
5	Why ‘faster feedback’ stopped being the whole story	Speed matters less than continuity. Long-running work values persistence over immediacy.

Phase B: Reframing (Articles 6–11)

#	Title	Key Message
6	From keystrokes to supervision	The developer’s role becomes more supervisory. This is not a loss of agency.
7	How to allocate attention at scale	Tools scale faster than human attention. The challenge is deciding where to look.
8	Why chat is not the replacement for the IDE	Chat is coordination, not creation. The mistake is treating it as a new editor.
9	Git as memory, not just version control	Git becomes the long-term record of intent. Commits as checkpoints in async work.
10	What long-running agents change, and what they don’t	Persistence matters more than intelligence. Agents extend work across time, not capability.
11	Working from a phone is a clue, not a goal	Mobile work reveals what must stay central. If it works on a phone, it’s probably supervisory.

Phase C: Tensions & Implications (Articles 12–17)

#	Title	Key Message
12	The goalkeeper’s dilemma: when AI writes 95% of your code, can you still execute the critical 5%?	Automation makes you rusty at the work you stop doing. The 5% AI can’t handle becomes the hardest 5% you need to execute.
13	When productivity becomes invisible	Less typing doesn’t mean less work. Output becomes harder to attribute.
14	The quiet cost of always-on systems	Long-running work never really “stops”. Boundaries blur unless designed explicitly.
15	Why experience matters more in async development	Judgement becomes more important than speed. Senior intuition compounds in async systems.
16	What breaks when you remove the editor from the centre	Debugging, learning, onboarding all change. Some things get harder, not easier.
17	The centre doesn’t disappear; it moves	The “centre” is contextual and temporary. The future is fluid, not replacement-driven.

Publication Types

Regular Series Articles (001-016)

Follow standard channel strategy:

Publish on thelongrun.work first (canonical home)
Cross-post to Medium 24-48h later
Distribute via LinkedIn

Synthesis/Distribution Articles

Special pieces designed for external reach:

Purpose: Standalone synthesis for audiences who haven’t read the series
Distribution: Pitch to external publications (LeadDev, InfoQ, The New Stack, Hacker News)
Canonical home: Can be hosted on thelongrun.work OR on the external publication (depending on their policy)
Timing: Publish after the series phase completes (e.g., Phase A synthesis after article 005)
Links back: Always includes “Start here: [article 001]” to drive traffic to series

Examples:

Phase A synthesis (mid-March 2026): Targets The New Stack, Dev.to → article.md
Phase B synthesis (TBD): The New Stack, Dev.to
Phase C synthesis (TBD): The New Stack, Dev.to

Note: InfoQ is not a fit for our synthesis articles. They focus on deep technical implementation content from practitioners in innovator/early adopter stages. Our observational, reflective essay style doesn’t match their technical deep-dive requirements.

External Publication Requirements

When preparing synthesis articles for external publications, prepare these materials in advance (store in article-planning.md):

The New Stack Requirements (Primary Target):

Email pitch to contributors@thenewstack.io
Focus: Practical solutions to real-world technical challenges
Combine technical expertise with personal experience
Original, human-written (no AI-generated content)
800+ words (flexible)
Images: 1,800px wide or 350px tall
Review time: 2-3 weeks

Dev.to (backup option):

No pitch required - direct publish
Set canonical URL if published elsewhere first
Tags: choose 4-5 relevant tags
Can cross-post with other platforms

Channel Strategy

Channel	Role
TheLongRun.work	Canonical home for series articles
External publications	Distribution for synthesis articles
Medium	Discovery + reach (regular articles)
LinkedIn	Conversation + distribution
Newsletter (later)	Retention

Don’t try to make any one channel do all jobs.

Medium Strategy

Medium serves as the discovery engine: reaching readers who wouldn’t find the site directly.

Cross-posting approach

Publish on thelongrun.work first (canonical source)
Import to Medium using “Import a story” feature
Medium will automatically set the canonical URL to your original
Wait 24-48 hours before cross-posting to let the original index

Tag Strategy

Medium allows 5 tags per story. Choose strategically:

Primary tags (high reach, always include 2-3):

Tag	Followers	Notes
Technology	15.5M	Broadest reach
Artificial Intelligence	7.6M	Hot topic in 2026
Productivity	7.3M	Aligns with our themes
Software Engineering	3.6M	Best discovery ratio (37.5)
Programming	12M	Strong ratio (32.7)

Secondary tags (rotate based on article topic):

Tag	When to use
Future Of Work	Articles about changing work patterns
Software Development	Technical workflow pieces
Developer Experience	IDE/tooling focused
Remote Work	Async/distributed themes
Leadership	Supervisory role pieces

Recommended combinations by article type:

“Noticing the shift” articles: Technology, Future Of Work, Software Engineering, Productivity, Artificial Intelligence
Technical workflow pieces: Programming, Software Development, Developer Experience, Productivity, Technology
Role/attention pieces: Future Of Work, Leadership, Productivity, Technology, Artificial Intelligence

Publication strategy

Use your own Medium publication (“The Long Run”) as the home for all articles.

Why this is better than submitting to other publications:

You own the audience: followers subscribe to you
Brand consistency: “The Long Run” exists as a coherent presence
No gatekeepers: publish when ready, no approval delays
Tags still drive discovery: Medium’s algorithm works regardless of publication

Note: An article can only belong to one publication on Medium. Don’t waste time submitting to external publications; build your own audience instead.

Alternative publications (only if you don’t have your own):

Publication	Followers	Fit
ITNEXT	~77K	Software engineers
Better Programming	Large	Developer-focused
The Startup	Large	Broader tech audience

Medium-specific formatting

Add a subtitle (Medium displays this prominently)
First paragraph is crucial: it shows in previews
Use the article’s subtitle from frontmatter as the Medium subtitle
Images: Add a header image if you have one (quote cards work well)

Timing

Cross-post 1-2 days after original publication
Best engagement: Tuesday-Thursday, morning (US time zones)
Avoid weekends and Mondays

Cross-Post Platform Strategy

Platform	Timing	Purpose
Medium	+2 days after publish	Primary syndication, canonical to site
Dev.to	~2 weeks after publish	Community reach, alternating articles
Hacker Noon	~2 weeks after publish	Broader tech audience, alternating articles

Reddit Engagement Strategy

Target: r/ExperiencedDevs (primary), r/programming (occasional)

Tactics:

Cadence: Every 2-4 days, naturally varied (not predictable)
Theme rotation: Never repeat same article angle consecutively
Search terms: Find existing discussions (see table below)
Reply follow-up: Check back 4-6 hours, respond to 1-2 replies
No article links: Profile links to site; comments share insight only
Value-first: Share genuine insight, not promotion

Search Terms by Theme:

Theme	Search Terms
002: Work continues	`AI pair programming`, `copilot workflow`, `agentic coding`
003: Synchronous	`AI coding review`, `reviewing AI code`, `async development`
004: Intervention	`AI code review`, `developer experience AI`, `IDE AI`
005: Continuity	`developer productivity AI`, `measuring productivity`
013: Always-on costs	`always on work`, `work-life boundaries AI`, `burnout`
014: Experience	`senior developer AI`, `junior developer AI`, `experience value`

Hacker News Engagement Strategy

Approach: Thoughtful participation, not promotion

Tactics:

Timing: Early morning US time (6-8am PT) for best visibility
Engagement type: Comment on relevant threads, share insights
Submission timing: If submitting synthesis article, ask someone else to submit
Frequency: 1-2 times per week, varied days
Focus: General presence building, not article promotion

LinkedIn Posting Pattern

Post multiple times per article, but never the same post twice.

Making posts memorable

Posts should show, not explain. Lead with something concrete, surprising, or viscerally relatable; not a summary of what you wrote.

The sauna test: Could this post be a photo with a caption? Every post needs a visual, so think in images first, words second.

Hooks that work:

Type	Example
The absurd proof	Directing AI from an iPad in a sauna
The scale shock	”2,847 lines changed while I was at lunch”
The role flip	”I open my IDE to approve, not create”
The counterintuitive	”Faster feedback stopped mattering”
The overnight flex	”While I slept, my agent…”
The before/after	How the same moment looks different now

Visual ideas:

Real photos of workflow moments (the more unexpected the setting, the better)
Screenshots (PRs, git logs, notifications, diffs)
Before/after comparisons
Your actual screen, your actual coffee, your actual context

Per-article cadence

1. Publish-day post

Lead with a hook: the surprising moment, not the thesis
Include a visual that proves the point
Link to article
End with a question or invitation

2. Insight post (7–10 days later)

One strong idea, stated plainly
Visual that reinforces the insight
No link needed: let it stand alone

3. Reflection post (3–4 weeks later)

“Since writing this, I’ve noticed…”
Personal observation that extends the original
Visual showing the continued reality

Why this works

Reaches different audiences
Avoids spammy repetition
Lets ideas mature
Visuals stop the scroll

Editorial Rule

If an article feels “finished”, it’s probably too late to publish.

These are thinking pieces, not whitepapers.

Techcle Wiki

Explorer

Content Strategy