How to Write Technical Articles That Actually Resonate

TL;DR

Writing tech articles that work (read, shared, cited) isn't talent—it's process. Structure: unique angle + numbered outline + active voice + brutal editing. Execution: cut 40 % of your draft, source every number, read aloud. Result: articles that attract serious readers (other devs, tech leads, founders). On my portfolio, the 5 articles following this process generate 60 % of traffic and 80 % of citations.

1. Before Writing: The Bad Angle Problem

Mistake #1: You want to write "about a topic" (example: "Flutter vs React Native"). That's vague, too broad, impossible to handle honestly.

Mistake #2: You write to show off knowledge. Result: 5k words listing features, zero opinion, zero usefulness. Reader: "Cool story, not for me."

Mistake #3: You write what exists already. "Top 10 frameworks" #42, "Why you should learn Rust." Generic, forgettable, buried in 10k similar results.

Solution: Define a unique angle before writing the first sentence.

An angle is: for WHO, facing WHAT EXACT PROBLEM, what's the answer nobody else has clearly posed?

Bad angle: "Flutter vs React Native."
Good angle: "Flutter vs React Native for an expert mobile dev who wants to launch a web + mobile SaaS, in the Caribbean, solo."

A good angle forces you to take a position. Riskier (you'll upset people), but laser-focused. And people share what's sharp.

2. Outline Before Prose

Before writing body copy, build a numbered outline. It's your dependency graph: what idea requires what other idea first?

Rule: no section should reference a concept introduced below it.

Bad outline:

Performance benchmarks
Definition of "performance"
Pitfalls in interpretation

Good outline:

Define "performance"
Common pitfalls
Real benchmarks and why they contradict

Once your outline flows, show it to someone. Not for approval—to catch logical gaps. If you have to explain yourself, the outline has a hole.

3. Source, Don't Improvise

Every numerical or technical claim needs a source. Not for legal cover, but because your readers are sharp. They'll verify. If there's an error, you lose credibility.

Process:

Claim: "React Native dominates with 6,400 offers vs 1,070 Flutter (USA 2026)."
Source: LinkedIn Recruiter, filtered search, screenshot May 2026.
Note: "Ratio varies by platform (Indeed vs LinkedIn, Glassdoor). Order of magnitude: 2 to 8× more RN offers."
In article: "React Native: ~6,400 offers vs Flutter ~1,070 (LinkedIn Recruiter, May 2026). Ratio varies by source but heavily favors RN."

You source, you note the dependency, you keep trust.

Pitfalls:

Widely-cited numbers (that everyone quotes but nobody verified): trace the original source.
Your opinion presented as fact: label it "I believe" or cut it. Example: "I think Flutter has better long-term prospects" ≠ "Flutter is growing faster."
Outdated sources (3+ years old in a fast-moving field): flag the date and say plainly it's stale.

4. Voice & Tone: Mechanical Rules

Forget "find your unique voice." Start with simple, applied rules.

Active Voice

Bad: "A framework is chosen by devs based on available jobs."
Good: "Devs choose their framework based on available jobs."

Mechanic test: if "by monkeys" sticks to your sentence and it still makes sense, it's passive. Rewrite.

Direct Address

Bad: "The user must install the CLI."
Good: "You install the CLI with npm install -g."

Who are you talking to? If it's generic ("developers"), it's weak. Say who. "You Flutter dev," "You founder with a JS team," "You mobile architect."

Present Tense & Imperative

Bad: "One should consider installing the dependencies."
Good: "Install the dependencies."

No "should," no "one." State the fact. If it's conditional, state the condition.

Short Sentences

Bad: "Given the multitude of cross-platform frameworks available in today's market, each offering distinct developer experiences and performance profiles dependent on context, selection becomes complex."

Good: "Choosing a framework depends on three things: required performance, your team, and the job market. No framework wins everywhere."

Count words: cut sentences > 20 words. Simple rule, almost magical for clarity.

5. Brutal Editing: Cut 40 %

Your draft is too long. All drafts are.

Pass through, word by word:

Adjectives that change nothing: "very," "just," "really," "quite." Delete them. "It's a very flexible language" → "It's a flexible language."
Vague quantifiers: "many," "often," "most," "rarely." Replace with a number. "Many devs choose RN" → "60 % of new mobile projects use RN."
Filler that adds no info: paragraphs rephrasing what you just said. Delete entirely.
Transitions that recap: "We've seen that X. Now let's move to Y." → Jump straight to Y. Transition is implicit.

Test: Read aloud. Every time you think "okay I get it, next," cut that passage.

Expected result: lose 30-40 % of words, gain clarity. Less is more.

6. Structure & Formatting for Readability

Headings

Sentence case (not "Flutter Best Practices," but "When to choose Flutter").
Descriptive (not "Verdict," but "Verdict: React Native for web + mobile SaaS").
No rhetorical questions ("Why Flutter?" → "Why choose Flutter").

Lists

Introduce with a colon.
Unordered (-) for independent items, numbered (1, 2, 3) for sequences.
Format: **Term** : description.

Example:

Flutter advantages:
- **Hot reload** : edit code and see changes in < 1 sec.
- **Single codebase** : one base for mobile, web, desktop.

Tables

Great for comparison. Weak for enumeration (use a list).

Bad table: | Framework | Thing | |---|---| | Flutter | Impeller | | RN | Hermes |

Good table (actual comparison): | Metric | Flutter | React Native | |---|---|---| | Animation performance | 9.5/10 | 8/10 | | Binary size | 15-25 MB | 8-15 MB |

7. Deep Edit: The Real Work

Writing is 20 %. Editing is 80 %.

Pass 1: Structure

Read your draft. Does the outline hold? Dependencies intact? Are there jumps where you think "why is he saying this?"

If yes: reorganize or add context. Not perfect, just logical.

Pass 2: Voice

Read aloud (really). Every time you stumble or it sounds "corporate," rewrite. True test: can a non-tech person grasp the first paragraph without jargon?

Pass 3: Facts

Fact by fact, number by number. Source? Current? Wrong source? Fix or remove.

Pass 4: Cut

This is where you delete 40 %. Ruthlessly eliminate the flabby.

Pass 5: Polish

Typos, formatting, links, citations. Mechanical but critical. One typo doesn't break credibility. Five do.

8. Light SEO

No SEO stuffing. A few obvious rules:

Title: should contain a useful keyword ("How to write," "Flutter vs React Native").
Description: 160 chars, summarizes and includes the keyword if natural.
Headings: your H2s and H3s should be scannable. Someone reading titles only should understand the article.
Links: link to related articles when natural, not for link-building.

Honestly: if you write well and source properly, Google loves you. No tricks needed.

9. Publishing & Promotion

Once the article is ready (edited, sourced, proofread), publish. But the real work starts after.

Day 0: Launch

Post excerpt on LinkedIn (100-200 words, link to article).
Cross-post to dev.to (if applicable).
Email 3-5 people who'd care.

Week 1-2

Get feedback (comments, shares, "this helped").
Found an error? Fix and publish an update.
Reply to every comment (shows you're reading).

Month 1-3

Articles that hit: retweet, reference in other content.
Articles that flopped: why? Bad angle? Bad timing? Under-sourced?

10. When to Write

Not every topic deserves an article. Signs you should:

You have a contrasting opinion ("Everyone says X, but it's wrong because Y").
You've spent 40+ hours learning, hands-on. There's something to share.
It's actionable for the reader. Not abstract, not philosophical—something people do.
You've heard the question 5+ times from different people.

Hit 3/4? Write.

Otherwise, it's a LinkedIn thread (2 min), not an article (2 days).

Real Results from My Portfolio

Since 2024, 20 articles published, ~40k total views.

| Article | Views | Shares | Citations | |---------|------|--------|-----------| | Flutter vs React Native 2026 | 8,200 | 140 | 23 | | Open source impact in startups | 3,100 | 45 | 8 | | Install Hadoop on MacBook M1/M2 | 4,500 | 62 | 15 | | (Other 17 articles) | 24k | 350+ | 40+ |

The 5 that followed this process exactly generate 60 % of traffic. The rest? Solid but forgettable.

TL;DR

A good article isn't talent. It's a process.

Unique, narrow angle.
Outline that flows.
Source every fact.
Active voice, short sentences.
Edit ruthlessly.
Read aloud.
Publish and engage.

It's tedious. So most people write fast (and get forgotten fast). If you spend 2-3 days on an article, you'll write something people remember.

Go write something sharp.

TL;DR

1. Before Writing: The Bad Angle Problem

Mistake #1: You want to write "about a topic" (example: "Flutter vs React Native"). That's vague, too broad, impossible to handle honestly.

Mistake #2: You write to show off knowledge. Result: 5k words listing features, zero opinion, zero usefulness. Reader: "Cool story, not for me."

Mistake #3: You write what exists already. "Top 10 frameworks" #42, "Why you should learn Rust." Generic, forgettable, buried in 10k similar results.

Solution: Define a unique angle before writing the first sentence.

An angle is: for WHO, facing WHAT EXACT PROBLEM, what's the answer nobody else has clearly posed?

Bad angle: "Flutter vs React Native."
Good angle: "Flutter vs React Native for an expert mobile dev who wants to launch a web + mobile SaaS, in the Caribbean, solo."

A good angle forces you to take a position. Riskier (you'll upset people), but laser-focused. And people share what's sharp.

2. Outline Before Prose

Before writing body copy, build a numbered outline. It's your dependency graph: what idea requires what other idea first?

Rule: no section should reference a concept introduced below it.

Bad outline:

Performance benchmarks
Definition of "performance"
Pitfalls in interpretation

Good outline:

Define "performance"
Common pitfalls
Real benchmarks and why they contradict

Once your outline flows, show it to someone. Not for approval—to catch logical gaps. If you have to explain yourself, the outline has a hole.

3. Source, Don't Improvise

Every numerical or technical claim needs a source. Not for legal cover, but because your readers are sharp. They'll verify. If there's an error, you lose credibility.

Process:

Claim: "React Native dominates with 6,400 offers vs 1,070 Flutter (USA 2026)."
Source: LinkedIn Recruiter, filtered search, screenshot May 2026.
Note: "Ratio varies by platform (Indeed vs LinkedIn, Glassdoor). Order of magnitude: 2 to 8× more RN offers."
In article: "React Native: ~6,400 offers vs Flutter ~1,070 (LinkedIn Recruiter, May 2026). Ratio varies by source but heavily favors RN."

You source, you note the dependency, you keep trust.

Pitfalls:

Widely-cited numbers (that everyone quotes but nobody verified): trace the original source.
Your opinion presented as fact: label it "I believe" or cut it. Example: "I think Flutter has better long-term prospects" ≠ "Flutter is growing faster."
Outdated sources (3+ years old in a fast-moving field): flag the date and say plainly it's stale.

4. Voice & Tone: Mechanical Rules

Forget "find your unique voice." Start with simple, applied rules.

Active Voice

Bad: "A framework is chosen by devs based on available jobs."
Good: "Devs choose their framework based on available jobs."

Mechanic test: if "by monkeys" sticks to your sentence and it still makes sense, it's passive. Rewrite.

Direct Address

Bad: "The user must install the CLI."
Good: "You install the CLI with npm install -g."

Who are you talking to? If it's generic ("developers"), it's weak. Say who. "You Flutter dev," "You founder with a JS team," "You mobile architect."

Present Tense & Imperative

Bad: "One should consider installing the dependencies."
Good: "Install the dependencies."

No "should," no "one." State the fact. If it's conditional, state the condition.

Short Sentences

Good: "Choosing a framework depends on three things: required performance, your team, and the job market. No framework wins everywhere."

Count words: cut sentences > 20 words. Simple rule, almost magical for clarity.

5. Brutal Editing: Cut 40 %

Your draft is too long. All drafts are.

Pass through, word by word:

Adjectives that change nothing: "very," "just," "really," "quite." Delete them. "It's a very flexible language" → "It's a flexible language."
Vague quantifiers: "many," "often," "most," "rarely." Replace with a number. "Many devs choose RN" → "60 % of new mobile projects use RN."
Filler that adds no info: paragraphs rephrasing what you just said. Delete entirely.
Transitions that recap: "We've seen that X. Now let's move to Y." → Jump straight to Y. Transition is implicit.

Test: Read aloud. Every time you think "okay I get it, next," cut that passage.

Expected result: lose 30-40 % of words, gain clarity. Less is more.

6. Structure & Formatting for Readability

Headings

Sentence case (not "Flutter Best Practices," but "When to choose Flutter").
Descriptive (not "Verdict," but "Verdict: React Native for web + mobile SaaS").
No rhetorical questions ("Why Flutter?" → "Why choose Flutter").

Lists

Introduce with a colon.
Unordered (-) for independent items, numbered (1, 2, 3) for sequences.
Format: **Term** : description.

Example:

Flutter advantages:
- **Hot reload** : edit code and see changes in < 1 sec.
- **Single codebase** : one base for mobile, web, desktop.

Tables

Great for comparison. Weak for enumeration (use a list).

Bad table: | Framework | Thing | |---|---| | Flutter | Impeller | | RN | Hermes |

Good table (actual comparison): | Metric | Flutter | React Native | |---|---|---| | Animation performance | 9.5/10 | 8/10 | | Binary size | 15-25 MB | 8-15 MB |

7. Deep Edit: The Real Work

Writing is 20 %. Editing is 80 %.

Pass 1: Structure

Read your draft. Does the outline hold? Dependencies intact? Are there jumps where you think "why is he saying this?"

If yes: reorganize or add context. Not perfect, just logical.

Pass 2: Voice

Read aloud (really). Every time you stumble or it sounds "corporate," rewrite. True test: can a non-tech person grasp the first paragraph without jargon?

Pass 3: Facts

Fact by fact, number by number. Source? Current? Wrong source? Fix or remove.

Pass 4: Cut

This is where you delete 40 %. Ruthlessly eliminate the flabby.

Pass 5: Polish

Typos, formatting, links, citations. Mechanical but critical. One typo doesn't break credibility. Five do.

8. Light SEO

No SEO stuffing. A few obvious rules:

Title: should contain a useful keyword ("How to write," "Flutter vs React Native").
Description: 160 chars, summarizes and includes the keyword if natural.
Headings: your H2s and H3s should be scannable. Someone reading titles only should understand the article.
Links: link to related articles when natural, not for link-building.

Honestly: if you write well and source properly, Google loves you. No tricks needed.

9. Publishing & Promotion

Once the article is ready (edited, sourced, proofread), publish. But the real work starts after.

Day 0: Launch

Post excerpt on LinkedIn (100-200 words, link to article).
Cross-post to dev.to (if applicable).
Email 3-5 people who'd care.

Week 1-2

Get feedback (comments, shares, "this helped").
Found an error? Fix and publish an update.
Reply to every comment (shows you're reading).

Month 1-3

Articles that hit: retweet, reference in other content.
Articles that flopped: why? Bad angle? Bad timing? Under-sourced?

10. When to Write

Not every topic deserves an article. Signs you should:

You have a contrasting opinion ("Everyone says X, but it's wrong because Y").
You've spent 40+ hours learning, hands-on. There's something to share.
It's actionable for the reader. Not abstract, not philosophical—something people do.
You've heard the question 5+ times from different people.

Hit 3/4? Write.

Otherwise, it's a LinkedIn thread (2 min), not an article (2 days).

Real Results from My Portfolio

Since 2024, 20 articles published, ~40k total views.

The 5 that followed this process exactly generate 60 % of traffic. The rest? Solid but forgettable.

TL;DR

A good article isn't talent. It's a process.

Unique, narrow angle.
Outline that flows.
Source every fact.
Active voice, short sentences.
Edit ruthlessly.
Read aloud.
Publish and engage.

It's tedious. So most people write fast (and get forgotten fast). If you spend 2-3 days on an article, you'll write something people remember.

Go write something sharp.

TL;DR

1. Before Writing: The Bad Angle Problem

2. Outline Before Prose

3. Source, Don't Improvise

4. Voice & Tone: Mechanical Rules

Active Voice

Direct Address

Present Tense & Imperative

Short Sentences

5. Brutal Editing: Cut 40 %

6. Structure & Formatting for Readability

Headings

Lists

Tables

7. Deep Edit: The Real Work

Pass 1: Structure

Pass 2: Voice

Pass 3: Facts

Pass 4: Cut

Pass 5: Polish

8. Light SEO

9. Publishing & Promotion

10. When to Write

Real Results from My Portfolio

TL;DR

La newsletter qui ne perd pas ton temps.

Une lettre par mois, sur ce que je construis et ce que j’apprends.

TL;DR

1. Before Writing: The Bad Angle Problem

2. Outline Before Prose

3. Source, Don't Improvise

4. Voice & Tone: Mechanical Rules

Active Voice

Direct Address

Present Tense & Imperative

Short Sentences

5. Brutal Editing: Cut 40 %

6. Structure & Formatting for Readability

Headings

Lists

Tables

7. Deep Edit: The Real Work

Pass 1: Structure

Pass 2: Voice

Pass 3: Facts

Pass 4: Cut

Pass 5: Polish

8. Light SEO

9. Publishing & Promotion

10. When to Write

Real Results from My Portfolio

TL;DR

La newsletter qui ne perd pas ton temps.