How to write a .MD file (Pragmatic: too Much vs too Few)

note: this article is more technical, as a practical implementation of the reflection Writing for ‘Future of Me’

General Writing

  1. always use GIT History
    to track changes

  2. pay attention to how you write
    Writing is read by humans, so write naturally.
    As much as possible, use:
    • indentation
    • outline

    Note: AI is very smart and understands natural writing immediately and easily.

  3. SDR:
    • S {Situation → Specific → Simple → Speed → Shipment}
    • D {Define → Document → Design → Develop → Delivery}
    • R {Realistic → Refine → Result}

  4. Too Few vs Too Much

     ❌ Too Few   → Incomplete, not useful
 ❌ Too Much  → Overwhelmed, information overload
 ✅ Pragmatic

    I need to find the sweet spot – the one that feels “just right”.

  5. where possible, include these 3 things:
    {Nice to have, but not always required — it can be boring}
    • Problem
    • Solution
    • Main Idea
## Problem and Solution

**Problem:**
- user wants to import data into Software
- Software has its own specific data format for each type of data

**Solution:**
- a step-by-step guide for importing data into Software

## Main Idea: prepare data in the correct Format, using Software's sample file
- Excel file from the User
- `Sample File` {_Excel Template file_} from Software
- Generate data (combination)

Technical Writing

If the section above leans more toward concepts, this section is more about the actual practice. I write a lot of technical articles on this Website.
I use these guidelines:

  1. the Pragmatic Programmer book
  2. Solve the problem
  3. not Perfectionist
    • avoid Over Engineering
    • Good > Perfect
    • final process:
      • Shipment
      • Delivery
      • Result
  4. CI / CD
    • Continuous Improvement / Continuous Development
    • step by step
    • Continuous — never stop
    • always use GitHub for:
      • storing Code
      • storing writings in .MD file format
      • GitHub Issues for capturing ideas on the fly {GitHub Issues support Versioning/History}
      • copy/paste image into .MD file or Issue == super easy
  5. SDR:
    • S {Situation → Specific → Simple → Speed → Shipment}
    • D {Define → Document → Design → Develop → Delivery}
    • R {Realistic → Refine → Result}

GOAL: for the User / Client / Reader

At the end of the day, all this technical work is built for one purpose:

a Product/Content that actually works — for User/Client/Reader who use it.

That’s the GOAL.
When in doubt about a decision, come back to that GOAL.

Nice to know:

SDR - Software DevelopeR
SDR - SuDiRman

😁😁😁
he he he… ha ha ha…