อธิบายกลไก ไม่ใช่ขั้นตอน
ทำไมคู่มือทุกเล่มที่ผมเขียนถึงเริ่มจาก "มันทำงานยังไง" ไม่ใช่ "กด 1-2-3"
คู่มือส่วนใหญ่บอกคุณว่า "ทำอะไรบ้าง" ทีละขั้น ของผมเลือกบอกว่า "มันทำงานยังไง" เพราะพอเข้าใจกลไก คุณจะคิดขั้นตอนขึ้นมาเองได้ทุกครั้งที่สถานการณ์เปลี่ยน
ขั้นตอนเน่าเสียได้ กลไกไม่
step-by-step มีจุดตายอยู่อย่างเดียว: มันใช้ได้เฉพาะกับสถานการณ์ที่คนเขียนคิดไว้ล่วงหน้า พอชีวิตจริงเบี่ยงไปนิดเดียว — ปุ่มย้ายที่ เวอร์ชันเปลี่ยน error ไม่ตรงกับในคู่มือ — คุณก็ค้าง เพราะไม่เคยรู้ว่า ทำไม ถึงต้องกดปุ่มนั้นตั้งแต่แรก
กลไกไม่เน่าแบบนั้น เข้าใจว่า git เก็บ commit เป็นกราฟ snapshot คุณจะเดา behavior ของคำสั่งที่ไม่เคยใช้ได้เอง แต่ถ้าจำแค่ว่า "พิมพ์ git rebase -i แล้วกด..." พอเจอ conflict จริงเมื่อไหร่ก็จบเห่
"เข้าใจถึงแก่น" คือมีโมเดลอยู่ในหัว
ผมชอบคำว่า เข้าใจถึงแก่น เพราะมันไม่ได้แปลว่า "จำได้เยอะ" แต่แปลว่า "มีโมเดลของสิ่งนั้นอยู่ในหัว": เล็กพอจะถือไว้ได้ทั้งก้อน แต่แม่นพอจะทำนายว่าอะไรจะเกิดขึ้น
โมเดลที่ดีทำสองอย่างพร้อมกัน
- บีบอัด — แทนที่จะจำร้อยขั้น เหลือจำหลักไม่กี่ข้อ
- ต่อยอด — จากหลักไม่กี่ข้อนั้น แตกขั้นตอนใหม่ ๆ ออกมาได้เอง
นี่คือเหตุผลที่คู่มือ git ของผมมีไดอะแกรมของ "กลไกข้างใน" ไม่ใช่แค่ลิสต์คำสั่ง และทำไม AI Brain ถึงอธิบายว่า Second Brain ทำงานยังไง ไม่ใช่แค่ "ลงแอปไหน กดตรงไหน"
ต้นทุนมีจริง แต่จ่ายครั้งเดียว
การสอนกลไกมันแพงกว่า เขียนยากกว่า อ่านช้ากว่า และช่วงแรกให้ความรู้สึกเหมือน "ยังทำอะไรไม่ได้เลยสักอย่าง"
ส่วน step-by-step ให้ dopamine เร็วกว่าเยอะ — ทำตามปุ๊บเห็นผลปั๊บ
ที่กล้าบอกว่าคุ้มเพราะเจอมากับตัวอยู่บ่อย ๆ ใน Power BI ที่ออฟฟิศ วันดีคืนดีตัวเลขงบใน dashboard ก็สูงผิดปกติ หรือกราฟที่ไม่เคยมีปัญหาอยู่ ๆ ก็พัง
ถ้ารู้แค่ขั้นตอนสร้างกราฟ ตรงนี้คือทางตัน เพราะหน้าจอไม่มีปุ่มไหนบอกว่าต้นตออยู่ตรงนี้
แต่ตัวเลขหนึ่งตัวบนจอมีเส้นทางของมัน
- ข้อมูลต้นทาง
- ความสัมพันธ์ในโมเดล
- สูตร measure
- แล้วค่อยโผล่บน visual
พอถือเส้นทางนี้ไว้ในหัว เห็นอาการปุ๊บก็นึกย้อนกลับถึงรากได้เลยว่าพังอยู่ชั้นไหน
ผมเลยมองว่ามันคือการเลือกระหว่างสองอย่างนี้
| ยืมคำตอบ | เป็นเจ้าของวิธีหาคำตอบ | |
|---|---|---|
| ได้ผลตอนไหน | เร็ววันนี้ | ช้ากว่าตอนเริ่ม |
| พอโจทย์เปลี่ยน | ต้องกลับไปยืมใหม่ | แตกขั้นตอนเองได้ |
| จ่ายกี่ครั้ง | ทุกครั้ง | ครั้งเดียว แล้วจ่ายคืนทุกครั้งที่สถานการณ์ขยับ |
สำหรับเครื่องมือที่ผมต้องใช้ไปทั้งชีวิต — git, การออกแบบระบบ, การเขียน prompt — ผมเลือกอย่างหลังเสมอ
แล้วมันก็วนกลับ
นี่แหละคือเหตุผลที่ผมเขียนคู่มือตั้งแต่แรก: ลงมือสร้างของจริง → เจอว่ากลไกมันทำงานยังไง → กลั่นออกมาเป็นโมเดลที่คนอื่นหยิบไปใช้ต่อได้ ถ้าเขียนแค่ขั้นตอน ผมกลั่นได้แค่เปลือก แต่ถ้าเขียนกลไก ผมกลั่นสิ่งที่จะเหลือรอดแม้เครื่องมือจะเปลี่ยนไป
อธิบายกลไกให้ชัด แล้วขั้นตอนจะตามมาเอง — ทุกครั้ง