เขียนซอฟต์แวร์ "ไร้ประโยชน์" ให้มากขึ้น

 (ntietz.com)
3 คะแนน โดย GN⁺ 2023-10-19 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ซอฟต์แวร์ไร้ประโยชน์ คือการเล่นเพื่อทวงคืนความสนุกของการคอมพิวติ้งให้หลุดพ้นจากแรงกดดันในการสร้างผลลัพธ์ที่ใช้งานได้จริง และ Hurl เองก็เป็นการทดลองที่เริ่มจาก “มุกตลก”
  • คนสายเทคนิคมักอยู่ในสภาพแวดล้อมที่ต้องสร้างผลลัพธ์ที่มีประโยชน์อยู่เสมอ จน ประกายแห่งความสนุก ที่ทำให้เริ่มเขียนโปรแกรมอาจค่อย ๆ อ่อนลง
  • ในโปรเจ็กต์ที่ทำเพื่อความสนุก เราเป็นคนกำหนดเองทั้งการทดสอบ ตัวติดตามปัญหา และเกณฑ์ความเสร็จ และจะหยุดเมื่อไรก็ได้ถ้าเรียนรู้พอแล้วหรือหมดสนุก
  • เชสเอนจิน, คีย์-แวลูสโตร์ที่ทำ Redis API บางส่วน, ยูทิลิตี Wake-on-LAN, งานภาพเชิงภาพข้อมูลหมากรุก, และฐานข้อมูลหมากรุก ล้วนเป็นการทดลองเพื่อเรียนรู้ GUI·ระบบ·เครือข่าย·โครงสร้างภายในฐานข้อมูล
  • การใช้คอมพิวเตอร์อย่างจริงจังน้อยลงและลองสร้างสิ่งที่ “ดูไร้ประโยชน์” เป็นวิธีที่ทำได้จริงในการได้ทั้งความรู้และความสนุก

อิสรภาพที่ความ “ไร้ประโยชน์” มอบให้

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

โปรเจ็กต์ที่ทำขึ้นมาเพื่อเล่น

  • เชสเอนจินและ UI สุดห่วย มีบั๊กเยอะมาก แต่ก็เป็นจุดเริ่มให้เข้าใจ การเขียนโปรแกรม GUI, การเขียนเกม และวิธีทำงานของเชสเอนจินได้ลึกขึ้น
  • คีย์-แวลูสโตร์ ถูกใช้เพื่อเรียนรู้ การเขียนโปรแกรมระบบ และวิธีเขียนโค้ดให้มีประสิทธิภาพมากขึ้น ระหว่างทำ Redis API บางส่วน
  • ยูทิลิตี Wake-on-LAN เป็นโปรเจ็กต์เพื่อทำความเข้าใจว่า WOL ทำงานอย่างไร และเพื่อฝึกการเขียนโปรแกรมเครือข่ายด้วย Rust
  • งานภาพเชิงภาพข้อมูลหมากรุก ทำให้ได้ทดลองสร้างงานศิลปะด้วยโค้ดและหาวิธีแสดงภาพเกมโปรดของตัวเอง
  • ฐานข้อมูลหมากรุก ทำให้ได้เรียนรู้มากเกี่ยวกับ บิตแมป และโครงสร้างภายในของฐานข้อมูล
  • ยังเคยสร้างเครื่องมือบน LLM ที่คอย “mansplain” ว่าคำสั่งแต่ละคำสั่งทำอะไร
  • การทำโปรโตคอลฝั่งเซิร์ฟเวอร์ของ POP3 ยังไม่เสร็จ แต่ก็สนุกกับการเรียนรู้โปรโตคอลและจินตนาการว่าแอปที่ใช้ POP3 จะหน้าตาเป็นอย่างไร
  • การลองทำ “Crafting Interpreters” ตามด้วย Rust ทำให้ได้เรียนรู้เรื่องอินเทอร์พรีเตอร์และคอมไพเลอร์อย่างมาก โดยเป้าหมายไม่ใช่การทำให้เสร็จ แต่คือความสนุกระหว่างทาง
  • “Mazes for Programmers” ทำไปได้ราวครึ่งทางด้วย Rust ก่อนจะกลายเป็นงานเสียเองจึงหยุด และก็ไม่อยากทำต่อแล้ว
  • สคริปต์เล็ก ๆ อีกหลายตัวก็ถูกเขียนขึ้นเพื่อเล่นกับไอเดียและแนวคิดต่าง ๆ และทดลองสิ่งใหม่ ๆ
  • Hurl เองก็เป็นการเล่นในรูปแบบหนึ่ง และต่อให้ไม่เกิดประโยชน์ใช้งาน ก็ยังสนุกกับการได้เรียนรู้และสร้างบางสิ่งขึ้นมาได้

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

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

 
GN⁺ 2023-10-19
ความคิดเห็นจาก Hacker News

  • ชอบสร้างซอฟต์แวร์ไร้ประโยชน์ แค่ของที่ทำปีนี้ก็มี uncolouring book ที่ https://lines.potato.horse, MeatGPT ที่ https://meat-gpt.sonnet.io, Medieval Content Farm ที่ https://tidings.potato.horse, You deserve butter ที่ https://butter.sonnet.io, Mrr ที่ https://mrr.sonnet.io และ Mrr ที่ถูกต้องตามฟิสิกส์ที่ https://mrrr.sonnet.io
    บางชิ้นในนั้นจริง ๆ แล้วใกล้เคียงกับบทความบล็อกที่ทำอย่างประณีตมากกว่า และเป็นงานที่ทำเกินจำเป็น เพราะการเล่นและแสดงออกด้วยโค้ดนั้นง่ายกว่าการแก้ปัญหาจริง ๆ รายการที่ยาวกว่านี้อยู่ที่ https://sonnet.io./projects

    • ของไร้ประโยชน์ที่ชอบที่สุดคือ https://sc.rollc.at รู้สึกเหมือนในที่สุดก็พบการใช้งานที่ทำให้ infinite scroll ดูมีเหตุผลได้เสียที
    • https://meat-gpt.sonnet.io เป็นสิ่งที่ตลกที่สุดอย่างหนึ่งที่ได้เห็นบนอินเทอร์เน็ตมานาน เป็นของดีสุด ๆ
    • ได้แรงบันดาลใจจากโปรเจกต์เหล่านี้และลิงก์อื่น ๆ ในบทความ เลยสร้างบัญชี Scratch แล้วลองทำนาฬิกาอนาล็อก: https://scratch.mit.edu/projects/910890145
      ลูกอายุ 8 ขวบเล่น Scratch ทุกวัน และมักช่วยเวลามีคำถาม การทำโปรเจกต์เพี้ยน ๆ ที่ใส่แอนิเมชันไร้สาระเข้าไปเพียงเพื่อความสนุกนั้นสนุกทีเดียว ต้องขอบคุณเรื่องนี้ ตอนนี้ที่บ้าน “Hurry to love! Hurry to love!” กลายเป็นวลีฮิตไปแล้ว
    • ได้แรงบันดาลใจจากบทความ เลยทำรายการของตัวเอง: https://untested.sonnet.io/Here's+a+List+of+Toys
      จริง ๆ แล้วลืมของในนั้นไปเยอะมากทีเดียว
    • ขอหมายเหตุว่า ลิงก์ mrrr แบบ triple-r ดูเหมือนจะใช้งานไม่ได้

  • เห็นด้วยสุด ๆ ช่วงหลังได้ไปโรงเรียนตัวตลกมา แล้วตระหนักว่าตัวเองหมกมุ่นกับการทำโปรเจกต์ให้ “ถูกต้อง” หรือ “ดี” มากเกินไป
    ชีวิตคือสิ่งที่ต้องใช้ชีวิต และถ้าพยายามทำซอฟต์แวร์ให้ “ถูกต้อง” เกินไป ก็จะบีบความสนุกออกไปหมด ดังนั้นช่วงนี้จึงพยายามเขียนโค้ดให้สนุกขึ้น แล้วก็พบว่าเขียนโค้ดได้มากขึ้นมาก และมันไหลลื่นขึ้นด้วย ช่วงหลังได้ทำไลบรารี binary serialization สไตล์ protobuf เองเพื่อทดลองไอเดียเรื่อง schema evolution และตอนนี้กำลังทำฐานข้อมูล local-first บนพื้นฐาน CRDT เมื่อวานนี้ซิงก์ข้อมูลครั้งแรกได้แล้ว ตื่นเต้นมาก หลายปีมานี้เขียนโค้ดเพื่อแก้ Serious Problems ไว้เยอะ และก็เขียนโค้ดตามแรงกระตุ้นไว้มากเช่นกัน แต่ที่น่าขันคือ โค้ดที่ภูมิใจที่สุดกลับเป็นสิ่งที่ทำเพื่อความสนุก โปรเจกต์สนุก ๆ ทำให้กลับมาดูแลและปรับปรุงต่อเรื่อย ๆ แต่โปรเจกต์จริงจังมักเหี่ยวเฉาตายเมื่อฉันจากไป

    • แนวคิด min/maxing ในเกมดูเหมือนจะใช้ได้กับด้านอื่น ๆ ของชีวิตด้วย
      ในเกม แทนที่จะปล่อยตัวไปตาม flow และเชื่อในกระบวนการ ผู้คนเริ่มอ่านไกด์เพื่อสร้างตัวละครที่แข็งแกร่งที่สุด ปั้นค่าสเตตัสให้สุด และตั้งเป้าเคลียร์ 100% สุดท้ายความสนุกจากการสำรวจและการพบเจอโดยบังเอิญที่เคยทำให้เกมดีหายไป กลายเป็นการใช้เวลาเพื่อทำค่าสเตตัสให้สูงสุดเหมือนสุ่มทอยลูกเต๋า กิจกรรมอื่น ๆ ก็คล้ายกัน ไม่ว่าจะเป็นความมั่งคั่งหรือคุณภาพโค้ด ระหว่างที่พยายามเพิ่มอะไรบางอย่างให้สูงสุด ความรู้สึกพิศวงและการ “แค่ลองทำดู” ก็หายไป
    • สมัยก่อนเคยสนุกกับฟิสิกส์ เหตุผลที่สนุกก็เพราะได้เล่นกับฟิสิกส์ ไม่ได้ทำตามว่าสำคัญต่อความก้าวหน้าของฟิสิกส์นิวเคลียร์แค่ไหน แต่ทำสิ่งที่อยากทำตามว่ามันน่าสนใจและสนุกให้ได้เล่นหรือไม่
      https://www.asc.ohio-state.edu/kilcup.1/262/feynman.html
    • ยินดีด้วยที่เข้า Princeton ได้
    • รู้สึกแบบเดียวกันตอนเล่น Factorio ตอนแรกสร้างโรงงานสปาเกตตีกับเพื่อน และรีแฟกเตอร์ไปเรื่อย ๆ ทุกครั้งที่ข้อกำหนดเปลี่ยน ซึ่งสนุกมาก
      แต่พอจมอยู่กับการ optimize อยู่ ๆ เกมก็กลายเป็นเกมที่มีคำตอบถูกเพียงคำตอบเดียว และความสนุกทั้งหมดก็หายไปในชั่วข้ามคืน หลายครั้งเราเรียนรู้ได้มากกว่าตอนที่ทำอะไรแย่ ๆ ด้วยความโอหังและตามอารมณ์ ความคิดว่า “มันจะยากสักแค่ไหนเชียว?” ทำให้หลายครั้งลงไปลึกเกินกว่าจะรับมือไหว แต่ในกระบวนการปีนกลับขึ้นมา ก็ได้เรียนรู้อย่างมหาศาลและพบความสนุกเสมอ
    • การที่ทุกคนตีความคำว่า “โรงเรียนตัวตลก” ว่าเป็นโรงเรียนตัวตลกจริง ๆ หรือไม่ก็หนึ่งในมหาวิทยาลัย Ivy League นั้นบอกอะไรได้มาก

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

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

  • นี่ไม่ใช่แค่เรื่องชวนให้เขียนซอฟต์แวร์ที่ “ไร้ประโยชน์” เท่านั้น แต่ยังเป็นข้อเสนอว่าในโปรเจกต์เล็ก ๆ ควรหลีกเลี่ยงสิ่งที่เรียกว่า best practices ด้วย
    ผมทำ static site generator สำหรับแคตตาล็อกสินค้า ซึ่งแคตตาล็อกนั้นเรียบง่ายและไม่ได้เปลี่ยนบ่อย พอคิดว่าจะใช้ฐานข้อมูลอะไรดี สุดท้ายก็ตัดสินใจใส่ทุกอย่างไว้ใน static array ใน codebase ไปเลย dependency ที่ต้องคิดถึงลดลงไปหนึ่งอย่าง และมันก็เหมาะกับเป้าหมายของผมอย่างสมบูรณ์แบบ

    • ถือว่ารู้ตัวค่อนข้างเร็ว ประมาณปี 1998 เคยมีโปรเจกต์ที่ใช้ Oracle เป็น content repository “เพราะมันมีอยู่ตรงนั้น” แล้วพอตรวจสอบประสิทธิภาพก็สรุปว่า “เราปล่อยซอฟต์แวร์ใหม่บ่อยกว่าที่เปลี่ยนข้อมูลเสียอีก ดังนั้นควรคอมไพล์มันเข้าไปในผลิตภัณฑ์ตั้งแต่แรก”
      ไม่รู้ว่าในทางปฏิบัติเปลี่ยนเป็นแบบนั้นจริงไหม แต่หลังจากนั้น ทุกครั้งที่มีคนพูดว่า “ต้องมีฐานข้อมูล” นี่กลายเป็นคำถามแรกที่ผมถามเสมอ
    • แนวทางที่เหมาะสม ชนะ best practices เสมอ
    • ผมไม่คิดว่า “ไม่ใช้ฐานข้อมูล” เป็น best practice หรอก best practice น่าจะใกล้เคียงกับการใช้ เครื่องมือที่ดีที่สุดให้เหมาะกับงาน มากกว่า วิธีที่อธิบายมานั้นเข้ากับตัวอย่างนี้ได้ดี
    • ในโปรเจกต์งานอดิเรก ผมตัดสินใจแบบเดียวกัน เวอร์ชันปัจจุบันแทบจะเป็นแค่การ query dataset อย่างเดียว ไม่ได้สร้าง/ลบ/แก้ไข
      ไหน ๆ ก็ต้องโหลดข้อมูลทั้งหมดเข้า memory เพื่อรัน graph algorithms อยู่แล้ว ผมเลยตระหนักว่าการเก็บข้อมูล read-only ไว้ในฐานข้อมูลแทบไม่มีความหมายเลย ผมไม่มีความคิดจะ implement Bellman-Ford ด้วย SQL แม้แต่น้อย
    • เพื่อนคนหนึ่งที่รู้จักเอาทุกอย่างที่เรียนรู้ไปใส่ใน โปรเจกต์โอเพนซอร์ส ของตัวเอง ตอนแรกมันเป็น showcase ของ best practices และตอนนี้โปรเจกต์เหล่านั้นก็ค่อนข้างได้รับความนิยมมาก

  • ผมได้เรียนรู้เรื่องนี้ตอนเขียนโค้ดกับเพื่อนที่เคยคิดว่าเป็น coder ห่วย ๆ คนหนึ่ง
    เราสนิทกัน เลยทำโปรเจกต์สนุก ๆ ด้วยกันหลายอย่าง แต่เขาดูเหมือนไม่รู้จริง ๆ ว่ากำลังทำอะไรอยู่ copy/paste ไปทั่ว ไม่มี architecture ไม่มี design ตั้งชื่อแย่ ๆ และครึ่งหนึ่งเหมือนเขาเองก็ไม่มั่นใจว่าโค้ดทำอะไรจริง ๆ กันแน่ แต่ถึงอย่างนั้นมัน ทำงานได้ สุดท้ายผมก็ตระหนักว่าเขาทำอะไรได้มากกว่าผม เขาไม่ไปยึดติดกับเรื่องเล็ก ๆ น้อย ๆ และลงมือทำมากกว่ามาก เขาไม่ได้เขียน unit test แต่เล่นกับผลลัพธ์เหมือนเด็กเล่นของเล่น แล้วทดสอบเองด้วยมือไปเรื่อย ๆ ในที่สุดผมก็ยอมรับแนวคิดนั้น ผมหาซอฟต์แวร์จัดการรายชื่อผู้ติดต่อที่ทำฟีเจอร์ตามต้องการไม่ได้ เลยคิดจะทำเอง แต่แทนที่จะพยายามทำ UI ให้เนี้ยบ ผมใช้ django-admin แล้วจบ ผมใช้ชุดฟอร์มอันน่ากลัวนั้นมา 10 ปีแล้ว และมันก็ทำงานของมันได้ ตอนที่ยังไม่มี CLI สำหรับ TOTP ผมก็ทำด้วย Python แล้ว dump seed เป็น TOML แบบ plain text ใช้เวลา 5 ปีกว่าจะเพิ่มการเข้ารหัส เพราะแค่ทำ symbolic link ไฟล์จาก Veracrypt container ก็พอแล้วและงานก็น้อยกว่า สองเดือนก่อน ผมอยากได้ timer ที่ถ้าออกกำลังกายแล้วจะเติมงบเวลา และถ้าเล่นวิดีโอเกมแล้วจะใช้มัน ก็เลยทำขึ้นมา (https://substackcdn.com/image/fetch/w_1456,c_limit,f_webp,q_...) ผมเอาก้อน Tailwind ที่ ChatGPT คายออกมา มาต่อเข้าด้วย HTMX แล้วมันก็พอแล้ว พอเอาให้เพื่อนดู มี 4 คนขอบัญชี และอีกคนขอทดลองใช้สำหรับแพทย์ในโปรแกรมบำบัดการเสพติด ไม่มีแม้แต่ฟอร์มสมัครสมาชิก ผมก็ hardcode เอา อยากบอกตัวเองตอนยังหนุ่มว่าให้เลิกหมกมุ่นกับการทำสิ่งต่าง ๆ ให้ถูกต้อง หรือทำเฉพาะปัญหาที่สำคัญได้แล้ว ยังไงทั้งชีวิตผมก็ไม่เคยไปถึง “ความถูกต้อง” นั้นจริง ๆ อยู่ดี

    • เมื่อหลายปีก่อน ผมตระหนักว่าถ้าพยายามทำสิ่งอย่างชื่อโปรเจกต์ให้ถูกต้องตั้งแต่แรก ส่วนใหญ่จะล้มเหลว
      หลังจากเริ่มปล่อยให้ชื่อที่ IDE ตั้งให้ค้างไว้อย่างนั้นจนกว่าจะพิสูจน์ได้ว่าโปรเจกต์นั้นน่าสนใจ อัตราความสำเร็จก็ดูเหมือนจะสูงขึ้น น่าจะเกี่ยวกับหลักการพื้นฐานเดียวกัน
    • ซอฟต์แวร์ควรถูกทุบ ๆ ประกอบ ๆ ให้เข้าที่ก่อน แล้วค่อยจัดระเบียบทีหลัง เมื่อรู้แล้วว่าต้องการอะไรและจำเป็นต้องมีอะไร
      โดยเฉพาะเวลาจัดระเบียบโค้ดของคนอื่น มันมีตรรกะแปลก ๆ อยู่ ด่าไปว่า “ตอนนั้นคิดอะไรอยู่เนี่ย?” แต่ในขณะเดียวกันก็มีข้อเท็จจริงว่าเขาเป็นคนที่ทำให้มัน เริ่มเดินหน้า ได้ก่อน
    • เคยมีคนหนึ่งที่สร้างแรงบันดาลใจให้ผม นิสัยแย่มาก และโค้ดที่ได้เห็นทีหลังก็แย่มาก
      แต่เขาหาเงินได้ชั่วโมงละ 100 ดอลลาร์ในประเทศที่ค่าแรงต่ำ เขาซื้อโดเมนกับคอนเทนต์มาทำซอฟต์แวร์ใหม่ ทำอะไรอย่าง search engine optimization แล้วขายต่อใน 3 เดือนด้วยราคา 10 เท่าของราคาที่ซื้อมา กำไรประมาณ 7,000 ดอลลาร์จากงาน 3 เดือนก็ไม่เลว และน่าจะไม่ใช่งานเต็มเวลาด้วยซ้ำ
    • ผมเคยมีประสบการณ์คล้ายกัน แต่ข้อสรุปกลับต่างกันโดยสิ้นเชิง เคยทำงานกับคนที่โยน ๆ แปะ ๆ แบบนั้น และก็เห็นบ่อยว่ามันติดกำแพงได้จริง
      แต่ข้อสรุปของผมคือ หนึ่ง มันล้มเหลวบ่อยพอ ๆ กับที่สำเร็จ และคาดเดาไม่ได้ว่าจะออกฝั่งไหน แถมการแก้ทีหลังยากกว่าการไม่ทำแบบนั้นตั้งแต่แรก จึงดูเหมือนการพนันที่ค่าคาดหวังติดลบ สอง โดยส่วนตัวผมไม่ชอบทำงานแบบนั้น สาม ดังนั้นผมจึงไม่อยากใช้เวลาไปกับงานที่วิธีแบบนั้นอาจจะดูเข้าท่าได้ ประสบการณ์นี้ทำให้ผมหันไปหาโปรเจกต์ที่ลึกและใหญ่กว่า แทนที่จะเป็นงานเล็ก ๆ จุกจิกต่อเนื่องกัน แต่ตอนนี้ผมยอมรับได้สบายใจกว่ามากว่าคนอื่นอาจมีความชอบต่างจากผม ผมคิดถึงวิธีที่เหมาะกับตัวเองมากกว่าวิธีที่ถูกต้องในการสร้างซอฟต์แวร์
    • ตอนนี้ผมกำลังทำแบบนั้นอยู่พอดี กำลังทำแอป “ไร้ประโยชน์” สนุก ๆ ด้วยเทคโนโลยีที่ไม่ค่อยรู้จัก โดยเขียนโค้ดขยะที่โง่ที่สุดและ maintain ไม่ได้ที่สุด
      แต่ถึงอย่างนั้นมันก็ทำงานได้ แม้จะหนักหน่อย แต่ก็ productive และผมได้เรียนรู้อะไรมากในกระบวนการนี้ ผมรู้วิธีจัดระเบียบ ขัดเกลา และทำให้ maintain กับ scale ได้ในภายหลัง ดังนั้นจะทำหลังจากมีอะไรบางอย่างที่ทำงานได้จริงแล้ว โดยเฉพาะเวลาลองของใหม่ แนวทางนี้เคย productive พอสมควรในอดีต ผมจึงสนับสนุนเต็มที่

  • Apple เคยปฏิเสธแอปของผมด้วยเหตุผลว่าแอปของผม ไร้ประโยชน์ ทีมรีวิวแอปโทรมาบอกเองเลยว่าแอปนี้ไร้ประโยชน์และจะไม่ได้รับอนุมัติให้ขึ้น Mac App Store
    ราว 12 ปีต่อมา แอปเล็ก ๆ ไร้ประโยชน์ตัวนั้นที่ชื่อ KeyboardCleanTool มีคนใช้หลายพันคน มันเป็นแอปฟรีขนาดจิ๋วที่บล็อกทั้งอินพุตจากคีย์บอร์ดและ Touch Bar แต่ผู้คนเอาไปใช้ในแบบที่ผมไม่เคยนึกถึง เช่น ปล่อยให้เด็กเล็กทุบคีย์บอร์ดได้ตามใจ หรือปล่อยให้แมวนอนบนแล็ปท็อป อะไรที่มีประโยชน์นั้นเป็นเรื่องอัตวิสัยจริง ๆ

    • ผมจำเป็นต้องทำความสะอาดคีย์บอร์ด เลยค้นหาวิธีทำความสะอาดคีย์บอร์ด MacBook แล้วแอปนั้นก็โผล่ขึ้นมาตลอด ตอนแรกก็หัวเราะผ่าน ๆ ว่า “แอปจะทำความสะอาดคีย์บอร์ดได้ยังไง เขย่าหลอก ๆ แล้วทำให้สะอาดเหรอ?”
      หลังจากค้นหาอีกประมาณสิบครั้ง ผมถึงเข้าใจเมื่อเห็นบทความเกี่ยวกับวิธีดี ๆ ในการทำความสะอาดคีย์บอร์ดแนะนำแอปนั้น เพราะมันล็อกคีย์บอร์ดได้ สุดท้ายก็เลยดาวน์โหลดมา และสำหรับแอปที่ว่า “ไร้ประโยชน์” มันกลับมีประโยชน์ทีเดียว
    • รู้จักแอปนั้นอยู่ ดูค่อนข้างยอดเยี่ยมเลย
      ตอนเด็ก ๆ แม่ผมเคยเผลอเปิด Mac IIsi ของเราระหว่างทำความสะอาด และผมใช้เรื่องนั้นเป็นข้ออ้างโน้มน้าวได้สำเร็จว่าเราต้องมีสกรีนเซฟเวอร์ After Dark ไม่นานนักก็มีเครื่องปิ้งขนมปังบินไปมาบนหน้าจอ ชวนให้นึกถึงอดีตจริง ๆ
    • ผมใช้ KeyboardCleanTool มาหลายปีแล้ว และมันเป็นแรงบันดาลใจให้เพิ่มฟีเจอร์คล้าย ๆ กันชื่อ Cleaning Mode ในแอป Lunar: https://lunar.fyi/shortcuts#cleaning-mode
      เวลาทำความสะอาด หน้าจอ MacBook และมอนิเตอร์ต้องดำสนิทเพื่อให้เห็นฝุ่นที่อาจขูดให้เกิดรอยได้ และต้องปิดการทำงานของแทร็กแพดด้วย คีย์ลัดสำหรับปิดโหมดทำความสะอาดต้องเป็นแบบที่กดโดนโดยบังเอิญได้ยากแต่จำง่าย ผมเลยกำหนดให้กดปุ่ม Command รัวอย่างน้อย 8 ครั้ง แนวทางการรีวิวแอปของ Apple น่าหงุดหงิดเสมอ ไม่เข้าใจว่าทำไมถึงพยายามตัดสินแทนผู้ใช้ว่าอะไรมีประโยชน์ ยังไม่ต้องพูดถึงแอปหลอกลวงที่ผ่านการรีวิวแล้วอยู่รอดใน App Store ได้เป็นเดือน ๆ
    • ทุกครั้งที่มีคนปกป้อง สวนมีกำแพงล้อม ของ Apple ผมอยากเก็บคอมเมนต์นี้ไว้เลย

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

    • เหมือนหลายสิ่งในชีวิต ถ้าผัดผ่อนไปจนกว่า “จะพอรับไหว” ก็มีโอกาสสูงว่าจะไม่มีวันได้มันเลย

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

  • เมื่อนานมาแล้วผมเคยจัดกลุ่มชื่อ Houston Recreational Computer Programming Group เป็นกลุ่มที่แทบทั้งหมดมีไว้โชว์โปรเจกต์ซอฟต์แวร์ไร้ประโยชน์และสนุก ๆ และมันสนุกมาก
    ตอนนี้ผมย้ายไปแล้ว และไม่แน่ใจว่าเมืองที่อยู่ตอนนี้ใหญ่พอจะตั้งกลุ่มแบบนั้นหรือไม่ หรือผมยังมีพลังจะกลับไปจัดอีกไหม สิ่งที่ผมชอบเป็นการส่วนตัวคือเดือนละครั้งผมต้องทำโปรเจกต์เล็ก ๆ ไว้โชว์ เผื่อไม่มีใครเอาอะไรมา ตลอดราว 2 ปีมีเหตุการณ์แบบนั้นเกิดขึ้นแค่ไม่กี่ครั้ง แต่หนึ่งในนั้น[1] ออกมาค่อนข้างเจ๋ง และผมภูมิใจกับมัน มันก็ไม่ได้ไร้ประโยชน์โดยสิ้นเชิง [1] https://github.com/smcameron/gaseous-giganticus

    • ด้วยการมีส่วนช่วยสร้างวัฒนธรรมของ TX/RX labs ที่นั่นจึงเติบโตได้ดีมากในเวลาต่อมา

  • ผมเพิ่งทำซอฟต์แวร์ไร้ประโยชน์เสร็จเมื่อไม่กี่นาทีก่อน บทความนี้เลยมาถูกจังหวะมาก
    CFR Brackets: https://susam.net/cfr.html
    Demo: https://susam.net/cfr.html#3
    Source: https://github.com/susam/cfr
    มันเป็น ภาษาเขียนภาพ ขนาดเล็กมากที่รองรับเพียง 5 คำสั่ง ได้แก่ C(เปลี่ยนสี), F(เคลื่อนที่ไปข้างหน้า), R(หมุน), (เริ่มบล็อก), คำสั่งได้รับแรงบันดาลใจเล็กน้อยจากภาษาโปรแกรม Logo และความมินิมัลได้รับแรงบันดาลใจจาก P′′ แต่ต่างจากทั้งสองอย่าง มันไม่ใช่ Turing complete ไม่ได้ตั้งใจให้มีการใช้งานเชิงปฏิบัติ ทำขึ้นเพื่อความสนุก ผมตั้งใจจะเล่นกับมันต่อ โดยพยายามวาดรูปทรงที่น่าสนใจพร้อมรักษาโค้ดอินพุตให้เล็กที่สุด “ผมคิดว่าการรักษาความสนุกของการคำนวณไว้ในวิทยาการคอมพิวเตอร์นั้นสำคัญอย่างยิ่ง” — Alan J. Perlis