เครื่องมือที่ดีนั้นมองไม่เห็น
(gingerbill.org)- เครื่องมือที่ดีคือ เครื่องมือที่เลือนหายไปเป็นฉากหลัง ระหว่างที่ผู้ใช้จดจ่อกับงาน และเป้าหมายของผู้สร้างเครื่องมือก็คือการทำให้ผู้ใช้ไม่ต้องนึกถึงตัวเครื่องมือเอง
- หากห่อหุ้มข้อบกพร่องของเครื่องมือให้เป็น “ปริศนาที่สนุก” ก็ง่ายที่จะเข้าใจผิดว่า ความรู้สึกว่าตัวเองฉลาด คือผลิตภาพจริง
- การเลือกเอดิเตอร์อย่าง vim, emacs, Sublime อาจเข้ากับเวิร์กโฟลว์ส่วนตัวได้ แต่หากปกป้องแม้กระทั่งข้อบกพร่องราวกับเป็น สัญญาณบ่งบอกตัวตน ก็จะทำให้มองข้อดีข้อเสียอย่างตรงไปตรงมาได้ยาก
- แม้ในการถกเถียงเรื่อง TUI กับ GUI ก็ไม่ควรมองข้อขาดตกบกพร่องของการใช้งานจริงในปัจจุบันว่าเป็นข้อจำกัดโดยเนื้อแท้ของหมวดหมู่นั้นเอง เพราะปัญหามากมายเกิดจากการไม่มี การ implement ที่ดี
- ค่าเริ่มต้นที่ดีคือการออกแบบที่ช่วยประหยัดเวลาผู้ใช้ ส่วนความสามารถในการตั้งค่าสูงหรือ learning curve ที่ชันนั้นคุ้มค่าจะยอมรับก็ต่อเมื่อชดเชยกลับมาด้วยผลิตภาพจริงเท่านั้น
เกณฑ์ของเครื่องมือที่ดี
- เครื่องมือที่ดีควร มองไม่เห็น
- เมื่อผู้ใช้ทำงานต่อไปได้โดยไม่ต้องนึกถึงตัวเครื่องมือเอง เครื่องมือนั้นก็เลือนหายไปเป็นฉากหลัง
- ทันทีที่เครื่องมือถ่วงงานบางอย่างไว้ ผู้ใช้ก็จะกลับมารู้สึกถึงตัวเครื่องมืออีกครั้ง
- ท่าทีที่นำข้อบกพร่องมาห่อใหม่เป็น “ปริศนาที่สนุก” ทำให้การประเมินเครื่องมือพร่ามัว
- ความสนุกจากการหาทางอ้อมไม่ได้พิสูจน์คุณภาพของเครื่องมือ
- การสนุกกับข้อบกพร่องเหมือนเป็นงานอดิเรก กับการที่เครื่องมือนั้นดีจริง เป็นคนละเรื่องกัน
การถกเถียงเรื่อง text editor
- vim เป็นเพียงตัวอย่าง และตรรกะเดียวกันนี้ใช้ได้กับเอดิเตอร์อื่นอย่าง emacs หรือ Sublime ด้วย
- ผู้ใช้บางคนยกย่องกระบวนการแก้จุดด้อยของ vim เหมือนเป็น ปริศนาที่สนุก มากกว่าข้อดีของมัน
- มีกรณีที่การสร้าง macro เพื่อ refactor ข้อความแบบครั้งเดียวถูกมองว่าสนุก
- หากงานเดียวกันสามารถทำให้เสร็จในไม่ถึง 1 นาทีด้วย multiple cursor ของ Sublime หรือแก้ด้วยสคริปต์ง่าย ๆ ได้ งาน macro ก็จะอ่อนลงเมื่อวัดด้วยเกณฑ์ผลิตภาพจริง
- เอดิเตอร์สำคัญต่อเวิร์กโฟลว์ แต่ท่าทีที่ติดตามเอดิเตอร์ใดเอดิเตอร์หนึ่งแทบจะเหมือนศาสนาเพราะ “กลิ่นอายแฮกเกอร์” นั้นอันตราย
- บรรยากาศแบบนี้อาจดึงดูดคนที่เพิ่งได้ลอง vim หรือ emacs
- ความคุ้นเคยอาจบดบังข้อบกพร่อง และทำให้โอ้อวดข้อบกพร่องนั้นเหมือนเป็นเกม
เหตุผลที่ใช้ Sublime และข้อจำกัดที่ยอมรับ
- Sublime เป็นเอดิเตอร์ที่ใช้มา 15 ปี และเหตุผลที่เลือกสรุปได้เป็นไม่กี่ข้อ
- คีย์ลัดใกล้เคียงกับ superset ของสภาพแวดล้อม graphical OS ทำให้ ต้นทุนการสลับบริบททางความคิด ต่ำเมื่อต้องย้ายไปมาระหว่างแอป
- multiple cursor ถูกมองว่าดีกว่า macro ใน 99.999% ของกรณี
- multiple cursor ให้ feedback ทางสายตาโดยตรง
- มี “ปริศนา” ที่ต้องแก้น้อยที่สุดในเวิร์กโฟลว์การแก้ไขข้อความ
- Sublime ก็ยังมีข้อบกพร่อง
- บางครั้งไม่มีเครื่องมือที่ต้องการ จึงต้องใช้ปลั๊กอินหรือใช้โปรแกรมแยกต่างหากเพื่อแปลงข้อความ
- ไม่ห่อหุ้มข้อบกพร่องเหล่านี้ให้เป็น “ปริศนาที่สนุก” แต่ยอมรับว่าเป็นความไม่สะดวกตรง ๆ
- vim อาจดีกว่าสำหรับการแก้ไขพื้นฐาน แต่ในงานปริมาณมากที่ไม่ใช่งานตระกูล grep มองว่าอ่อนกว่า
- ไม่รู้สึกว่า vim motion ให้ผลิตภาพมากกว่าเวิร์กโฟลว์ของ Sublime อย่างชัดเจน
- เนื่องจากแทบไม่ได้เขียนโค้ดใน terminal จึงแทบไม่จำเป็นต้องใช้เอดิเตอร์ที่เน้น terminal
เมื่อเครื่องมือกลายเป็นตัวตน
- การเลือกเครื่องมืออาจทำหน้าที่เหมือนธงที่แสดงว่าตนเป็นคนแบบไหน
- “กลิ่นอายแฮกเกอร์” อาจไม่ได้เป็นเพียงสุนทรียะ แต่กลายเป็น สัญญาณของเผ่ากลุ่ม ด้วย
- เมื่ออัตลักษณ์ถูกผูกกับเครื่องมือ การยอมรับข้อบกพร่องจะรู้สึกเหมือนปฏิเสธตัวเอง
- ดังนั้นจึงไม่ใช่แค่อดทนกับข้อบกพร่อง แต่ยังปกป้องและโอ้อวดมัน
- เป็นเรื่องยากที่จะคุยอย่างตรงไปตรงมาเรื่องเครื่องมือกับคนที่ทำให้เครื่องมือกลายเป็นส่วนหนึ่งของบุคลิกภาพ
ความรู้สึกว่ามีผลิตภาพกับผลิตภาพจริง
- กรณี macro ของเอดิเตอร์แสดงให้เห็นความต่างระหว่าง ความรู้สึกว่ามีผลิตภาพ กับผลิตภาพจริง
- ความรู้สึกว่าตัวเองฉลาดที่เกิดขึ้นเมื่อแก้ปัญหายาก ๆ มักถูกสับสนกับผลลัพธ์จริงได้ง่าย
- เครื่องมือที่ทำให้งานยากรู้สึกเป็นวีรกรรม และทำให้ความฉลาดรู้สึกเหมือนความสำเร็จ อาจดูทรงพลัง
- ขณะเดียวกัน ความเร็วในการทำงานจริงอาจช้าอย่างเงียบ ๆ
- เกณฑ์ที่ซื่อตรงไม่ใช่ความลื่นไหลหรือความฉลาด แต่คือ เวลาที่ใช้ และจำนวนข้อผิดพลาด
- เครื่องมือที่หลายคนแนะนำอย่างเผยแพร่ศรัทธาอาจแพ้เมื่อวัดด้วยเกณฑ์นี้
- หากเป้าหมายคือผลิตภาพ ก็ควรสงสัยความเชื่อของตัวเองจริง ๆ และตรวจสอบว่าอะไรให้ผลิตภาพมากกว่า
การถกเถียงเรื่อง TUI กับ GUI
- สำหรับผู้ใช้ที่อยู่ใน terminal ทั้งวัน ข้อดีของแอป terminal นั้นชัดเจน
- แต่โปรแกรมเมอร์ส่วนใหญ่ไม่ได้ถูกขังอยู่ใน terminal ทั้งวัน
- คำวิจารณ์ที่ว่าไม่สามารถนำทางแอป GUI ด้วยคีย์บอร์ดอย่างเดียวได้ ไม่ได้แปลว่า GUI แย่โดยเนื้อแท้
- เพียงแต่ GUI จำนวนมากยังรองรับการนำทางด้วยคีย์บอร์ดไม่เพียงพอ
- ไม่มีอะไรที่เป็นไปไม่ได้โดยเนื้อแท้ในการทำให้ GUI นำทางด้วยคีย์บอร์ดได้
- ผู้สร้างเครื่องมือจำนวนมากไม่ได้ implement สิ่งนี้ หรือไม่ตระหนักว่ามีหลายกรณีที่การนำทางด้วยคีย์บอร์ดให้ผลิตภาพมากกว่าการใช้เมาส์บ่อย ๆ
- การเปรียบเทียบว่าแอป TUI บางตัวดีกว่าทางเลือก GUI บางตัวเป็นเรื่องที่สมเหตุสมผลได้
- แต่การตัดสินว่า TUI ดีกว่า GUI โดยเนื้อแท้ ใกล้เคียงกับข้อผิดพลาดที่เข้าใจข้อจำกัดของการ implement ปัจจุบันผิดว่าเป็น ข้อจำกัดโดยเนื้อแท้
Linux desktop กับความสนุกของการตั้งค่า
- แม้ในปี 2026 “ปีของ Linux desktop” ก็ยังไม่มาถึง
- เหตุผลหนึ่งคือผู้ใช้ Linux จำนวนมากชอบการแก้ไฟล์ตั้งค่าและปรับเปลี่ยนระบบเหมือนเป็น ปริศนาที่สนุก
- แม้เคยผ่านช่วงแบบนั้นด้วยตัวเอง แต่เมื่อเวลาผ่านไปก็จะอยากได้เครื่องมือที่ใช้งานได้ดีเฉย ๆ
- การตั้งค่าเป็นชั่วโมงหรือเป็นวันไม่ใช่สิ่งที่ต้องการอีกต่อไป
- ค่าเริ่มต้นควรดีและใช้งานได้ทันที
- เมื่อต้องปรับเล็กน้อย ก็ควรเสร็จภายในไม่กี่วินาที
- ความสามารถในการตั้งค่าสูงสุดไม่ควรเป็นเป้าหมายของเครื่องมือ แต่ควรเป็นทางเลือกที่ใช้เมื่อจำเป็นจริง ๆ
- การออกแบบเครื่องมือที่ถูกหลักสรีรศาสตร์คือการให้ทั้งค่าเริ่มต้นที่ดีและทางออกเมื่อจำเป็น
ค่าเริ่มต้นที่ดีและความรับผิดชอบของผู้สร้างเครื่องมือ
- ค่าเริ่มต้นที่ดี คือความรับผิดชอบของผู้สร้างเครื่องมือ
- ผู้สร้างเครื่องมือมักผลักภาระด้านการตั้งค่า การปรับแต่ง และการเรียนรู้ให้ผู้ใช้ได้ง่าย
- ภาระจำนวนมากเป็นผลจากการที่ผู้ออกแบบหลีกเลี่ยงการตัดสินใจ
- “ความสามารถในการตั้งค่าสูง” อาจเป็นข้ออ้างที่โยนปัญหาให้ผู้ใช้โดยไม่มีจุดยืนใด ๆ
- ค่าเริ่มต้นที่ดีคือการเคารพเวลาของผู้ใช้
- หากผู้สร้างเครื่องมือคิดให้ครั้งเดียว ผู้ใช้จำนวนมหาศาลก็ไม่ต้องคิดเรื่องเดียวกันซ้ำ ๆ
- ทางออกมีไว้สำหรับคนส่วนน้อยจริง ๆ ที่มีความต้องการเฉพาะ
- ไม่ควรนำมาแทนที่การทำกรณีทั่วไปให้ดี
learning curve ที่ชันไม่ใช่ฟีเจอร์
- มีการปกป้องว่า ความยากของเครื่องมือบางอย่างคือหัวใจสำคัญ
- ตามตรรกะนี้ มันคัดกรองคนที่ไม่ทุ่มเท และเมื่อผ่านจุดยากไปแล้วก็จะได้รับผลตอบแทนไปตลอดชีวิต
- learning curve คือ ต้นทุน ไม่ใช่คุณธรรม
- ต้นทุนนั้นอาจคุ้มค่าได้ แต่ผลตอบแทนต้องเป็นผลิตภาพจริง
- ความพึงพอใจที่ได้จ่ายต้นทุนไปแล้วไม่ควรกลายเป็นผลตอบแทนในตัวเอง
- ตรรกะว่า “เรียนมาหลายเดือนแล้วจึงต้องมีคุณค่า และคนอื่นก็ควรทำตาม” คือการห่อหุ้มต้นทุนจมให้ดูเหมือนความสามารถ
- ณ จุดนี้ ปริศนาไม่ได้เป็นงานที่ทำด้วยเครื่องมือ แต่กลายเป็น ตัวเครื่องมือเอง
ท่าทีที่สำคัญกว่าการเลือกเครื่องมือ
- นี่ไม่ใช่ข้อโต้แย้งเพื่อต่อต้านเครื่องมือใดเครื่องมือหนึ่ง แต่เป็นคำวิจารณ์ต่อวิธีคิดที่มีต่อเครื่องมือ
- จะใช้ vim, emacs หรือ Sublime อะไรก็ได้
- เกณฑ์คือเครื่องมือนั้นเลือนหายไปเป็นฉากหลังและช่วยให้ผู้ใช้ทำงานต่อไปได้หรือไม่
- เกณฑ์นี้เป็นเกณฑ์ส่วนบุคคล
- ปัญหาคือเรื่องเล่าที่เกาะอยู่รอบการเลือกเครื่องมือ
- นำข้อจำกัดมาห่อใหม่ให้เป็นฟีเจอร์
- ขายความพยายามในการอ้อมผ่านข้อบกพร่องให้เหมือนเป็นรางวัล
- ยกระดับเครื่องมือจาก “สิ่งที่ใช้” ไปเป็น “ส่วนหนึ่งของตัวตน”
- สัญญาณที่ชัดที่สุดว่าเครื่องมือกำลังรับใช้ได้อย่างถูกต้อง คือภาวะที่ผู้ใช้ไม่รู้สึกตัวว่ากำลังใช้เครื่องมือนั้นอยู่
- เครื่องมือที่ดีที่สุดไม่ใช่เครื่องมือที่มีเรื่องเล่าดีที่สุด แต่เป็นเครื่องมือที่ทำให้ผู้ใช้ลืมไปว่าตนกำลังใช้งานมันอยู่
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
หลังจากได้ออกแบบ เครื่องมือภายใน สำหรับทีมพัฒนามาค่อนข้างมาก ผมเห็นด้วยจริง ๆ
เมื่อก่อนผมคิดว่าเพราะผู้ใช้เป็นนักพัฒนา การเปิด “โครงสร้างภายใน” ไว้น่าจะดีกว่า แต่ในทางปฏิบัติกลับเป็นแค่การสร้างอุปสรรคให้เพื่อนร่วมทีมทำงานหลักของตัวเอง
เพื่อนร่วมทีมใช้เครื่องมือที่ผมสร้างขึ้นเพื่อทำงานที่บริษัทต้องการ ไม่ได้อยากมานั่งงัดแงะเครื่องมือเล็ก ๆ ที่ที่อื่นแทบไม่มีโอกาสได้ใช้ และก็ไม่มีเหตุผลที่ต้องทำแบบนั้นด้วย
ตอนนี้ผมยังคงเหลือทางออกไว้เยอะ แต่พยายามออกแบบเครื่องมือภายในให้ผู้ใช้ตกลงไปใน หลุมแห่งความสำเร็จ ได้อย่างเป็นธรรมชาติ
และข้อความผิดพลาด ข้อความผิดพลาด ข้อความผิดพลาด รวมถึงคำแนะนำอัตโนมัติสำหรับข้อผิดพลาดที่พบบ่อยนั้นสำคัญมาก
ผมยังผิดหวังที่มีคนจำนวนมากยึดติดกับตัวอย่างในบทความ โดยไม่ดูเจตนาของบทความ
ถ้ามันช่วยให้ผู้ใช้ทำสิ่งที่เขาให้ความสำคัญโดยตรง ความสามารถในการตั้งค่าก็มีคุณค่ามาก แต่ถ้าเป็นเครื่องมือที่ช่วยจัดการปัญหาที่ผู้ใช้ให้ความสำคัญน้อยกว่า มันอาจกลายเป็นสิ่งรบกวนได้
ตัวอย่างเช่น วิธีที่ Gusto จัดการเงินเดือน ภาษี และการยื่นแบบฟอร์มแทนนั้นดีจริง ๆ เพราะแทบไม่ต้องคิดหรือแตะต้องอะไรเลย
แต่สำหรับคนที่งานหลักคือเงินเดือน บัญชี หรือภาษี หรือคนที่ทำงานในฝ่าย HR กฎหมาย หรือการเงินขององค์กรขนาดใหญ่ การทำให้เรียบง่ายแบบนั้นอาจเป็นโทษได้ เพราะต้องสู้กับเครื่องมือ หรือพูดแบบอ่อนลงคือทำให้งานของตัวเองถูกทำให้เรียบง่ายเกินไป
อีกเรื่องใหญ่คือใครเป็นคนจ่ายเงินจริง ๆ และเครื่องมือนั้นมี วัตถุประสงค์เชิงป้องกัน อย่างการตรวจสอบย้อนหลังได้ ความปลอดภัย การจำกัดพฤติกรรมที่ไม่พึงประสงค์ หรือเป็นวัตถุประสงค์เชิงสร้างสรรค์กันแน่ ฟีเจอร์เชิงสร้างสรรค์น่าดึงดูดกว่า แต่ประเมินเป็นตัวเลขได้ยาก และผู้ใช้ปลายทางก็มักไม่อยากจ่ายเงินก้อนใหญ่เท่ากับระดับที่มันช่วยบทบาทของตน
คือมีค่าเริ่มต้นที่สมเหตุสมผล และให้ปรับแต่งได้เมื่อจำเป็น ควรเริ่มจากกรณี 80% และถ้าต้องการก็ให้เปลี่ยนได้ โดยต้องเป็นตัวเลือก
โดยเฉพาะในเครื่องมือสำหรับนักพัฒนา มักมีแนวโน้มลังเลที่จะใส่ความคิดเห็นเชิงออกแบบที่ชัดเจนลงไป ถ้าไม่มั่นใจว่าตัวเลือกใด “ถูกเสมอ” การถามผู้ใช้ก็ดูปลอดภัยกว่า และนักพัฒนาก็ค่อนข้างจู้จี้กับเรื่องพวกนี้
ถ้าคิดว่า “95% น่าจะต้องการวิธีนี้ แต่ 5% ก็มีเหตุผลของเขา งั้นทำให้ทุกคนเท่า ๆ กันดีกว่า” ผลลัพธ์คือเครื่องมือที่แย่ลงสำหรับผู้ใช้ส่วนใหญ่
การรองรับการปรับแต่งซับซ้อนกว่าที่คิดมาก ไม่ใช่แค่เรื่องบั๊กเท่านั้น แต่ทุกตัวเลือกทำให้การ ขัดเกลาประสบการณ์ผู้ใช้ ยากขึ้น ขอบเขตการทดสอบก็ใหญ่ขึ้น และ abstraction ที่ยืดหยุ่นกว่าก็ออกแบบได้ยากกว่า
แต่ก็ยังมีส่วนที่ต้องหาจุดสมดุลอยู่ นั่นคือการบังคับให้ผู้คนทำตาม วิธีที่ถูกต้อง
มักมีคนบ่นเสมอว่าติดขัดเพราะต้องทำให้ถูกต้อง และพวกเขามักรู้สึกว่ามันเสียเวลา
จากมุมมององค์กร เป้าหมายคือการสร้างเส้นโค้งผลงานที่สูงที่สุดในช่วงที่พนักงานยังทำงานอยู่ และจากมุมมองพนักงานคือการสร้างเส้นโค้งผลงานตลอดทั้งอาชีพ
หลายอย่างขึ้นอยู่กับความสัมพันธ์ของคนที่เกี่ยวข้อง ถ้าคนขนของไปออกกำลังกายเมื่อวันก่อนจนปวดกล้ามเนื้อ สำหรับผมผลลัพธ์คือช้าลงและแย่ลง แต่สำหรับบริษัทขนย้าย ระยะยาวเขาจะแข็งแรงขึ้นและทำงานได้มากขึ้น จึงอาจเป็นเรื่องดี แต่ถ้าวันนั้นเขาลาออกหรือถูกไล่ออก ก็กลับเป็นผลลัพธ์ที่แย่อีก
การประเมินที่แท้จริงไม่ใช่ว่าระหว่างมาโครกับการแก้ไขใน Sublime อะไรดีกว่า แต่คือกระบวนการคิดที่ใช้สร้างมาโครช่วยงานอื่นได้หรือไม่ และก่อนหน้านั้นเขากำลังทำอะไรอยู่
จากประสบการณ์ของผม แทบไม่มีใครที่จะเอาเวลาที่เคยใช้ทำมาโครหรือเรียน Vim ไปใช้กับงานที่มีความหมายจริง ๆ พวกเขามักเบื่อหรือหมดไฟ และแค่อยากคิดถึงอย่างอื่นที่รู้สึกสนุกในตอนนั้น
ปัญหาไม่ใช่ว่าพนักงานใช้สคริปต์สุ่ม ๆ แต่คือพวกเขาไม่มี ความเร่งด่วนหรือความสนใจ ต่อสิ่งที่กำลังทำอยู่
ผลที่อินเทอร์เฟซ “มองไม่เห็น” จริง ๆ แล้วเป็น ฟังก์ชันของเวลา ที่ใช้ไปภายในอินเทอร์เฟซนั้น
สิ่งที่ผู้เขียนกำลังตอบสนองดูเหมือนจะใกล้เคียงกับ แรงเสียดทานตามดุลยพินิจ ที่นักออกแบบหรือผู้จัดการผลิตภัณฑ์เพิ่มฟีเจอร์หรือความซับซ้อนเข้าไป
แต่เพื่อทำงานบางอย่างให้สำเร็จ แรงเสียดทานแบบนั้นอาจจำเป็น ลองนึกถึงสถานการณ์แก้ merge conflict ก็ได้ และถ้าใช้ไปนานพอ แม้แต่ขั้นตอนที่ “รบกวน” เหล่านั้นก็จะจางหายไปเป็นฉากหลัง
พูดให้เป็นรูปธรรม ห้องนักบินของ 737 มีอุปกรณ์ควบคุมแน่นขนัดมาก ตัวเครื่องบินเองก็มีหลายโหมด และมีแรงเสียดทานที่ตั้งใจใส่ไว้มากมาย
แต่ถ้าถามนักบินที่ใช้งาน 737 มานานกว่า 10 ปี เขาน่าจะบอกว่าอินเทอร์เฟซนั้นมองไม่เห็นไปแล้ว
Bloomberg Terminal ที่มักถูกมองว่า “แย่” ก็เช่นกัน ในวงการแพทย์ สำหรับคนที่ใช้ซอฟต์แวร์สแกน MR มากกว่า 8 ชั่วโมงต่อวันและอยากเข้าถึงทุกการควบคุมได้ทันที อินเทอร์เฟซที่เต็มไปด้วยปุ่มอาจเป็นคำตอบที่ถูกต้องพอดี
โปรแกรมเมอร์มีแนวโน้มจะรีบเหมารวมประสบการณ์และความชอบของตัวเองไปใช้กับคนอื่นเร็วเกินไป
ที่มา: เคยออกแบบซอฟต์แวร์สำหรับผู้บริโภคและผู้เชี่ยวชาญที่ IDEO เป็นเวลา 10 ปี
บทความพูดถึงเรื่องนี้จากฝั่งผู้ใช้ โดยมองว่ามีผู้ใช้กลุ่มหนึ่งที่สนุกกับการเรียนรู้ฟีเจอร์ “เพิ่มเติม” ซึ่งมีคุณค่าสูงสุดต่ำกว่าฟีเจอร์หลัก
ประเด็นสำคัญคือส่วนที่ว่า “ถ้าผู้คนใช้ vim, emacs ฯลฯ เพราะรู้สึกว่ามันดีจริงและทำให้มีประสิทธิภาพ ผมจะไม่วิจารณ์ คนเรารู้สึกสบายใจกับสิ่งที่คุ้นเคยที่สุด แต่คนที่ผมพูดถึงคือคนที่เพราะความคุ้นเคยนั้นทำให้มองไม่เห็นข้อบกพร่องของเครื่องมือ แล้วกลับยกย่องข้อบกพร่องเหล่านั้นเหมือนเป็นเกมและเอามาอวดกัน”
ในฐานะคนที่ใช้เทอร์มินัลมานาน จึงไม่ค่อยแปลกใจที่ผู้คนไม่เข้าใจ บทสนทนามักไหลไปแบบนี้
“ในเทอร์มินัลทำโน่นทำนี่ได้ด้วยคำสั่งง่าย ๆ”
“FrobnicatorStudio ของฉันมีคีย์ลัด Ctrl+Alt+So สำหรับสิ่งนั้น”
แล้วก็ลากยาวไปเรื่อย ๆ แบบนี้ กลายเป็นการเปรียบเทียบที่แทบไม่มีความหมายอย่าง “ใน Vim กดสี่ครั้งก็ลบได้ 24 บรรทัด” กับ “Sublime มีหลายเคอร์เซอร์”
ประเด็นที่ถูกต้องน่าจะเป็นว่า เทอร์มินัลครอบคลุมกรณีใช้งานได้แทบไม่สิ้นสุด เพราะมันผสาน เครื่องมือบรรทัดคำสั่ง เล็ก ๆ เข้าด้วยกันเป็น pipeline แต่ก็มี learning curve ที่ต้องใช้เวลาราวหนึ่งปีกว่าจะใช้ได้คล่อง
เมื่อไปถึงจุดนั้น คุณอาจมีผลิตภาพสูงกว่าผู้ใช้ GUI โดยเฉลี่ยมาก แต่การไปถึงตรงนั้นต้องใช้ความทุ่มเทและต้องผ่านความเจ็บปวด และหลายคนก็ไม่ได้เลือกเอง แต่จำเป็นต้องทำ
ในกรณีของผม งานแรกต้องดูแลเซิร์ฟเวอร์ลูกค้าผ่าน ssh และเซิร์ฟเวอร์เหล่านั้นติดตั้งของไว้แค่ขั้นต่ำ หลายครั้งไม่มีแม้แต่ vim มีแค่ vi และไม่มีทางเลือกอื่นนอกจากหาวิธีทำงานให้มีประสิทธิภาพในสภาพแวดล้อมนั้น
ถ้าไม่มีประสบการณ์นั้น ผมก็ไม่แน่ใจว่าจะยอมรับความเจ็บปวดของการเริ่มทำงานในเทอร์มินัลหรือไม่
แต่ถึงจุดหนึ่งก็รู้สึกว่ากำลังเสียเวลากับมันมากเกินไป จึงกลับไปใช้บรรทัดคำสั่งด้วย tshark กับ jq รวมถึง bash/awk/grep เก่า ๆ และ gnuplot ต่อมาผมใช้ Python แต่ก็ยังใช้เอาต์พุตจาก tshark อยู่
ท้ายที่สุดก็ถึงขั้นสร้าง parser สำหรับ pcap และ pcapng, การจัดการ ethernet-ip-udp/tcp และแม้แต่ Java IDE แบบสมบูรณ์ แล้วก็ไม่หันกลับไปอีก
เครื่องมือจับและสำรวจข้อมูลทุกอย่างที่ต้องใช้ซ้ำ ๆ ก็ผ่านเส้นทางคดเคี้ยวแบบเดียวกัน
ผมคิดว่าคงไม่ใช่ผมคนเดียวที่ผ่าน ขั้นตอนวนซ้ำของการปรับปรุงเครื่องมือ แบบนี้ และอยากให้มีสเกลที่ตั้งชื่อดี ๆ ไว้อธิบายมัน
เทอร์มินัลให้พลังมากกว่าอย่างไร้ขีดจำกัด แต่สิ่งที่ทำเป็นประจำจริง ๆ อาจมีประมาณ 20 อย่าง ถ้ามีแค่ 20 อย่างนั้นทั้งหมด learning curve ก็ทำให้โน้มน้าวได้ยาก
เช่น ถ้าอยู่ในเทอร์มินัลและอยากหา build script ก็ทำอะไรอย่าง
cat packages.json | jq .scriptsได้มันมีประโยชน์เมื่ออยู่ในเทอร์มินัล แต่ถ้าอยู่ใน VSCode ก็จบด้วย
ctrl-p -> packages.json -> ctrl-f -> scrและจริง ๆ แล้วจำนวนการกดคีย์ก็น้อยกว่าเวิร์กโฟลว์ของคนเรานั้นเป็นเรื่องเฉพาะตัวมาก ผมจึงไม่บอกให้ใครเปลี่ยน แต่สำหรับผม ผมชอบ เครื่องมือที่เข้าใจโครงสร้างโปรเจกต์ มากกว่าเครื่องมือที่มองโปรเจกต์เป็นแค่ข้อความล้วน ๆ ดังนั้น IDE จึงเหมาะกับผมกว่า
แอปบรรทัดคำสั่งหมายถึงเครื่องมือที่โต้ตอบด้วยการพิมพ์คำสั่งใน shell เช่น grep, sort, cp, git, ls, tar หากรู้วิธีใช้ทั่วไป ก็ใช้ในสคริปต์ได้ และจึงประกอบกันเป็น pipeline ได้
แอป text user interface หมายถึง แอปแบบโต้ตอบ ที่ยึดครองเทอร์มินัลระหว่างใช้งาน เช่น Vim, Emacs, Tmux, Lynx, Tig, Midnight Commander, Claude Code
สิ่งเหล่านี้ไม่ได้ถูกประกอบเป็น pipeline พูดให้แม่นกว่านั้นคือโดยปกติเราไม่ได้เอามันไปใส่ใน pipeline ตามวิธีใช้งานปกติ หากทำได้ ก็น่าจะเป็นเพราะแอปนั้นมี command-line interface แยกจาก TUI
การจะใช้กล่องเครื่องมือชุดเดียวกันแก้ปัญหาทุกอย่างได้ต้องใช้เวลา แต่ท้ายที่สุดมีประสิทธิภาพกว่า
เพียงแต่โน้มน้าวยาก จนกว่าจะได้แก้ปัญหาที่แทบแก้ไม่ได้หากไม่ใช้เครื่องมือบรรทัดคำสั่ง จึงจะเข้าใจความเรียบง่ายของมันได้ไม่ง่ายนัก
ถึงอย่างนั้นก็ยังใช้บรรทัดคำสั่งเยอะในทุกงาน ปกติมักเปิดหน้าต่าง konsole ไว้ และถ้าต้อง build หรือ test ก็ alt+tab ไปที่นั่นแทนการใช้การรองรับ “build system” ของ Sublime
ใช้ Vim เฉพาะตอนต้อง ssh หรือใช้ Termux บนโทรศัพท์เท่านั้น
เครื่องมือ GUI ที่ขยายได้อย่าง Sublime, VSCode ฯลฯ ก็ครอบคลุมกรณีใช้งานได้ไม่สิ้นสุดเช่นกัน และกลับให้สภาพแวดล้อมการรันที่เสถียรและทำซ้ำได้มากกว่า
เหตุที่การถกเถียงแบบนี้ไม่จบเสียที ผมคิดว่าเพราะโดยทั่วไปผู้คนมีกรอบความคิดคับแคบ ยากที่จะยืนในมุมของคนอื่น และยิ่งยากกว่าที่จะยอมรับอย่างจริงจังว่าตัวเองอาจผิด
สุดท้ายประเด็นนี้สำคัญเฉพาะกับมือใหม่เท่านั้น เมื่อคุ้นเคยพอแล้ว ไม่ว่าจะใช้อะไร คอขวดของผลิตภาพก็ไม่ใช่เครื่องมืออีกต่อไป แน่นอนว่า ed อาจเป็นข้อยกเว้น
ต่อคำกล่าวที่ว่า “คนไม่รู้ว่าการนำทางด้วยคีย์บอร์ดมีผลิตภาพสูงกว่าการเอื้อมจับเมาส์บ่อย ๆ มาก” คนจำนวนไม่น้อยที่บอกว่าตัวเองมีผลิตภาพสูงกว่านั้นจริง ๆ แล้วไม่เคยวัดเลย
ตลอดหลายปีมีการแข่งขัน การนำทางด้วยคีย์บอร์ดเทียบกับเมาส์ อยู่มาก และขึ้นอยู่กับรายละเอียดการออกแบบการทดสอบ บางครั้งฝั่งหนึ่งชนะ บางครั้งอีกฝั่งชนะ และหลายครั้งความต่างก็มากพอสมควร
ไม่ใช่น้อยที่วิธีที่ผู้ใช้บอกว่าทำให้ตนมีผลิตภาพสูงกว่านั้นแพ้เมื่อได้เห็นผลลัพธ์จริง
ผมไม่ได้อยากไล่ตามตัวชี้วัดผลิตภาพแบบสัมบูรณ์ แต่อยากได้ สภาพแวดล้อมที่ไม่ทำลาย flow
สำหรับหลายคน การเอื้อมไปจับเมาส์ทำให้ flow ขาดและรู้สึกฝืน และมักแย่กว่าการช้าลง 1 วินาที เพราะมันดึงให้ออกจากบริบทที่อยู่ในหัว
ในกรณีของผม การใช้เมาส์ขณะทำงานเป็นเรื่องเป็นธรรมชาติ ดังนั้นการเปลี่ยนเวิร์กโฟลว์ให้ใช้คีย์บอร์ดนำทางทุกอย่าง จึงเป็นการลงแรงเพิ่มมหาศาลเพียงเพราะบางสถานการณ์อาจประหยัดเวลาได้นิดเดียว
ในเครื่องมืออย่าง word processor, IDE, file manager ซึ่งงานหลักคืออ่าน พิมพ์ แล้วประมวลผลสิ่งที่อ่านและพิมพ์ เมื่อผู้ใช้เรียนรู้คีย์ลัดแล้ว ก็สามารถแสดงให้เห็นได้ว่าการนำทางด้วยคีย์บอร์ดเร็วกว่าและเป็นธรรมชาติกว่า
ในทางกลับกัน สำหรับเครื่องมือที่มีข้อมูลภาพที่ไม่ใช่ข้อความเป็นศูนย์กลาง การถกเถียงคีย์บอร์ดกับเมาส์จะเอียงไปทางเมาส์มากกว่า
ถึงอย่างนั้นก็มีจังหวะที่คีย์ลัดที่มีประสิทธิภาพมีประโยชน์กว่าเมนูและไอคอนมาก ลองดูซอฟต์แวร์ CAD หรือ 3D modeling งาน 90% ของผู้ใช้คือจัดการข้อมูลเชิงพื้นที่ที่แสดงผลด้วยภาพ แต่ถ้ารู้คีย์ลัดสำหรับเปลี่ยนเครื่องมือหรือปรับการตั้งค่าเครื่องมือ ก็จะเร็วขึ้นมากและลดความจำเป็นในการคุ้ยเมนูซ้อน ๆ อยู่เรื่อย ๆ
ผมกังวลว่าผู้เขียนอาจสับสนระหว่างความจริงที่ว่าเขาคุ้นเคยกับเครื่องมือของตัวเอง กับหลักฐานว่าเครื่องมือนั้นดีกว่า
ในความเป็นจริง เครื่องมือทุกอย่างล้วนมี trade-off และถ้าผู้ใช้ชอบเครื่องมือ X มากกว่าเครื่องมือ Y ก็มีความเป็นไปได้สูงว่าไม่ใช่เพราะเขาโง่ แต่เพราะเขาใช้ affordance ของเครื่องมือนั้นที่มีแต่ผู้ชำนาญเท่านั้นจะเข้าใจได้ดีกว่า
ถ้าให้เดเวลลอปเปอร์ใช้ vim, emacs, Sublime Text อย่างละ 10 ปี เขาก็คงไม่มั่นใจว่าอะไรดีกว่ากัน อาจมีความชอบส่วนตัว แต่ก็คงอธิบายได้ว่าทำไมคนอื่นถึงชอบเครื่องมืออื่น
ดูเหมือนเป็นข้อถกเถียงที่เกิดจากการไม่เคยให้โอกาสซอฟต์แวร์ที่ไม่คุ้นเคยอย่างจริงจัง
ผมมองว่าเครื่องหมายของคนเก่าที่ผ่านร้อนผ่านหนาวมานาน คือความไม่ไว้วางใจจาง ๆ ต่อซอฟต์แวร์ทุกตัวและคำสัญญาว่าจะปรับปรุงมัน ในระยะยาว ซอฟต์แวร์ทุกอย่างจะลู่เข้าไปสู่ ความธรรมดา
แค่บอกว่าไม่เห็นด้วยกับความคิดที่มองแรงเสียดทานของเครื่องมือเป็นฟีเจอร์
จะเอาประเด็นของเขามาใช้เพื่อแสดงว่า Vim เป็น editor ที่สมบูรณ์แบบสำหรับผมก็ได้ เพราะเวลาผมใช้ Vim มันมองไม่เห็น และส่วนหนึ่งก็เพราะผมได้ปรับ Vim ให้เป็นเครื่องมือแบบที่ผมต้องการ
เขาปรับ Sublime ให้เป็นเครื่องมือที่เขาต้องการแล้ว แต่ประเด็นหลักยังคงเดิม ถ้าคุณกำลังสร้างอะไรสักอย่างให้คนอื่นใช้ การทำให้เครื่องมือนั้น มองไม่เห็น สำหรับผู้ใช้คือคุณสมบัติที่ทรงพลัง
ความธรรมดาหมายถึง “คุณภาพโดยเฉลี่ยหรือโดยทั่วไป”
ตอนสร้างแอป CRUD ตัวถัดไป คุณอาจไม่จำเป็นต้องใช้เทคโนโลยีล้ำสุดล่าสุดที่ไม่ธรรมดาก็ได้
ถ้ายกประโยคที่ผมเขียน ก็เป็นแบบนี้ “สิ่งที่ทำให้ผมงุนงงคือ คนจำนวนมากปฏิบัติกับแรงเสียดทานนั้น—ความพยายามที่จะหลบเลี่ยงข้อจำกัดของเครื่องมือ—เหมือนเป็นส่วนที่ ‘สนุก’ และโปรโมตมันราวกับเป็นหลักฐานว่าเครื่องมือนั้นยอดเยี่ยม”
เรื่องนี้ไม่เกี่ยวกับว่าผมหรือคนอื่นเลือกเครื่องมือใดเพราะอะไร แต่เกี่ยวกับทัศนคติที่ปฏิบัติต่อข้อบกพร่องเป็น สิ่งที่ต้องหลบเลี่ยงเหมือนเกมปริศนา
ผู้ดูแลเครื่องมือที่ดีมักรับรู้สถานการณ์ในแง่ลบกว่าวิธีที่ผู้ใช้มองเครื่องมือจริง ๆ มาก
แยกความแตกต่างระหว่าง “วันนี้มี 10 คนบ่นเรื่องบั๊กหรือฟีเจอร์ที่ขาดไป และ 9990 คนใช้งานได้ไม่มีปัญหา” กับ “วันนี้มี 10 คนบ่น และมีแค่ 90 คนใช้งานได้ไม่มีปัญหา” ได้ยาก แต่ความพยายามที่ต้องใช้เพื่อขยับจากความพึงพอใจของผู้ใช้ 90% ไปเป็น 99.9% นั้นต่างกันมหาศาล
ผมสงสัยอย่างแรงว่านี่เป็นปัจจัยใหญ่ของ ภาวะหมดไฟของผู้ดูแลโอเพนซอร์ส จำนวนมาก
ผู้ใช้ที่ไม่พอใจจะมองเห็นได้ชัดกว่าผู้ใช้ที่พอใจมาก และเมื่อเทียบกับอัตราการเพิ่มขึ้นของผู้ใช้ใหม่ สัดส่วนของผู้ใช้ที่ไม่พอใจซึ่งสร้างรายงานบั๊กและคำขอฟีเจอร์ในปริมาณเท่าเดิมจะลดลง
สุดท้ายผู้ดูแลจะเกิดภาพลวงตาว่า ต่อให้ปรับปรุงแค่ไหน ความรู้สึกต่อคุณภาพโดยรวมก็ไม่เปลี่ยน และแรงจูงใจที่จะทำต่อก็ถูกบั่นทอน
ผมไม่รู้วิธีแก้ที่ดีสำหรับปัญหานี้ คำตอบที่ชัดเจนคือชมให้บ่อยขึ้นเมื่อมันทำงานได้ดี แต่ในความเป็นจริงมันใกล้เคียงกับปัญหาการกระทำร่วมกันที่ไม่ค่อยเกิดขึ้นจริง
ส่วนตัวแล้ว ถ้าอะไรสักอย่างทำงานได้ดี ผมพยายามตั้งใจให้ฟีดแบ็กเชิงบวกอย่างสม่ำเสมอและกระตือรือร้น แต่ถ้าไม่ใช่ทุกคนทำแบบนั้น ก็ยากที่จะสร้างความแตกต่างครั้งใหญ่
นึกถึงคำพูดนี้ขึ้นมา
“เรามักสังเกตเห็นคนที่ก้มหลังวุ่นวายและประจบสอพลออยู่เสมอ และอาจพูดว่า ‘ช่างถ่อมตัวเสียจริง!’ แต่คนที่ถ่อมตัวอย่างแท้จริงจะไม่เป็นที่สังเกต โลกไม่รู้จักเขา”
~ Tito Colliander
ส่วนที่ว่า “สัญญาณที่ชัดเจนที่สุดว่าเครื่องมือรับใช้คุณได้ดี คือคุณไม่รู้สึกตัวถึงมันอีกต่อไป กล่าวคือมันมองไม่เห็น คุณไม่ได้เปลี่ยนข้อบกพร่องให้เป็นงานอดิเรก จึงไม่สรรเสริญข้อบกพร่องนั้น แค่หลบเลี่ยงมันด้วยความรำคาญเล็กน้อย” ดูเหมือนจะ ขึ้นอยู่กับผู้ใช้ มากกว่าขึ้นอยู่กับเครื่องมือ
แน่นอนว่าเครื่องมือต่างกันย่อมดึงดูดผู้ใช้ต่างกัน และคงวัดความสัมพันธ์ที่แน่นแฟ้นได้
อีกอย่าง จุดยืนนี้ยังขาดความสมดุล เครื่องมือไม่มีวันสมบูรณ์แบบ และบางครั้งคุณก็จะตระหนักว่ามันปรับปรุงได้ แล้วต้องชั่งน้ำหนักระหว่างการนำการเปลี่ยนแปลงนั้นไปใช้กับผลกระทบที่มันจะมีต่อนิสัย
ยิ่งใช้นาน การเปลี่ยนแปลงแบบนั้นอาจเล็กลง แต่รูปแบบการใช้งานย่อมวิวัฒน์ไปตลอดชีวิต และเป็นเรื่องธรรมชาติที่เครื่องมือจะเปลี่ยนไปแบบนั้นด้วย
เป็นการตีความที่ค่อนข้างแปลก
แปลกตรงที่ผู้เขียนยึดติดว่า Vim นั้น “มองเห็นได้” แล้วสื่อเป็นนัยว่ามัลติเคอร์เซอร์และฟีเจอร์ของ Sublime ไม่เป็นแบบนั้น การที่เราฝึกจนสมองไม่ต้องคิดอีกต่อไป ไม่ได้แปลว่ามันมองเห็นน้อยลง
มัลติเคอร์เซอร์ไม่ใช่ฟีเจอร์พื้นฐานในเครื่องมือจำนวนมาก และถ้ารวมถึงการใช้งานให้มีประสิทธิภาพด้วย ก็เป็นสิ่งที่ต้องเรียนรู้เหมือนกัน เหมือนกับคีย์ไบน์ดิงของ Vim
ยิ่งไปกว่านั้น Vim ไม่ได้เป็นแค่ตัวเลือก TUI สำหรับผู้ใช้ที่ใช้เทอร์มินัลอย่างเดียว แต่ยังเป็น คีย์ไบน์ดิง ที่คนซึ่งเรียนรู้ให้คีย์บอร์ดเป็นส่วนขยายตามธรรมชาติของร่างกายใช้ เพื่อไม่ต้องสลับไปมาด้วยเมาส์ตลอดเวลา เช่นเดียวกับที่มัลติเคอร์เซอร์อาจเป็นสิ่งแบบนั้นสำหรับผู้ใช้ Sublime มา 15 ปี
“ผมเคยเห็นคนพูดว่าการสร้างมาโครเพื่อจัดการปัญหา refactoring ข้อความแบบใช้ครั้งเดียวนั้น ‘สนุก’ แค่ไหน แต่เมื่อผมเห็นว่าพวกเขาทำอะไรและใช้เวลานานเท่าไร ปฏิกิริยาตรงไปตรงมาของผมคือ แบบนี้ใช้มัลติเคอร์เซอร์ของ Sublime ทำได้ใน 1 นาที หรือไม่ก็เขียนสคริปต์สั้น ๆ ไปเลย”
และ “สิ่งที่ทำให้ผมงงคือ คนจำนวนมากมองแรงเสียดทานนั้น—ความพยายามในการอ้อมข้อจำกัดของเครื่องมือ—ว่าเป็นส่วนที่ ‘สนุก’ และโปรโมตมันราวกับเป็นหลักฐานว่าเครื่องมือนั้นยอดเยี่ยม”
ถ้าใช้มาโครของ Vim ได้อย่างมีประสิทธิภาพก็ดี แต่ถ้าใช้ Vim มาหลายสิบปีแล้วยังใช้ไม่ได้ ก็ไม่ควรโปรโมตว่านั่นคือส่วนที่ “สนุก”
ความรู้สึกที่พบบ่อยที่สุดคือมีช่วงการเรียนรู้ แต่สุดท้ายก็คุ้มค่า
ไม่รู้ว่าหมายถึงอะไร มาโครของ Vim ก็ให้ฟีดแบ็กทางภาพโดยตรงระหว่างที่เขียนเหมือนกัน คืออัดมาโครไปพร้อมกับแก้ไขตามปกติ แล้วค่อยเล่นการแก้ไขนั้นซ้ำภายหลัง
ทางเทคนิคอาจเป็นไปได้ที่จะใช้มาโครโดยไม่เห็นผลแบบเรียลไทม์ต่อข้อความระหว่างเขียน แต่ผมไม่เคยทำแบบนั้น
เพราะสงสัยเลยไปค้นเรื่องมัลติเคอร์เซอร์มา และข้อดีน่าจะอยู่ที่มันเป็นอินเทอร์เฟซเดียวที่อธิบายง่าย ในทางปฏิบัติถ้าจะทดแทนสิ่งนี้ใน Vim ก็คงใช้คำสั่ง Vim หลายคำสั่ง
ผมเห็นด้วยว่าสำหรับงานส่วนใหญ่ที่เหมาะกับมัลติเคอร์เซอร์ มัลติเคอร์เซอร์อาจดีกว่ามาโคร แต่ปกติงานแบบนั้นก็ไม่ได้ใช้มาโครอยู่แล้ว
งานส่วนใหญ่ที่ผมทำด้วยมาโคร ดูเหมือนจะทำด้วยมัลติเคอร์เซอร์ไม่ได้
ถ้ามีตัวอย่างว่า “ในสถานการณ์นี้มัลติเคอร์เซอร์ยอดเยี่ยม และ Vim ไม่มีทางเลือกที่ดี” ก็อยากให้พิสูจน์ว่าผมคิดผิด
แต่นั่นไม่ได้หมายความว่ามัลติเคอร์เซอร์ไม่มีช่วงการเรียนรู้ ยังต้องคิดอยู่ดีว่าจะวางเคอร์เซอร์ในตำแหน่งที่ถูกต้องอย่างไร
ผมเคยใช้คำว่า “มองไม่เห็น” ตอนอธิบาย emacs magit มาก่อน
มันเป็นเลเยอร์บาง ๆ บนเอาต์พุตของ git ที่ปรากฏขึ้น อนุมานพารามิเตอร์จากสถานะ UI แล้วเรียกคำสั่ง git ตามปกติ จากนั้นก็หายไป
เบาและเร็ว สำหรับโปรเจกต์ใหญ่ ๆ อาจจะไม่ใช่แบบนั้น แต่เขาว่ากันว่าเป็นอย่างนั้น