ความสนุกของการสร้างซอฟต์แวร์ของเล่น

• การสร้าง Toy ซอฟต์แวร์ เป็นวิธีฟื้นคืน ความสนุก และความคิดสร้างสรรค์ที่เป็นแก่นแท้ของการพัฒนาซอฟต์แวร์
• ในยุคที่ ความสุขอันบริสุทธิ์ของการพัฒนาซอฟต์แวร์ กำลังเลือนหายไปเพราะ AI และการทำให้อุตสาหกรรมเป็นระบบ การทำโปรเจกต์ส่วนตัวอย่าง โปรแกรมของเล่นง่ายๆ สามารถเป็นจุดเริ่มต้นให้ได้ความรู้ที่ใช้ได้จริงในงานและความเข้าใจที่ลึกซึ้งขึ้น
• ซอฟต์แวร์ของเล่น ยึดตามกฎ 80:20 โดยทำฟังก์ชันให้ได้มากที่สุดด้วยโค้ดให้น้อยที่สุด และหัวใจสำคัญคือ หลีกเลี่ยงการออกแบบที่มากเกินไปหรือการหมกมุ่นกับความสมบูรณ์แบบ
• ประสบการณ์ของการลงมือสร้างด้วยตนเองโดยไม่พึ่งเครื่องมือ AI อย่าง LLM คือความสุขพื้นฐานของการเรียนรู้และการเติบโต

---

ทำไมเราควรสร้างโปรแกรมของเล่นให้มากขึ้น

• คำกล่าวของ Richard Feynman ว่า “สิ่งที่ฉันสร้างไม่ได้ คือสิ่งที่ฉันยังไม่เข้าใจ” → ประสบการณ์ของการลงมือสร้างบางอย่างด้วยตัวเองนำไปสู่ความเข้าใจที่ลึกซึ้ง
• ต่างจากคำแนะนำเดิมที่ว่า ‘อย่าสร้างวงล้อขึ้นมาใหม่’ ประสบการณ์ของการ ลองสร้างวงล้อด้วยตัวเอง สอนอะไรได้มากกว่าการอ่านหรือการเรียนรู้เชิงทฤษฎี
• ช่วงหลังมานี้ AI และการทำให้อุตสาหกรรมซอฟต์แวร์เป็นระบบกำลังคุกคาม ความสนุก และ ความเป็นช่างฝีมือ ของการพัฒนา
• การสร้างซอฟต์แวร์ของเล่นช่วยฟื้น ความสนุกง่ายๆ ที่ทำให้เราหลงใหลคอมพิวเตอร์อีกครั้ง

หลักการของโปรแกรมของเล่น: Keep it simple

• ซอฟต์แวร์ของเล่นยึดหลัก 80:20: ใช้ความพยายาม 20% เพื่อให้ได้ฟังก์ชัน 80%
• เป้าหมาย ไม่ใช่ผลิตภัณฑ์สุดท้าย แต่คือความเรียบง่ายและการลงมือสร้างหลักการสำคัญด้วยตัวเอง
• เน้นการระวัง การออกแบบโครงสร้างเกินความจำเป็น (over-engineering) และเขียนเฉพาะโค้ดที่จำเป็นจริงๆ
• แนะนำแนวทางที่ ปล่อยให้เส้นทางของโค้ดทั้งหมดอยู่ในสถานะยังไม่ถูก implement แล้วค่อยขยายการ implement ออกไปเมื่อจำเป็น
• แม้ระบบจะดูเล็ก แต่เมื่อได้ลองทำจริงก็มักพบว่าสามารถสร้างได้ง่ายกว่าที่คิด

ประโยชน์เพิ่มเติมของซอฟต์แวร์ของเล่น

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

ตัวอย่าง: รายการโปรเจกต์ซอฟต์แวร์ของเล่นหลากหลายแบบ

ผู้เขียนได้สรุป ประเภทของโปรเจกต์ของเล่น ที่เคยลงมือทำเองตลอด 15 ปีที่ผ่านมา พร้อมระดับความยากและเวลาที่คาดว่าจะใช้ โดยแต่ละโปรเจกต์มีคำอธิบายสั้นๆ และแหล่งอ้างอิงเพิ่มเติม

• Regex เอนจิน (ความยาก 4/10, 5 วัน) : แปลความ regular expression แบบ POSIX และระบุสตริงที่ตรงกัน ช่วยให้เข้าใจการทำงานภายในของ regex อย่างลึกซึ้ง
• x86 OS เคอร์เนล (ความยาก 7/10, 2 เดือน) : รวม CLI ไดรเวอร์อย่างง่าย เมมโมรีแมเนเจอร์ ฯลฯ และสามารถท้าทายตัวเองเพิ่มด้วย in-memory filesystem, ไฟล์ปฏิบัติการ ELF, GUI, process isolation เป็นต้น
• GameBoy/NES อีมูเลเตอร์ (ความยาก 6/10, 3 สัปดาห์) : เรียนรู้ชุดคำสั่งแบบง่ายและฮาร์ดแวร์ รวมถึงการทำ PPU, PSG และฟอร์แมตคาร์ทริดจ์ที่มีลักษณะเฉพาะ
• เกม GameBoy Advance (ความยาก 3/10, 2 สัปดาห์) : เกมง่ายๆ ที่อิงสไปรต์ ชุมชนพัฒนา GBA ยังมีความคึกคัก และเป็นโครงสร้างระบบที่ทำความเข้าใจได้ด้วยตัวคนเดียว
• เอนจินฟิสิกส์ 2D (ความยาก 5/10, 1 สัปดาห์) : กลศาสตร์นิวตันพื้นฐานและการจัดการการชนแบบง่าย สามารถต่อยอดไปสู่รูปร่างซับซ้อน ความเฉื่อย อัลกอริทึมการแก้ปัญหา soft body/ปฏิสัมพันธ์แบบผสมได้
• Dynamic Interpreter (ความยาก 4/10, 1~2 สัปดาห์) : tree-walking interpreter การสร้างภาษาของตัวเองให้ทั้งความสุขทางเทคนิคและความคิดสร้างสรรค์
• คอมไพเลอร์สาย C (ความยาก 8/10, 3 เดือน) : ออกแบบสถาปัตยกรรมที่รองรับระบบชนิดข้อมูลแบบง่าย สภาพแวดล้อมเป้าหมาย การเพิ่มประสิทธิภาพต่างๆ และแบ็กเอนด์หลายแบบ
• Text Editor (ความยาก 5/10, 2~4 สัปดาห์) : เริ่มจาก file I/O อย่างง่าย ใช้ UI toolkit อย่าง QT/GTK ได้ หรือเลือกแบบคอนโซล แล้วเพิ่มฟีเจอร์อย่าง unicode, syntax highlighting, multi-buffer, LSP
• Async Runtime (ความยาก 6/10, 1 สัปดาห์) : ในกรณีของ Rust คือการจัดการ task แบบ impl Future และการทำ concurrency พร้อมต่อยอดด้วยการปลุก I/O
• Hash Map (ความยาก 4/10, 3~5 วัน) : เรียนรู้หลักการทำงานภายใน, closed/open addressing, กฎแบบ Robin Hood รวมถึงความเข้าใจเรื่องประสิทธิภาพและช่วงเวลาที่เหมาะสมในการใช้งาน
• Rasteriser / Texture Mapper (ความยาก 6/10, 2 สัปดาห์) : เรียนรู้โครงสร้างของ 3D graphics pipeline เวกเตอร์คณิตศาสตร์ Z-buffer และต่อยอดสู่ texture mapping กับอัลกอริทึม shading ได้
• การเรนเดอร์ Signed Distance Field (ความยาก 5/10, 3 วัน) : ทำความเข้าใจการแทนพื้นที่เชิงคณิตศาสตร์ การทำ visualization แบบง่าย รวมถึง shader และเวกเตอร์คณิตศาสตร์
• Voxel เอนจิน (ความยาก 5/10, 2 สัปดาห์) : หากมีประสบการณ์ด้าน 3D graphics หรือการพัฒนาเกมจะเข้าใจได้ง่าย และยังเพิ่มความท้าทายด้วย texture, procedural generation, network ฯลฯ ได้
• Threaded Virtual Machine (ความยาก 6/10, 1 สัปดาห์) : อินเทอร์พรีเตอร์ที่รวดเร็ว สร้างอินเทอร์พรีเตอร์ที่ optimize แล้วโดยไม่ต้องสร้างโค้ดแยกตามสถาปัตยกรรม และอาจได้ประสิทธิภาพใกล้เคียงคอมไพเลอร์
• GUI Toolkit (ความยาก 6/10, 2~3 สัปดาห์) : หลังมีประสบการณ์สร้างเครื่องมือ UI พื้นฐานแล้ว สามารถทำฟีเจอร์เชิงลึกอย่าง layout engine, text shaping, accessibility ได้ด้วยตัวเอง
• ตัวจำลองกลศาสตร์วงโคจร (ความยาก 6/10, 1 สัปดาห์) : สร้างโมเดลแรงโน้มถ่วงของนิวตันแบบง่าย ขยายไปสู่ปฏิสัมพันธ์ของหลายวัตถุท้องฟ้า อัลกอริทึมการอินทิเกรต การทำภาพ และการใช้ข้อมูลจาก NASA ได้
• Bitwise Challenge (ความยาก 3/10, 2~3 วัน) : เกมที่ถ่ายทอดสถานะได้ด้วยสถานะ 64 บิตเพียงอย่างเดียว เป็นการฝึกการจัดการสถานะเชิงสร้างสรรค์ และดูรายละเอียดกติกาเพิ่มเติมได้บน GitHub
• ECS เฟรมเวิร์ก (ความยาก 4/10, 1~2 สัปดาห์) : ลงมือสร้างโครงสร้าง Entity-Component-System เอง ผสานเข้ากับระบบชนิดข้อมูลของภาษา และปรับแต่งให้เหมาะกับข้อจำกัดและสมรรถนะสูง
• CHIP-8 อีมูเลเตอร์ (ความยาก 3/10, 3~6 วัน) : virtual machine แบบเรียบง่ายจากยุค 1970 สร้างได้รวดเร็ว และสามารถดูหรือรันแฟนเกมหลากหลายแบบได้
• Chess Engine (ความยาก 5/10, 2~5 วัน) : เริ่มจากกฎพื้นฐานแล้วค่อยๆ พัฒนา และการแพ้ให้กับเอนจินที่ตัวเองสร้างขึ้นคืออีกช่วงหนึ่งของการเติบโตของนักพัฒนา
• POSIX Shell (ความยาก 4/10, 3~5 วัน) : เข้าใจหลักการและข้อจำกัดของเชลล์แบบ POSIX อย่างลึกซึ้ง ผ่านการทำ compatibility กับภาษา Shell จริงและการพบกับลูกเล่นนับไม่ถ้วน

คำแนะนำเกี่ยวกับการใช้เครื่องมืออย่าง LLM

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

• หากเดินทางด้วยรถยนต์ คุณจะไม่สัมผัส ‘runner’s high’ แบบนักวิ่ง → ความสุขที่ลึกซึ้งเกิดจากประสบการณ์ตรง ไม่ใช่ทางลัด

[tolluset]

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

[nezz1204]

อ๋อ หมายถึงโปรเจกต์เล่น ๆ นี่เองนะครับ แค่เห็นชื่อก็เผลอคิดไปว่าเป็นการทำซอฟต์แวร์ที่ใส่อยู่ในของเล่นซะอีก ฮ่าๆ

[GN⁺]

ความคิดเห็นบน Hacker News

• สงสัยว่ามีใครใช้ LLM เหมือนเป็น search engine ไหม เมื่อก่อนเคยค้น Google ประมาณว่า “pros cons mysql mongodb” แล้วก็ต้องไล่อ่านทั้งเอกสารทางการ ฟอรั่ม บล็อก และ Stack Overflow กินเวลาเยอะมาก แต่เวลาที่ใช้ไปกับการอ่านและเรียนรู้ก็เป็นสิ่งที่ยินดีรับเสมอ ตอนนี้จะใส่พรอมป์ให้ LLM แบบเจาะจงขึ้น เช่น “ข้อดีข้อเสียของ mysql vs mongodb สำหรับเก็บรูปภาพ พร้อมลิงก์อ้างอิง” ทำให้จับประเด็นสำคัญได้เร็ว และมีลิงก์แนบมาด้วย เลยไม่ต้องพึ่งภาพหลอนของมันอย่างเดียว บางครั้งก็ขอแบบเฉพาะเจาะจง เช่น “ช่วยออกแบบ data schema สำหรับเก็บ metadata รูปภาพใน postgres อยากแยก X ไปไว้อีกตาราง” แต่จะใช้แบบนี้ก็ต่อเมื่อรู้ชัดเจนอยู่แล้วว่าผลลัพธ์ที่ต้องการควรออกมาเป็นแบบไหน ใช้แค่ตอนเสียดายเวลาพิมพ์ หรือเผลอลืมชื่อ type แบบเฉพาะ ๆ ชั่วคราว เช่น int กับ integer

  • ถ้าใช้ LLM เป็นเครื่องมือตอบคำถามเชิงเทคนิค มันมักให้ข้อมูลที่ดูน่าเชื่อถือเผิน ๆ แต่ผิดตรงจุดสำคัญบ่อยมาก ถ้าเชื่อตามตรง ๆ แล้วเดินตามคำตอบไป อาจเสียเวลาเปล่าเป็นชั่วโมงหรือเป็นวัน แม้จะขอลิงก์อ้างอิง บางครั้งก็ได้ข้อมูลจริง แต่บางครั้งก็ให้เนื้อหาที่ไม่เกี่ยวกัน อย่างไรก็ดี มีอย่างหนึ่งที่มันทำได้ดีชัดเจนคือการค้นย้อนแบบ "tip-of-my-tongue" คือเราอธิบายแนวคิดไป แล้วมันช่วยแนะนำคำค้นที่ตรงกับสิ่งนั้นได้อย่างสม่ำเสมอและน่าพอใจ
  • อีกไม่นานบริษัทต่าง ๆ น่าจะจ่ายเงินก้อนโตให้ LLM เพื่อให้ผลิตภัณฑ์ของตัวเองถูกนำเสนอในการเปรียบเทียบว่าเหนือกว่าได้ LLM สามารถปรับกรอบการนำเสนอและจุดเน้นให้ผลลัพธ์ดูเหมือน 'เกิดขึ้นเองตามธรรมชาติ' ได้ เพราะมันยังคงแสดงแต่ข้อมูลจริงที่มีหลักฐานรองรับ และเปลี่ยนแค่ 'น้ำหนักของบริบท' เท่านั้น
  • ฉันก็ใช้ LLM เพื่อค้นหาเหมือนกัน ความรู้สึกเหมือนได้ย้อนกลับไปยุคต้นทศวรรษ 2010 ที่การค้น Google ทรงพลังมาก เป็นช่วงที่ค้นอะไรก็เจอ แน่นอนว่าช่วงนั้นอยู่ได้ไม่นาน และตอนนี้การค้น Google ก็แทบเป็นความเจ็บปวดกับความหงุดหงิดล้วน ๆ ฉันมีเรื่องให้บ่นกับการเปลี่ยนแปลงที่ Google กับนักการตลาดสร้างไว้เยอะเหมือนกัน แต่ ณ ตอนนี้ LLM ให้ความรู้สึกว่ามีประสิทธิภาพมากในการดึงข้อมูลบนอินเทอร์เน็ตขึ้นมาให้เห็นแบบฉับไว ลิงก์อ้างอิงก็ค่อนข้างแม่นอยู่ สุดท้ายแรงผลักแบบเดิมก็คงเกิดขึ้นอีก และนี่น่าจะเป็นแค่โอกาสช่วงสั้น ๆ ก่อนที่มันจะเสื่อมสภาพเหมือนเดิม
  • ฉันก็เป็นอีกคนที่ใช้ LLM เหมือน search engine ยังไม่ได้ใช้ AI IDE ช่วงนี้ตอนสัมภาษณ์งานเทคนิคแบบสด ฉันพยายามตอบโดยถาม LLM ที่เลือกใช้เหมือนเวลาค้น Google แล้วคนสัมภาษณ์บอกว่าไม่เคยเจอผู้สมัครที่ใช้ AI แบบนี้มาก่อน ฉันนึกว่านักพัฒนาส่วนใหญ่ยังใช้มันเพื่อค้นหาก่อน มากกว่าจะไปใช้ AI IDE กันแล้ว หรือว่ากรณีแบบพวกเราเป็นส่วนน้อย?
  • แม้แต่ตอนพัฒนาก็ยังใช้ LLM แบบ search engine เช่น “ช่วยวิเคราะห์ repo ที่ฉัน clone ไว้ใน /src/foo แล้วอธิบายว่า barFeature ถูก implement ไว้อย่างไร ทีนี้ลองดูโปรเจ็กต์ /src/baz แล้วอธิบายว่าทำไมแนวทางของ foo ถึงนำมาใช้กับ baz ได้ยาก” ใช้มันเพื่อแปลสิ่งที่มีอยู่แล้วให้เข้ากับไอเดียของตัวเอง ไม่ได้ใช้ให้สร้างอะไรใหม่ ๆ เพราะงานพัฒนาที่ใหม่จริงและท้าทายจริง ฉันยังสนุกกว่าถ้าได้เขียนเอง

• หนึ่งในสิ่งที่ดีที่สุดต่อเส้นทางอาชีพที่ฉันเคยทำ คือการหยุดพัก 6 เดือนระหว่างงานแล้วทำโปรเจ็กต์ส่วนตัว ปกติมีโปรเจ็กต์ที่อยากเริ่มเยอะมาก แต่เพราะไม่มีข้อจำกัด ขอบเขตก็มักบานปลายจนสุดท้ายทำไม่เสร็จ เลยตัดสินใจว่าจะให้แต่ละโปรเจ็กต์แค่ 1 สัปดาห์เท่านั้น ทำได้แค่ไหนใน 1 สัปดาห์ก็เอาแค่นั้น การเริ่มจากศูนย์แล้วสร้างอะไรที่ใช้งานได้ภายใน 1 สัปดาห์ ไม่ว่าจะด้วยภาษาใหม่ framework ใหม่ หรือในโดเมนที่ไม่คุ้นเคย เป็นประสบการณ์ที่สร้างความมั่นใจอย่างมหาศาล และยังทำให้นึกได้อีกครั้งว่าทำไมเดิมทีถึงชอบการเขียนโปรแกรม ถ้ามีช่วงพักระหว่างงานสักหลายเดือน แทนที่จะเตรียมสัมภาษณ์แบบ Silicon Valley ลองไปทำ toy project ดู แล้วจะตกใจว่าจริง ๆ ตัวเองรู้มากขนาดไหนแล้ว

  • ถ้ามีเครื่องมือสร้างงานด้วย AI มันช่วยโปรเจ็กต์ส่วนตัวแบบนี้ได้มาก ฉันถนัด backend เป็นหลัก แต่ก็พอทำ frontend ได้ เพียงแต่ CSS กินเวลามากเกินไป จนเมื่อก่อนมักทำโปรเจ็กต์ส่วนตัวไม่จบ ตอนนี้แค่บอก AI ว่า “ช่วยทำให้สวยหน่อย” มันก็ทำมาได้ถึงประมาณ 85% แล้ว เหลือแค่แก้บั๊กหรือเก็บรายละเอียดอีกนิดหน่อยก็ปิดงานได้เร็ว เมื่อก่อนการพัฒนามันเหมือนลุยโคลน แต่ตอนนี้ง่ายขึ้นมาก เลยทำโปรเจ็กต์ส่วนตัวได้บ่อยกว่าเดิม
  • ช่วงนี้เริ่มไม่พอใจกับไลบรารีที่ใช้อยู่มากขึ้นเรื่อย ๆ เลยหันไปแก้เอง พอเจอเอกสาร onboarding ที่ไม่สมบูรณ์ SDLC ที่พัง หรือปัญหาประสิทธิภาพหนัก ๆ ก็หมดวันไปกับการแก้สิ่งเหล่านั้น ต่างจากโปรเจ็กต์ร่วมกับคนอื่นที่มีคนรออยู่ เพราะ toy project ส่วนตัวนี่หลุดไปทำ side quest ได้ง่ายมาก งานร่วมกันมันมีแรงกดดันจากการที่มีคนรอ
  • อยากรู้ว่าพักได้ตั้ง 6 เดือนแล้วยังหางานถัดไปได้อย่างไร ฉันก็อยากพักสัก 6 เดือนเหมือนกัน แต่กังวลว่าจะหางานไม่ได้ แล้วต้องพักยาวกว่านั้น
  • ตอนเด็ก ๆ เคยตั้งเซิร์ฟเวอร์ด้วย classic ASP + SQL จัดการทั้ง HTML/CSS/JS และ deploy ได้ง่ายมาก สมัยนั้นแค่อัปไฟล์ขึ้น FTP ก็พอแล้ว ตอนนี้อยากลองแนวทางสมัยใหม่ขึ้นบ้าง แต่พอทำโปรเจ็กต์ส่วนตัวทีไร ก็มักหลงอยู่กับคำถามเรื่อง deployment กับกระบวนการพัฒนา (lifecycle) ทุกที เลยอยากรู้ว่าคนอื่นเลือกโฮสต์และวิธี deploy สำหรับ toy project กันอย่างไร
  • ฉันก็รู้สึกชัดเจนเหมือนกันว่า AI ช่วยเร่งความเร็วของโปรเจ็กต์ส่วนตัวแบบนี้ได้จริง โดยเฉพาะเวลามันสร้าง boilerplate หรือโค้ดทดสอบอัตโนมัติให้

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

  • ฉันชอบพัฒนาซอฟต์แวร์ไว้ใช้เองมากกว่า เหมือนกับรถยนต์ที่ยิ่งขับได้นานด้วยค่าใช้จ่ายต่ำก็ยิ่งรู้สึกคุ้ม
  • เคยมีช่วงหนึ่งที่ฉันดูแล email server เอง แต่ตอนนี้ไม่ทำแล้ว ไม่ใช่เพราะอยากลงมือทำเองจริง ๆ แต่เป็นเพราะรู้สึกว่าเรื่องนี้อยากปล่อยให้ผู้เชี่ยวชาญจัดการมากกว่า
  • ไม่นานมานี้ฉันทำแอป invoice ขึ้นมาเอง สนุกมากที่ได้ค่อย ๆ เพิ่มฟีเจอร์ที่ต้องการทีละอย่าง ใส่ครบแม้แต่ฟีเจอร์ที่ปกติต้องจ่ายรายเดือนให้บริการอื่น แต่พอถึงเวลาที่ต้องส่งใบแจ้งหนี้จริง ๆ ก็พบว่ายังมีปัญหาในแอปที่ตัวเองทำอีกเยอะมากที่ต้องจัดการ เช่น เรื่องสไตล์หรือการกรอกที่อยู่ สุดท้ายเลยรู้สึกว่าต้องหาสมดุลระหว่างความสนุกแบบการปั่นจักรยานเล่น กับความใช้งานได้จริงของจักรยานสำหรับเดินทาง และก็เริ่มตระหนักว่าเมื่อเวลาผ่านไป ความสนุกกับความใช้งานได้จริงอาจค่อย ๆ เข้าใกล้กันมากขึ้น
  • ฉันเองก็มีหลายอย่างมากที่อยากทำให้เป็น “ซอฟต์แวร์ที่เสร็จสมบูรณ์” แต่ไม่มีทั้งเวลาและพลังงาน งานที่น่าเบื่อและซ้ำซากก็มีเยอะมากเหมือนกัน ถึงอย่างนั้น การคอยจัดการและคัดกรอง “ผลงานจาก AI” ก็เป็นงานไม่น้อยเหมือนกัน ตอนนี้ยังอยู่ในช่วงทดลองระยะแรก เลยไม่แน่ใจว่าอีกไม่กี่เดือนข้างหน้าจะยังคิดเหมือนเดิมไหม
  • ด้วยเหตุนี้แหละ การทำโฮมเพจส่วนตัวจึงสนุกมาก เพราะใช้เป็นสนามเด็กเล่นของตัวเองได้จริง

• แปลกใจที่มีความเห็นเชิงลบต่อ LLM เยอะมาก LLM ป้อนข้อมูลให้ถึงปาก ตอนเริ่มโปรเจ็กต์ใหม่ มันเป็นเรื่องปกติอยู่แล้วที่จะไม่ได้รู้ทุกอย่างตั้งแต่แรก การพยายามอย่างเต็มที่แล้วพัง จากนั้นค่อยไปศึกษา ทำความเข้าใจว่าทำไมมันถึงไม่เวิร์ก และปรับด้วยแนวทางใหม่ นั่นแหละคือการเรียนรู้จริง ถ้ารู้ทุกอย่างหมดแล้วแค่ทำตาม tutorial ก็จะไม่ได้สัมผัสข้อจำกัดของแต่ละวิธีหรือข้อดีข้อเสียจริง ๆ เช่น ลองทำ parser ด้วย regular expression แล้วค้นพบเองว่ามันรับมือ recursive expression ไม่ได้ แบบนี้เราจะได้เรียนรู้ทั้งโครงสร้างที่ซับซ้อนขึ้นและปัญหาเรื่อง time complexity ไปพร้อมกัน หรือถ้าลองเขียน optimizing compiler เองแล้วติดกับดักเทคนิค optimization สารพัด ก็จะเข้าใจว่าทำไม compiler จริงถึงถูกออกแบบแบบนั้น การได้ลองเขียน layout engine เองก็ทำให้สัมผัสได้แม้กระทั่งความยากของการจัดการแนวคิดอย่าง width ประสบการณ์ที่เกิดจากการลองผิดลองถูกนั้นไม่มีอะไรดีไปกว่าอีกแล้ว ถึง LLM จะช่วยกันไม่ให้ทำพลาด แต่ก็หวังว่าจะไม่ทำให้พลาดโอกาสการเรียนรู้ที่สำคัญไปด้วย

  • หลายคนบอกว่าถ้าไม่ใช้ LLM จะตามไม่ทัน แต่ฉันกลับคิดว่าการใช้ LLM น้อยกว่าอาจเป็นข้อได้เปรียบใหญ่ในระยะยาว

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

  • Tiny ray-tracer
  • 2D rigid-body simulator
  • Character animation system
  • Animation curve visualizer
  • Motion capture playback in the web เป้าหมายที่แท้จริงของภูเขาโค้ดเหล่านี้ทั้งหมดคือ “การแสวงหาความรู้”

• รู้สึกว่าวิญญาณของ “ความสนุกในการเขียนโปรแกรม” ที่บทความนี้เสนอจำเป็นมากจริง ๆ และยิ่งมีค่ามากขึ้นในยุค AI agent coding แต่รู้สึกว่าเวลาประมาณการของ toy project ที่ผู้เขียนเสนอไว้นั้นสั้นเกินไป ฉันอาจไม่ได้เร็วระดับเฉลี่ยก็จริง แต่ถึงอย่างนั้น ก็ยังคิดว่าโปรเจ็กต์ส่วนใหญ่ในลิสต์นั้น ถ้าทำวันละแค่ 2–3 ชั่วโมง ก็ไม่ได้จบในไม่กี่วันแน่ ๆ แค่การรีเสิร์ชก่อนเริ่มก็ใช้เวลาพอสมควรแล้ว ยกตัวอย่าง ไม่นานมานี้ฉันเปลี่ยนบล็อก Pelican ของตัวเองมาเป็น Odin static site generator ส่วนตัว ใช้เวลา 2 สัปดาห์ ทั้งที่ลงวันละแค่ 2–3 ชั่วโมงเอง และนั่นยังนับว่าเป็นโปรเจ็กต์ที่ง่ายกว่าหลายรายการในลิสต์นั้นด้วยซ้ำ

  • โปรเจ็กต์ของคุณเกินกว่าจะเรียกว่า “toy” แล้ว คุณเป็นลูกค้าตัวจริงของตัวเอง คาดหวังว่าหลัง deploy แล้วมันต้องทำงานได้ดี และความคาดหวังนั้นแหละคือเส้นแบ่งระหว่างของเล่นกับเครื่องมือจริง ๆ จะทำ word processor ให้เสร็จภายในหนึ่งชั่วโมงก็ยังได้ อาจเป็นเวอร์ชันที่แค่รับอินพุตทีละตัว เรียบง่ายแบบสุด ๆ ไม่มีแม้แต่ปุ่มปิด แต่แค่นั้นก็พอจะเป็น “toy” word processor ได้แล้ว
  • ถ้าตีความระยะเวลา “X วัน” ว่าเป็น 24*X ชั่วโมง รายการนี้ก็เริ่มดูสมเหตุสมผลขึ้น
  • ข้อดีอย่างหนึ่งของ toy project คือมันไม่มี deadline เพราะงั้นจะค่อย ๆ ทำแบบสบาย ๆ ก็ได้ ฉันเองก็ยังคงขัดเกลาภาษาแบบ PEG-based ที่ Turing-complete อยู่เลย ตั้งแต่ช่วงโควิดจนถึงตอนนี้
  • เวลาที่ต่างกันมากแบบนี้ขึ้นอยู่กับว่าคุณใช้ไลบรารีจากภายนอกมากแค่ไหน แก้ปัญหาเองถึงระดับไหน และโฟกัสเฉพาะแก่นหลักจริง ๆ มากเพียงใด ถ้าดู GitHub ของผู้เขียน (https://github.com/ssloy?tab=repositories) จะได้เรียนรู้เทคนิคมากมายในการควบคุมขนาดงานให้เล็ก และผู้เขียนเองก็มีความเข้าใจโดเมนปัญหาอย่างลึกอยู่แล้ว จึงเขียนได้กระชับขนาดนั้น ถ้าเป็นหัวข้อใหม่คงทำแบบนี้ได้ยาก

• ฉันก็เห็นด้วยกับคำแนะนำที่ว่า “อย่าใช้ LLM กับโปรเจ็กต์แบบนี้” แต่ก็ไม่อยากให้ตีความแบบสุดโต่งเกินไป สิ่งที่น่าสนใจคือคำแนะนำเรื่องการรับความช่วยเหลือจาก AI ว่าควรทำอย่างไร ทำไมมันถึงให้ความรู้สึกต่างจากการขอความช่วยเหลือจากคน ถ้าตรงท้ายบล็อกเขียนว่า “ถ้าคุณมีเพื่อนที่เขียนโปรแกรมเก่ง อย่าไปขอความช่วยเหลือเด็ดขาด” มันก็คงฟังแปลก เพื่อนผู้เชี่ยวชาญเข้าใจบริบท และช่วยเราให้แก้ปัญหาได้ด้วยตัวเอง ฉันว่าแทบไม่มีใครเคยลองขอ AI แบบจริงจังว่า “อย่าแก้ปัญหาแทนฉัน แต่ช่วยชี้แนะเหมือนเพื่อนผู้เชี่ยวชาญ” แน่นอนว่าตอนนี้มันอาจยังทำไม่ได้ดีหรือทำได้ไม่ครบ แต่ในอีก 1–2 ปี วิธีแนะนำแบบนั้นอาจกลายเป็นเรื่องธรรมดามากก็ได้ เพราะงั้นการฝึกนิสัย “บอกให้ชัดว่าเราอยากได้ความช่วยเหลือแบบไหน” น่าจะเป็นเรื่องดี ไม่จำเป็นต้องมีอคติว่าต่อให้ทำอย่างไร LLM ก็จะให้แต่คำตอบผิด ๆ เท่านั้น

  • ฉันรู้สึกชัดเจนว่า AI ยังไม่ใช่นักพัฒนาผู้เชี่ยวชาญ
  • การใช้ LLM เหมือนเพื่อนผู้เชี่ยวชาญเป็นวิธีที่ฉันใช้บ่อยที่สุด ถ้าอยากให้เชื่อถือได้ ก็ต้องปรับพรอมป์หรือคำถามให้ไม่ชี้นำเกินไป ช่วงหลังรู้สึกว่า Claude กับ ChatGPT มีแนวโน้มจะเห็นด้วยกับสิ่งที่ฉันคิดมากเกินไป
  • (ผู้เขียน) จริง ๆ แล้วฉันถึงขั้นแนะนำว่า “อย่าขอความช่วยเหลือแม้แต่จากเพื่อนผู้เชี่ยวชาญ” เว้นแต่จะตันจริง ๆ ถึงค่อยไปอ่านเอกสารสั้น ๆ ที่เกี่ยวกับหัวข้อนั้น ฉันเชื่อมากว่าการลองผิดลองถูกเองหลายวิธี ล้มลุกคลุกคลานแก้ปัญหาด้วยตัวเอง เป็นองค์ประกอบสำคัญในการพัฒนาความคิดสร้างสรรค์และทักษะแก้ปัญหา ช่วงเวลาที่สับสนเป็นสิ่งจำเป็นจริง ๆ แต่แน่นอนว่าแต่ละคนต้องตัดสินใจเอง
  • ฉันถาม LLM ราวกับเป็น “ครู” จริง ๆ ไม่ได้ถามให้ตอบเหมือน intern

• ต้องขอบคุณ vibe coding ที่ขับเคลื่อนด้วย Claude ทำให้ได้เริ่ม side project สนุก ๆ อีกครั้งหลังจากห่างหายไปนาน พอคุ้นกับเครื่องมือและกระบวนการแล้ว ช่วงไม่กี่สัปดาห์มานี้ก็ทำแอปได้อย่างรวดเร็วหลายตัว ทั้งแดชบอร์ดปฏิทิน/อากาศสำหรับครอบครัว แอปอ่าน Bluesky ที่ซ่อนโพสต์ที่อ่านแล้ว แดชบอร์ด PM ในบริษัทแบบ gamified Chrome extension ที่ซ่อนโพสต์ Reddit หลังเวลาที่กำหนด และแอปทดแทน WordPress plugin ที่ไม่มีคนดูแลแล้ว ช่วงแรกฉันโยนเรื่องต่าง ๆ เช่นการปรับปรุง UI ให้ Claude ทำเยอะมาก แต่ตอนนี้เริ่มเรียนรู้ที่จะพอใจกับความสมบูรณ์ราว 90% และหันไปโฟกัสที่ฟีเจอร์ของแอปใหม่แทนการขัดเกลาให้สุด

  • บางครั้ง Claude แก้บั๊กเสร็จแล้วแต่ไม่ยอมแสดงผลลัพธ์ที่อัปเดตให้ดูทันที เลยทำให้หงุดหงิด เคยมีครั้งหนึ่งที่ต้องขอผลลัพธ์หลังแก้ไขใหม่ถึง 6 รอบสำหรับการแก้แค่เรื่องเดียว ไม่รู้ว่ามีใครเจอเหมือนกันไหม

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

  • (ผู้เขียน) นั่นแหละคือสิ่งที่ฉันเรียกว่า “การเรียนรู้บางประเภท” ในเนื้อหาหลัก เช่น ถ้าอยากเรียนรู้โครงสร้างของ ELF binary คุณไม่มีทางเดาเอาเองได้ ต้องรู้ประวัติหรือกระบวนการตัดสินใจ จึงต้องใช้สเปก เอกสาร หรือแหล่งอ้างอิงรวมถึง LLM แต่สิ่งที่สำคัญในระดับพื้นฐานคือ “constructive learning จากการลองสร้างเอง” กระบวนการสำรวจ ล้มลุกคลุกคลานระหว่างที่ลองออกแบบ binary format เองต่างหาก ที่ทำให้เข้าใจเหตุผล ปัญหา และ design space ทั้งหมดของฟอร์แมตจริงอย่าง ELF ฉันแนะนำว่าอย่าใช้ LLM ในการเรียนรู้เชิงสำรวจแบบนี้ “ถ้ามีแค่โน้ตบุ๊ก text editor และ compiler แล้วปล่อยไว้ 10 ปี เราจะสร้างอะไรได้ถึงไหน? แล้วจะติดตรงไหนที่ต้องไปหาข้อมูลเฉพาะ?”

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

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