Get AI summaries of any video or article — Sign up free
Janine Chan - Seven habits of increasingly technical technical writers thumbnail

Janine Chan - Seven habits of increasingly technical technical writers

Write the Docs·
5 min read

Based on Write the Docs's video on YouTube. If you like this content, support the original creators by watching, liking and subscribing to their content.

TL;DR

Replace identity statements like “I am not technical” with time-bound skill statements such as “I can’t do this yet” to keep learning possible.

Briefing

Technical writers (and anyone moving from “good” to “great”) become more capable not by collecting a pile of courses or waiting for a confidence milestone, but by building a habit of learning how to learn. Janine Chan’s central claim is that “technical” isn’t a fixed identity or a single skill toggle; it’s what happens when people train themselves to pursue knowledge, ask better questions, and keep experimenting—especially when they feel behind.

Chan frames her own path as a counterexample to the usual career narrative. An English degree didn’t come with deep technical training, and her early work didn’t magically erase gaps. Yet she eventually landed a senior technical writing role at Data Dog after passing a code test, and the missing link wasn’t a secret credential—it was learning to teach herself. That “hot take” becomes the backbone of seven habits aimed at tech writers, instructional designers, developers, and “neat people” who want to level up.

The first habit targets identity traps. People often write “I am not technical,” turning a skill gap into a permanent self-description. Chan urges a different phrasing: “I can’t do this particular thing yet,” which keeps the problem specific and time-bound. That mindset shift—growth over fixed—matters because it prevents people from mentally boxing themselves into “non-technical” categories.

Next comes a practical emotional pivot: when overwhelm hits, redirect it into curiosity. Deadlines and unfamiliar features can trigger an overwhelm spiral that blocks progress. Curiosity, by contrast, turns uncertainty into a reason to investigate, collaborate, and ask questions. Chan recommends breaking large knowledge gaps into smaller ones (like separating pie into crust, goo, and baking steps) so questions become manageable.

As those gaps become specific, the third habit is learning to ask for help without guilt. Chan argues that requesting information makes someone a better colleague: it improves credibility, models human behavior, and helps teams understand where answers come from. She offers a structured Slack-question template—describe context, what’s already been considered, where the writer is stuck, what they hope to learn, why they’re asking that person, and an explicit acknowledgement of the other person’s time.

The fourth habit is low-stakes tinkering. Learning technical skills accelerates when people try things locally, with safe guardrails, and treat mistakes as data rather than shame. Chan illustrates this with a lesson from Benjamin Zander, who reframes errors as “fascinating” and actionable—decoupling shame from performance so learners keep going.

The remaining habits reinforce momentum: notice that admired people also struggle with impostor syndrome; avoid perfectionism that delays useful drafts; and be honest about whether the “learn-by-not-knowing” process is energizing or draining for you. If it’s draining, she says, it’s valid to choose easier work or different environments.

Chan closes by tying change to identity and responsibility—admitting that growth feels hard because it challenges what people assume they can do, but arguing that daily opportunities to become “smarter, kinder, more compassionate, more inclusive” are part of what it means to be alive.

Cornell Notes

Janine Chan argues that “technical” ability grows from a habit of learning how to learn, not from credentials or a sudden confidence moment. She recommends replacing identity statements like “I am not technical” with skill-based, time-bound ones like “I can’t do this yet,” which supports a growth mindset. When overwhelm appears, she advises turning it into curiosity by breaking large unknowns into smaller questions. Chan also emphasizes asking for help in a structured, respectful way and using low-stakes tinkering to build evidence that mistakes are survivable and informative. The payoff is resilience: writers keep investigating, draft sooner, and improve without waiting for perfection.

Why does Chan treat “I am not technical” as a problem, and what wording does she prefer instead?

She treats it as an identity lock. Saying “I am not technical” uses “am,” turning a skills gap into a permanent self-description, which makes change feel impossible. Her alternative keeps the limitation specific and temporary: “I can’t do this particular thing yet.” That phrasing preserves other strengths while signaling that the missing capability is learnable over time—an explicit growth-mindset move.

How should a writer respond when a deadline and unfamiliar documentation task trigger overwhelm?

Chan says overwhelm is allowed, but it shouldn’t become a spiral. Instead of staying stuck in fear, redirect attention toward curiosity—pursuing information, collaborating, and asking questions. She adds a method for making curiosity actionable: split big, indeterminate gaps into smaller ones (e.g., “how does pie work?” becomes “how does the crust work?” “how does the goo work?” “how does the hot box work?”). Smaller questions are easier to investigate and help others answer more precisely.

What makes asking colleagues for help a “better colleague” behavior rather than a burden?

Chan argues that requesting help improves credibility because it shows what the writer knows and doesn’t know, and it clarifies where information comes from. It also models teamwork and human work: people trust guidance more when it’s grounded in transparent inquiry. She even frames it as setting an example—teams benefit when writers demonstrate they’re willing to ask questions and learn.

What structure does Chan use when asking questions in Slack?

Her template is: (1) explain the situation and how the writer got there, (2) share why they’re looking at it (sometimes surprising context), (3) list what they’ve already considered so others don’t start from scratch, (4) state where they’re stuck, (5) specify what they hope to learn (not just the narrow UI detail but also context and next steps), (6) make clear why they’re asking that specific person, and (7) acknowledge the other person’s limited time. She notes that this can feel “manipulative” to some, but she frames it as normal human appreciation and clarity.

How does Chan use Benjamin Zander’s teaching to change the emotional meaning of mistakes?

She highlights a moment where Zander tells a nervous student that mistakes are observable and actionable—“Go… How fascinating”—instead of shame-inducing. Chan connects that to a common self-incrimination loop: people often treat their own errors as unacceptable while tolerating others’ mistakes. By decoupling shame from error, mistakes become “fascinating” and learners keep moving, especially in low-stakes settings like local development.

What does Chan recommend when perfectionism threatens progress?

She argues that “good enough” should win over perfectionism. Writers don’t need to be full experts to be helpful; sometimes learning alongside the audience produces clearer explanations. She also normalizes small imperfections—typos, slightly outdated screenshots—because nobody dies from them. With limited time and resources, shipping useful drafts and celebrating incremental wins (first drafts, good reviews, applied feedback) keeps momentum alive.

Review Questions

  1. Which identity-based phrases can trap learners, and what skill-based rephrasing does Chan recommend instead?
  2. Describe Chan’s approach to turning overwhelm into curiosity. How do small questions change the process?
  3. What role do low-stakes tinkering and mistake reframing play in building evidence that self-teaching works?

Key Points

  1. 1

    Replace identity statements like “I am not technical” with time-bound skill statements such as “I can’t do this yet” to keep learning possible.

  2. 2

    When overwhelm hits, don’t stay there—convert it into curiosity and turn vague unknowns into smaller, answerable questions.

  3. 3

    Ask for help without guilt by being specific about context, what’s already been tried, where you’re stuck, what you want to learn, and why you’re asking that person.

  4. 4

    Use low-stakes experimentation (especially local tinkering) to learn technical skills faster and to treat mistakes as informative rather than shameful.

  5. 5

    Counter impostor syndrome by remembering that admired people learned the same way and also have stories about failing.

  6. 6

    Avoid perfectionism that delays useful drafts; “good enough” documentation can still be genuinely helpful.

  7. 7

    Know your limits: if the learn-by-not-knowing cycle is draining, choose easier work or environments that fit your life and energy.

Highlights

Chan’s core “technical” insight: learning how to learn beats waiting for confidence or collecting credentials.
A structured Slack-question method: context, what’s been considered, where you’re stuck, what you want to learn, why that colleague, and appreciation for their time.
Mistakes become fuel when shame is decoupled from error—an approach Chan ties to Benjamin Zander’s teaching style.
Perfectionism isn’t just slow; it can block helpful writing. Typos and slightly outdated screenshots are survivable.
The best technical writers aren’t defined by certainty—they’re defined by curiosity that keeps going despite uncertainty.

Mentioned

  • Data Dog
  • VS Code
  • Atom
  • Janine Chan
  • Benjamin Zander
  • Jerome
  • UI
  • PM
  • GitHub