การลงมือทำก็คือการลงมือทำ

 (softwaredesign.ing)
3 คะแนน โดย GN⁺ 2026-01-28 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • มีเพียง การกระทำจริงเท่านั้น ที่นับว่าเป็นการลงมือทำ ส่วนการคิดหรือการเตรียมตัวไม่ใช่การลงมือทำ
  • ย้ำซ้ำ ๆ ว่า การวางแผน การเรียนรู้ การถกเถียง การซื้อเครื่องมือ ล้วนไม่ใช่ ‘การลงมือทำงาน’
  • มีเพียง การลองทำด้วยตัวเองจริง ๆ แม้จะล้มเหลวหรือทำได้ไม่ดี เท่านั้นที่ถือเป็นการลงมือทำจริง
  • การเริ่มต้นแม้เพียงเล็กน้อย คือสิ่งสำคัญ โดยไม่จำเป็นต้องเตรียมตัวให้สมบูรณ์แบบหรือรอเงื่อนไขที่เหมาะที่สุด
  • เป็นบทความที่เตือนว่า ท่าทีที่เปลี่ยนเป็นการกระทำจริง คือหัวใจของการสร้างสรรค์และการพัฒนา

การแยกระหว่างการลงมือทำกับการไม่ลงมือทำ

  • บทความไล่เรียงว่า “การคิด การฝัน การมองภาพในหัว การเตรียมตัว” ล้วน ไม่ใช่ ‘การลงมือทำงาน’
    • ตัวอย่าง: “การคิด”, “การฝัน”, “การจินตนาการถึงความสำเร็จ”, “การรอจนกว่าจะพร้อม” เป็นต้น
  • การพูด การอธิบาย หรือการโต้เถียง ก็ไม่ถือว่าเป็นการลงมือทำ
    • รวมถึง “การอธิบายให้คนอื่นฟัง”, “การโต้เถียงบนออนไลน์”, “การประกาศว่าจะเริ่ม”

กับดักของการเตรียมตัวและการเสพข้อมูล

  • การฟังพอดแคสต์ ดูบทเรียน อ่านกรณีศึกษาของคนอื่น ล้วนไม่ใช่การลงมือทำ
  • การออกแบบระบบให้สมบูรณ์แบบ การซื้อเครื่องมือ หรือการจัดพื้นที่ทำงาน ก็ไม่ถูกมองว่าเป็นการลงมือทำ
  • ท่าทีที่ปลอบใจตัวเองด้วยความรู้สึกผิดหรือความยุ่ง ก็ไม่ใช่การกระทำจริงเช่นกัน

รูปแบบของการลงมือทำจริง

  • การทำไปทั้งที่ล้มเหลว, การทำแบบยังไม่ชำนาญ, การทำแม้จะเล็กน้อย ล้วนถูกยอมรับว่าเป็น ‘การลงมือทำงาน’
    • แม้จะไม่สมบูรณ์แบบ สิ่งสำคัญคือการลงมือขยับมือทำจริง
  • ช่วงท้ายของบทความมีการกล่าวว่า “แม้แต่การเขียนบล็อกก็ยังไม่ใช่การลงมือทำงาน” พร้อมนำไปสู่ ข้อสรุปเชิงสะท้อนตนเอง

ข้อความสำคัญ

  • มีเพียงการกระทำเท่านั้นที่เป็นการลงมือทำจริง และสิ่งอื่นทั้งหมดไม่ใช่สิ่งทดแทนของการลงมือทำ
  • การเริ่มแม้เพียงเล็กน้อย ยอมรับความล้มเหลว และลองทำด้วยตัวเอง คือความก้าวหน้าเพียงแบบเดียว
  • ประโยคสุดท้ายของบทความ “ตอนนี้ฉันต้องกลับไปทำงานแล้ว” เป็นสัญลักษณ์ของ ท่าทีที่พร้อมลงมือทันที

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
bobross0 2026-02-27

เป็นประโยคที่ดีสำหรับคนอย่างผมที่ลงมือทำได้ไม่ค่อยเก่งครับ
 
GN⁺ 2026-01-28
ความคิดเห็นจาก Hacker News

  • หลักการ “Doing it badly” เปลี่ยนวิธีคิดของฉันไปหมดเลย
    ฉันใช้เวลาหลายสัปดาห์พยายามออกแบบสถาปัตยกรรมให้สมบูรณ์แบบ แต่สุดท้ายก็หยุดวางแผนแล้วสร้าง เวอร์ชันบ้านๆ ที่แก้ปัญหาของฉันได้ขึ้นมาก่อน
    สิ่งที่น่าทึ่งคือ เวอร์ชันแรกนั้นสอนสิ่งที่ไม่มีทางเรียนรู้ได้จากการวางแผนล้วนๆ มันทำให้รู้ว่าผู้ใช้ให้ความสำคัญกับอะไรจริงๆ เคสขอบที่สำคัญในสถานการณ์จริงคืออะไร และมาตรฐานของคำว่า ‘ดีพอ’ คืออะไร
    สิ่งที่ยากที่สุดคือการยอมปล่อยของทั้งที่รู้อยู่ว่ามันยังมีข้อบกพร่อง แต่ลูปฟีดแบ็กจากการใช้งานจริงมีค่ามากกว่าการถกเถียงสมมุติหลายสัปดาห์มาก

    • เห็นด้วยกับเนื้อหา แต่ โทนของบทความมันเหมือนข้อความที่ LLM สร้าง
      เดี๋ยวนี้โพสต์แบบนี้เต็มไปหมดในซับเรดดิตสาย productivity ฉันก็สงสัยว่าการนั่งวางสถาปัตยกรรมเป็นสัปดาห์เพื่อทำเครื่องมือ automation ใช้ส่วนตัวมันสมจริงแค่ไหน
      พอดูประวัติความเห็นของผู้เขียนก็เห็นสำนวนคล้ายๆ กันซ้ำไปมา เลยไม่ค่อยน่าเชื่อถือ
    • ฉันเคยเห็นนักพัฒนาที่เก่งมากคนหนึ่งทำงานด้วยวิธี ลบโค้ดทิ้งทั้งหมดแล้วเขียนใหม่หลายรอบ
      ได้ดูขั้นตอนนั้นแล้วน่าสนใจมากจริงๆ
    • การสอนความรู้สึกแบบนี้ให้มือใหม่เป็นเรื่องยากมาก
      ในกระบวนการลงมือทำจริงและ refactor นั้น มีอะไรให้เรียนรู้ทั้งเรื่องปัญหาและการเขียนโปรแกรมโดยรวมเยอะมาก
      abstraction ที่คิดไว้ตอนแรกส่วนใหญ่ผิด พอเริ่มลงมือทำ โครงสร้างจะเปลี่ยนไปหมด และสุดท้ายก็ได้ โค้ดที่สวยงาม ซึ่งต่างจากตอนเริ่มต้นโดยสิ้นเชิง
    • มันทำให้นึกถึงบทความ “Plan to Throw One Away” ในหนังสือ 『The Mythical Man-Month』 ของ Fred Brooks
      ใจความคือให้ทำเวอร์ชันแรกโดยเตรียมใจว่าจะต้องทิ้งมัน แต่ในทางปฏิบัติส่วนใหญ่เรามักไม่ทิ้ง และค่อยๆ ปรับปรุงมันไปเรื่อยๆ
      ทุกวันนี้เราสามารถ iterate ต่อเนื่องได้เพราะเครื่องมือและกระบวนการที่ดีขึ้น
    • ประเด็นสำคัญคืออย่าสับสนระหว่างการออกแบบฟีเจอร์ระดับบนกับ plumbing ภายใน (โครงสร้างพื้นฐาน)
      โครงสร้างภายในเองก็ต้องการการทำซ้ำและการทำต้นแบบ แต่เรื่องอย่างโครงสร้างข้อมูล การจัดการข้อผิดพลาด logging และการตั้งชื่อ ควรตัดสินใจอย่างรอบคอบตั้งแต่ต้นเพื่อให้ปรับปรุงได้เร็วในภายหลัง

  • ฉันชอบประโยคที่ว่า “Doing it badly is doing the thing”
    นี่เป็นบทเรียนที่ได้จาก HN คือเวลาติดขัด อย่าเพิ่งหมกมุ่นว่าจะต้องทำให้สมบูรณ์แบบ แค่เริ่มทำก่อนสำคัญกว่า
    ต่อให้ตอนแรกมันเละเทะ พอค่อยๆ ปรับปรุงไปก็จะเริ่มเห็นภาพชัดขึ้นเอง มันเหมือนเวทมนตร์เลย

    • คำพูดที่ว่า “Everything worth doing is worth doing badly” ช่วยให้ฉันผ่านช่วงเวลายากๆ มาได้
    • มีคำแนะนำสองอย่างที่ฉันชอบเกี่ยวกับเรื่องนี้
      อย่างแรกคือ คำแนะนำของ Dan Harmon เรื่อง writer’s block และ
      อีกอย่างคือ “The Gap” ของ Ira Glass
      แก่นของมันคืออย่ารอความสมบูรณ์แบบ ให้ เขียนร่างที่ห่วยๆ ออกมาก่อน แล้วค่อยแก้ด้วยสายตาแบบนักวิจารณ์
    • ในบริษัท ถ้าทำแบบนี้กลับจะโดนบอกว่า “พอได้แล้ว” แล้วสุดท้ายก็ต้องอยู่กับเวอร์ชันที่ยังไม่เสร็จไปตลอด
      เพราะงั้นช่วงนี้ฉันเลยตั้งใจบอกว่า “ยังไม่เสร็จ” ไปก่อนจนกว่าจะทำให้เสร็จจริงๆ
    • ซอฟต์แวร์โดยทั่วไปผ่านสามช่วงคือ alpha–beta–release
      ฉันมักจะทำให้เสร็จเร็วๆ ก่อน จากนั้นค่อยขัดเกลา แล้วสุดท้ายค่อยเขียนใหม่อีกที
      เรื่องสำคัญคือ อย่าติดกับดักความสมบูรณ์แบบในช่วง beta
    • น่าสนใจที่พอมนุษย์ค่อยๆ ปรับปรุงทีละนิด คนมองว่าเป็นเรื่องดี แต่พอ LLM ทำกลับมองแง่ลบ
      ถ้า การปรับปรุงแบบค่อยเป็นค่อยไป มันได้ผลจริง จะเป็นมนุษย์หรือ AI ก็ไม่น่าต่างกัน

  • ที่บริษัทเก่าของฉัน ผู้บริหารถูกเรียกว่า “ชมรมอุทานกับปัญหา”
    พวกเขาหมกมุ่นกับการคุย วิเคราะห์ และหาคนรับผิดชอบ แต่ไม่ได้แก้ปัญหาจริงๆ
    สุดท้ายสิ่งสำคัญคือ ‘การลงมือทำจริง’

    • ในทางกลับกัน บางบริษัทกลับ ยึดติดกับวิธีแก้เดิม มากจนไม่ยอมมองปัญหาใหม่อีกครั้ง
      วิธีที่ดีที่สุดคือมีทั้งความใส่ใจกับปัญหาและความตั้งใจจะแก้แบบทำซ้ำไปเรื่อยๆ
      การ dogfooding โดยให้คนในใช้ของนั้นเอง เป็นวิธีที่ดีในการรักษาสมดุลนั้น
    • สุดท้าย ถ้าคุณเป็นคนที่ลงมือทำงานจริง คุณก็ต้อง ใช้สิทธิ์ในการตัดสินใจนั้น
      สิ่งสำคัญคือพยายามตัดสินใจให้เอื้อต่อตัวเองให้มากที่สุดเท่าที่จะทำได้
    • การเอา ผู้จัดการระดับกลาง ออกไปช่วยเพิ่มผลิตภาพได้
      การประสานงานเพื่ออัปเดตลดลง และองค์กรที่ทำงานจริงก็มีประสิทธิภาพมากกว่า
    • หลังจากวิเคราะห์ปัญหาแล้ว ถ้าคุณมี เหตุผลที่จะเริ่มทำอย่างอื่นเดี๋ยวนี้ แบบนั้นก็ไม่เป็นไร

  • บทความนี้คล้ายกับ บทความของ strangestloop.io มาก

    • พูดตรงๆ ว่ามันให้ความรู้สึกเกือบ ถึงขั้นลอกเลียน
      ฉันเห็นชื่อแล้วรู้สึกคุ้นๆ พอกดเข้าไปกลับเป็นอีกเว็บและโพสต์เมื่อไม่กี่วันก่อน เลยตกใจ
      เนื้อหาคล้ายกันเกินกว่าจะบอกว่าเป็นเรื่องบังเอิญได้
    • ฉันเองก็จำไม่ได้ว่าก่อนหน้านี้เห็นเรื่องนี้จากที่ไหน แต่จำได้ว่าเคยอ่านอะไรที่คล้ายๆ กัน

  • เมื่อก่อนฉันคิดว่าการเตรียมตัวสำคัญ แต่พอถึงจุดหนึ่งก็รู้ว่า การเตรียมตัวกลายเป็นลูปไม่รู้จบ ได้
    ทีมของเราสร้างผลิตภัณฑ์เสร็จใน 4 เดือนจากสเปกยาว 2 หน้า แต่ทีมคู่แข่งใช้เวลา 8 เดือนเขียนเอกสารอย่างเดียวแล้วสุดท้ายก็ยุบทีม
    การวางแผนแค่ 20% ก็จัดการปัญหาได้ 80% แล้ว หลังจากนั้นมันก็เป็นแค่ ความเข้มงวดที่ถูกห่อด้วยความกังวล
    สุดท้ายสิ่งที่ฉันได้เรียนรู้ส่วนใหญ่ก็มาจากการปล่อยของที่น่าอายออกไปแล้วค่อยแก้

    • ดูเหมือนคุณจะเข้าใจประเด็นของบทความคลาดเคลื่อนไปนิดหน่อย ฉันมองว่า ‘การเตรียมตัว’ เองก็อยู่ในหมวด ‘ไม่ใช่ doing the thing’ อยู่แล้ว
    • มันแล้วแต่ทีม ทีมของเราวางแผนกันหลายเดือนแล้วก็ยังปล่อยของได้ดี สุดท้ายคือ ขึ้นอยู่กับบริบท
    • ประโยชน์ของการวางแผนลดลงตามเวลา แต่โปรเจกต์ส่วนใหญ่พังเพราะ วางแผนน้อยเกินไป มากกว่า
    • มันทำให้นึกถึงฉากที่ Rimmer ใน Red Dwarf เอาแต่เตรียมสอบจนสอบตก
      มีการอ้างถึงไว้ใน คอมเมนต์ HN ก่อนหน้า
    • การตัดการวางแผนออกไปทั้งหมดก็มีปัญหาเหมือนกัน ต้อง หาสมดุล

  • Analysis paralysis มีอยู่จริง
    ถ้าไม่อยากหยุดนิ่ง ก็ต้องเริ่มก่อน จัดการ happy path ให้ได้ก่อน แล้วค่อยมาเก็บเคสขอบทีหลัง
    ทุกวันนี้ต้นทุนของการทำ prototype ต่ำลงมาก จึงไม่ควรกลัวความล้มเหลวและควรลองให้ไว
    นี่เองก็เป็นเหตุผลที่ LLM มีประสิทธิภาพอย่างน่าทึ่ง — มัน ลงมือทำทันทีแทนการวิเคราะห์
    ถึงผลลัพธ์จะไม่สมบูรณ์แบบ แต่ก็มักใช้งานได้ดีพอ และถ้าจำเป็นค่อยไป optimize ทีหลังได้
    ก่อนจะสร้าง framework คุณควรสร้างระบบจริงอย่างน้อยสามครั้งก่อน จะได้รู้ว่าส่วนไหนเยอะเกินไปหรือน้อยเกินไป

    • แต่อย่า เข้าใจ prototype ว่าเป็นผลิตภัณฑ์จริง
      คำว่า ‘ดีพอใช้’ อาจกลายเป็นการหลอกตัวเองได้
      prototype ที่ล้มเหลวไม่ได้แปลว่าไม่มีตลาด แค่มันเป็น สัญญาณว่ายังมีอะไรบางอย่างขาดอยู่ เท่านั้น

  • บทความนี้มีสารที่แทบจะเหมือนกับ โพสต์ก่อนหน้า
    และเคยถูกพูดถึงใน การถกเถียง HN ก่อนหน้า แล้ว

    • เนื้อหาคล้ายกันมากจนควรถูกติดป้ายว่าเป็น โพสต์ซ้ำ (dupe) เลย

  • ในทางกลับกัน บางครั้ง ‘doing the thing’ เองก็อาจเป็นทางเลือกที่ผิด
    เพราะงั้นฉันยังยืนยันจะใช้ design document และ code review ต่อไป
    ในยุค GenAI การ ‘ลองทำแบบส่งๆ โดยไม่วางแผน’ กลายเป็นเรื่องง่ายเกินไป จึงยิ่งต้องมี ตัวถ่วงดุล มากขึ้น

    • ทุกวันนี้ happy path ทำได้ง่ายขึ้นก็จริง แต่ ช่องว่างระหว่าง prototype กับ production กลับกว้างขึ้น
      เวลาส่วนใหญ่หมดไปกับปัญหา non-determinism และ latency แล้วสุดท้ายความท้าทายที่แท้จริงคือการทำให้ unit economics ลงตัว

  • ใน 『Remains of The Day』 การ ‘เอาแต่พูดถึง the thing’ ถูกเรียกว่า พฤติกรรมที่ทำให้ตัวเองพึงพอใจ
    มันมักจบลงที่การคุยแล้วรู้สึกดี ทั้งที่ในความเป็นจริงไม่ได้ทำอะไรสำเร็จเลย

  • ในอีกมุมหนึ่ง การวางแผน การเตรียมตัว และ mise-en-place ก็สามารถช่วยให้การลงมือทำจริงดีขึ้นได้

    • แต่จะมีความหมายก็ต่อเมื่อ นำไปสู่การลงมือทำจริงเท่านั้น ต้องไม่ตกอยู่ในภาวะวิเคราะห์จนขยับไม่ได้
    • คนมักเข้าใจผิดว่าการวางแผนหรือการพูดคุยคือ ‘doing the thing’ ทั้งที่นั่นแหละคือปัญหา