The 80/20 Guide to Technical Documentation for Small Teams

You don't need a 500-page wiki — you need the right documentation, at the right time, for the right audience.

DocumentationEngineeringSMB

Content (raw — renderer coming soon)

{
  "root": {
    "type": "root",
    "format": "",
    "indent": 0,
    "version": 1,
    "children": [
      {
        "type": "paragraph",
        "format": "",
        "indent": 0,
        "version": 1,
        "children": [
          {
            "mode": "normal",
            "text": "Documentation is one of those things everyone agrees is important, but nobody actually wants to write. The key is to focus on the 20% of documentation that gives you 80% of the value.",
            "type": "text",
            "style": "",
            "detail": 0,
            "format": 0,
            "version": 1
          }
        ],
        "direction": "ltr"
      },
      {
        "type": "paragraph",
        "format": "",
        "indent": 0,
        "version": 1,
        "children": [
          {
            "mode": "normal",
            "text": "What you must document: 1) Architecture decisions (ADRs) — why you chose X over Y, so future teams don't repeat the same debates. 2) Deployment instructions — how to get code from your laptop to production. 3) Onboarding guide — how to get a new engineer productive in a week.",
            "type": "text",
            "style": "",
            "detail": 0,
            "format": 0,
            "version": 1
          }
        ],
        "direction": "ltr"
      },
      {
        "type": "paragraph",
        "format": "",
        "indent": 0,
        "version": 1,
        "children": [
          {
            "mode": "normal",
            "text": "What you can skip (for now): Inline code comments for obvious code, exhaustive API docs that will be outdated next month, and theoretical architecture diagrams that don't match reality.",
            "type": "text",
            "style": "",
            "detail": 0,
            "format": 0,
            "version": 1
          }
        ],
        "direction": "ltr"
      },
      {
        "type": "paragraph",
        "format": "",
        "indent": 0,
        "version": 1,
        "children": [
          {
            "mode": "normal",
            "text": "The best documentation lives as close to the code as possible. A README in your repo is better than a wiki page somewhere. Comments in your database migration explain why you did what you did.",
            "type": "text",
            "style": "",
            "detail": 0,
            "format": 0,
            "version": 1
          }
        ],
        "direction": "ltr"
      },
      {
        "type": "paragraph",
        "format": "",
        "indent": 0,
        "version": 1,
        "children": [
          {
            "mode": "normal",
            "text": "Documentation doesn't have to be perfect — it just has to be good enough to reduce the bus factor for your team.",
            "type": "text",
            "style": "",
            "detail": 0,
            "format": 0,
            "version": 1
          }
        ],
        "direction": "ltr"
      }
    ],
    "direction": "ltr"
  }
}