The Stoic Programmer: เขียนโค้ดอย่างไรให้ใจไม่พัง

Share
The Stoic Programmer: เขียนโค้ดอย่างไรให้ใจไม่พัง
Photo by Tyler Lastovich on Unsplash

ในมหานครที่ฉาบด้วยแสงนีออนและความโกลาหลของข้อมูล เหล่าโปรแกรมเมอร์มักจะติดอยู่ในวงจรของการพยายามควบคุมสิ่งที่ควบคุมไม่ได้ เราภาวนาให้ Network ไม่ล่ม เราอ้อนวอนให้ User ใส่ Input ที่ถูกต้อง และเราเจ็บปวดเมื่อระบบ panic! พังทลายลงต่อหน้า

แต่นักคิดสโตอิก (Stoic) เมื่อสองพันปีก่อนไม่ได้สอนให้เราอ้อนวอน พวกเขาสอนให้เราสร้าง “ป้อมปราการภายใน” (Inner Citadel) ขึ้นมา เพื่อเผชิญหน้ากับโลกที่พร้อมจะพังทลายใส่เราทุกเมื่อ

1. แยกแยะสิ่งที่ควบคุมได้และไม่ได้ (Dichotomy of Control)

แก่นของสโตอิกคือการยอมรับความจริงอันโหดร้ายว่า เราควบคุมสิ่งภายนอกไม่ได้เลย

  • สิ่งที่ควบคุมไม่ได้: 3rd party services อาจจะล่ม หรือแม้แต่พฤติกรรมที่คาดเดาไม่ได้ของผู้ใช้งาน
  • สิ่งที่ควบคุมได้: โครงสร้างของ Logic, การออกแบบระบบ Error Handling, และที่สำคัญที่สุดคือ “ปฏิกิริยา” ของเราต่อปัญหา

เมื่อคุณเขียน Rust คุณกำลังฝึกฝนวิถีสโตอิก เพราะ Rust ไม่ยอมให้คุณเพิกเฉยต่อความไม่แน่นอน

2. Error Handling: การยอมรับความจริงผ่าน Result และ Option

ในภาษาอื่น Error อาจเป็นเรื่องน่าตกใจ แต่ใน Rust… Error คือเรื่องธรรมดา การใช้ Result<T, E> คือการประกาศว่า "ฉันรู้ว่างานนี้อาจจะล้มเหลว"

แทนที่จะปล่อยให้โปรแกรมระเบิดตัวเองด้วย Exception เราใช้ match เพื่อแกะความจริงออกมาดูทีละชั้น หากมันคือ Ok(data)เราก็ก้าวต่อไป หากมันคือ Err(e) เราก็รับมือมันด้วยความสงบนิ่ง นี่คือการมีสติ (Mindfulness) ในรูปแบบของโค้ด

3. Immutability: ความนิ่งสงบในโลกที่แปรปรวน

ในยุคที่เราถูกรุมเร้าด้วยสถานะที่เปลี่ยนแปลงตลอดเวลา (Mutable State) ความสงบมักหายไปได้ง่ายๆ Rust จึงมอบพลังของ Immutability มาเป็นค่าเริ่มต้น

เมื่อคุณกำหนดให้ข้อมูลเป็น Immutable คุณกำลังสร้างความมั่นคง (Certainty) ขึ้นมาท่ามกลางความโกลาหล ข้อมูลนั้นจะไม่ถูกเปลี่ยนโดยมือมืดที่เราควบคุมไม่ได้จาก Thread อื่น มันคือการรักษา “จุดยืนที่มั่นคง” ของระบบให้ยังคงอยู่แม้พายุแห่งข้อมูลจะโหมกระหน่ำ

บทสรุป

การเป็น The Stoic Programmer ไม่ใช่แค่เรื่องของการจัดการหน่วยความจำ หรือการเขียนโค้ดให้ปลอดภัย แต่คือการเข้าใจว่า บั๊กและข้อผิดพลาดเป็นส่วนหนึ่งของวิถีชีวิต

พันธกิจของ Software Engineer ไม่ใช่เพียงการพยายามสร้างระบบที่สมบูรณ์แบบจนไม่มีวันเกิดข้อผิดพลาด แต่คือการออกแบบระบบให้มีความ Resilience หรือความสามารถในการรับมือกับความไม่แน่นอนได้อย่างชาญฉลาด เพื่อให้ธุรกิจดำเนินต่อไปได้อย่างราบรื่นแม้ในสภาวะวิกฤต ซึ่งทัศนคติที่มั่นคงของผู้ออกแบบนี้เอง คือหัวใจสำคัญของการสร้างเทคโนโลยีที่ยั่งยืน

Uncle Quin
Bit Crafter / Philosopher of the Void


หากบทความนี้มีประโยชน์

คุณสามารถติดตาม Late Night with Uncle Quin ได้ทาง

ที่ที่เราคุยกันเรื่อง software, engineering mindset และอนาคตของ developer

แบบไม่ต้องใส่สูท

แต่ใส่ความจริงของวงการเข้าไปเต็ม ๆ

Read more

Distributed Decision Making

Distributed Decision Making

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

By Chokchai Phatharamalai
Risk Management: The Hard Test

Risk Management: The Hard Test

ท้ายหนังสือ Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency ของ Tom DeMarco ได้ให้เทคนิคใหม่ในการจัดการความเสี่ยงกับผม ทอมสอนว่าในการทำงานยุคปัจจุบัน งานมีความเสี่ยงกระจายอยู่เต็มไปหมด ซึ่งในความเสี่ยงนั้น เรามีโอกาสโชคดีและมีโอกาสโชคร้าย การจัดการความเสี่ยงเป็นสิ

By Chokchai Phatharamalai
วิธีปรับเวลาการนอน

วิธีปรับเวลาการนอน

ผมเดินทางกลับมาจาก Conference ของ Berkeley ที่ซานฟรานซิสโก เครื่องลงที่สนามบินสุวรรณภูมิประมาณ 22:30 น. กว่าจะถึงบ้านก็เกือบเที่ยงคืน ยังดีที่ขากลับไม่เหนื่อยเท่าขาไป เพราะลองซื้อหมอนรองคอจาก Duty Free ที่ซานฟรานซิสโกมาใช้ดู หมอนเป็นลายการ์ตูน มีรูปสะพาน

By Chokchai Phatharamalai
เร็วแค่ไหนก็ไร้ค่า ถ้าไปผิดทาง

เร็วแค่ไหนก็ไร้ค่า ถ้าไปผิดทาง

อีกบทเรียนที่ผมได้จากหนังสือ Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency ของ Tom DeMarco คือ ทำไมองค์กรใหญ่ ๆ ถึงยึดมั่นกับ Efficiency กันนัก Efficiency คืออะไร? Efficiency แปลว่า "ประสิทธิภาพ" ยกตัวอย่างเช่น

By Chokchai Phatharamalai