นิ่ง

นิ่ง
Photo by David Tip on Unsplash

น้อง ๆ ที่ทำงานถามกับผมว่า
“ทำไมพี่นิ่งจัง”
“พี่ดูใจเย็น”

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

ผมตอบกลับไปว่า
“รู้จัก Hulk มั้ยล่ะ”

แล้วผมก็ยิ้ม


ใน The Avengers
มีประโยคหนึ่งที่ผมชอบมาก

“That’s my secret, Cap. I’m always angry.”

มันไม่ใช่การ “ระเบิดอารมณ์”
แต่มันคือการ “อยู่กับมันได้ตลอดเวลา”


การเป็นวิศวกรซอฟต์แวร์
โดยเฉพาะในวันที่ระบบกำลังจะพัง
มันไม่ต่างอะไรกับการถือระเบิดเวลาไว้ในมือ

  • ระบบล่ม แต่ลูกค้ากำลังใช้งานอยู่
  • API พัง แต่ dependency อีก 5 ตัวรออยู่
  • log เต็มไปด้วย error แต่ไม่มีใครบอกได้ว่า root cause คืออะไร
  • ทีมเริ่มสื่อสารกันไม่รู้เรื่อง
  • decision ที่ควรชัด กลับเต็มไปด้วยความลังเล

นี่ไม่ใช่แค่ “ปัญหาเทคนิค”
แต่มันคือ “แรงกดดัน” ที่ถาโถมเข้ามาพร้อมกัน


คนส่วนใหญ่พอเจอสถานการณ์แบบนี้
จะมี 2 แบบ

แบบแรก: ตื่นตระหนก
แบบที่สอง: เงียบ… แต่กำลังจะระเบิด

แต่มีอีกแบบหนึ่ง
ที่ไม่ได้ถูกพูดถึงบ่อยนัก

คือ “นิ่ง”


ความนิ่ง ไม่ได้แปลว่า “ไม่รู้สึก”
แต่แปลว่า “ควบคุมสิ่งที่รู้สึกได้”

คุณยังเห็นความพังทั้งหมดเหมือนเดิม
คุณยังรู้ว่ามันแย่แค่ไหน
คุณยังรู้ว่าถ้าพลาดอีกนิด มันจะลุกลาม

แต่คุณ “ไม่ปล่อยให้มันควบคุมคุณ”


ผมไม่ได้ใจเย็นโดยธรรมชาติ

ผมเคย panic
เคยพิมพ์ command ผิดตอน production ล่ม
เคย deploy แก้ bug แล้วทำให้ bug ใหม่หนักกว่าเดิม
เคยเถียงกันในทีมจนหลุดโฟกัสจากปัญหาจริง

แต่พอเจอบ่อยเข้า
คุณจะเริ่มเข้าใจบางอย่าง

ความวุ่นวาย ไม่ได้ต้องการ “คนเก่งที่สุด”
แต่มันต้องการ “คนที่นิ่งที่สุด”

เวลาระบบพัง
สิ่งที่ทีมต้องการ ไม่ใช่คนที่คิดได้ 10 วิธี
แต่คือคนที่เลือก “1 วิธีที่ชัด” แล้วพาทีมไป

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

เวลาทุกอย่างดูควบคุมไม่ได้
สิ่งที่สำคัญที่สุด คือ
“ใครบางคนที่ยังควบคุมตัวเองได้”


ความนิ่ง มันส่งต่อได้

ถ้าคุณนิ่ง
ทีมจะเริ่มนิ่งตาม

ถ้าคุณ panic
panic จะกระจายเร็วกว่า incident อีก


ผมไม่ได้เก่งกว่าใคร
ผมแค่ “ฝึกอยู่กับความโกลาหล” บ่อยพอ

เหมือน Hulk
มันไม่ใช่ว่าเขาไม่โกรธ
เขาแค่ “คุ้นเคยกับมัน”


แต่ความคุ้นเคยแบบนี้
มันไม่ได้เกิดขึ้นเอง

มันถูก “ซ้อม”


ผมได้แนวคิดนี้มาจาก Marcus Aurelius
ที่พูดถึงการเตรียมใจรับสิ่งเลวร้ายล่วงหน้า

ทุกเช้าระหว่างเดินทางไปทำงาน
ผมจะจินตนาการว่า…

  • วันนี้ระบบจะพังตั้งแต่ยังไม่ถึงเที่ยง
  • จะมีคนโยนความผิดใส่กัน
  • จะมีการใส่ร้าย หรือบิดเบือนข้อมูล
  • จะมีคนพยายามหาคนผิด มากกว่าหาสาเหตุ
  • จะมี moment ที่ผม “ถูกเข้าใจผิด” อย่างแรง

ผมไม่ได้แค่คิดเล่น ๆ

ผม “ดันมันไปให้สุด”


ผมปล่อยให้ตัวเองโกรธ
หงุดหงิด
ไม่พอใจ

เหมือนมันเกิดขึ้นจริงตรงหน้า

จนถึงจุดที่รู้สึกว่า
“ถ้าเกิดขึ้นจริง มันก็เลวร้ายชะมัด”

ผมกำหมัดทุกเช้า


แล้วผมก็หยุด

แล้วกลับมาเป็นปกติ


สิ่งที่เปลี่ยนไป
ไม่ใช่โลก

แต่เป็น “ตัวผมเอง”


พอเหตุการณ์จริงเกิดขึ้น

มันไม่ใช่ครั้งแรกอีกต่อไป

ผมเคย “ผ่านมันมาแล้ว”
ในหัวของตัวเอง


นี่แหละคือเหตุผลที่ผมนิ่ง

ไม่ใช่เพราะผมไม่โกรธ
แต่เพราะผม “รู้จักความโกรธดีพอแล้ว”


ผมไม่ได้รอให้สถานการณ์ควบคุมผม
ผม “ซ้อมให้ตัวเองคุมมัน” ไว้ก่อนแล้ว


ทุกระบบที่คุณดูแล
วันหนึ่งมันจะพัง

ทุก architecture ที่คุณภูมิใจ
วันหนึ่งมันจะเผยจุดอ่อน

ทุกทีมที่คุณเชื่อใจ
วันหนึ่งจะสื่อสารกันไม่เข้าใจ

มันหลีกเลี่ยงไม่ได้


สิ่งเดียวที่คุณเลือกได้
คือ ตอนที่มันเกิดขึ้น

คุณจะ “เป็นอะไร”

  • คนที่เติมความวุ่นวายเข้าไป
    หรือ
  • คนที่ทำให้มันนิ่งลง

และบางที
ความนิ่งของคุณ
ไม่ได้เกิดจากความใจเย็น

แต่มาจาก
“ความโกลาหลที่คุณเคยเผชิญมันมาแล้ว — ล่วงหน้า”


“ความเก่ง ทำให้คุณแก้ปัญหาได้”

“แต่ความนิ่ง ทำให้คุณยังเป็นคนที่คนอื่นพึ่งได้ ในวันที่ทุกอย่างพัง”


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

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

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

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

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

Read more

Tuple: ปรัชญาของการปูเสื่อ และศิลปะแห่งการไม่ตั้งชื่อ

Tuple: ปรัชญาของการปูเสื่อ และศิลปะแห่งการไม่ตั้งชื่อ

ในโลกของการเขียนโปรแกรม เรามักถูกสอนให้เป็น “นักจัดระเบียบ” เราสร้างคลาส สร้าง Struct ตั้งชื่อตัวแปรให้สื่อความหมาย (Clean Code) แต่บางครั้ง ความเคร่งครัดที่มากเกินไปอาจกลายเป็นพันธนาการที่ทำให้ Code ของเราอุ้ยอ้ายโดยไม่จำเป็น 1. Naming Fatigue: ภาระของการมีตัวตน ลองนึกภาพคุณได้

By Santi
The Art of Early Return: วินัยแห่งการ “คัดออก” เพื่อสมองที่โล่งกว่าเดิม 10 เท่า

The Art of Early Return: วินัยแห่งการ “คัดออก” เพื่อสมองที่โล่งกว่าเดิม 10 เท่า

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

By Santi
The Logic Trap: เมื่อ “ความถูกต้อง” กลายเป็นอาวุธที่ทำลายทีมซอฟต์แวร์

The Logic Trap: เมื่อ “ความถูกต้อง” กลายเป็นอาวุธที่ทำลายทีมซอฟต์แวร์

ในโลกของการพัฒนาซอฟต์แวร์ เราถูกสอนให้เทิดทูน Logic เป็นพระเจ้า เราใช้เหตุผลในการคัดเลือก Stack, ใช้ความถูกต้องในการทำ Code Review และใช้ตัวเลขในการวาง Roadmap แต่เคยสงสัยไหมครับ? ทั้งที่เราพูดเรื่องที่ “ถูกต้อง” และเป็น “ความจริง” ทุกประการ ทำไมผลลัพธ์ในห้องประชุ

By Santi
Change Management ต้องทำไหมนะ แล้วทำตอนไหน

Change Management ต้องทำไหมนะ แล้วทำตอนไหน

เนื่องจากช่วงนี้ได้ทำงานกับลูกค้าที่มีการเปลี่ยนแปลงทาง scope ของงานเยอะมาก อารมณ์แบบตอน baseline เป็นแบบนึง พอจะเลือกงานมาทำจริงๆ เรียกว่าเปลี่ยนไปตาม strategy ขององค์กรเลยก็ว่าได้ ในฐานะที่เราเป็นกลุ่มนักพัฒนา ที่ยังจำเป็นต้องควบคุมงบประมาณ กำหนด scope และต้องตอบให้ได้ว่า

By Thanthiya Phatharamalai