การปรับแต่ง Talking Points ปี 2018 ให้เหมาะสมที่สุด (rachelbythebay.com) 2 คะแนน โดย GN⁺ 2024-05-27 | 1 ความคิดเห็น | แชร์ทาง WhatsApp บทความที่เกี่ยวข้อง เริ่มเบื่อเรื่อง AI กันแล้วหรือยัง? 40 คะแนน · 17 ความคิดเห็น · 2026-03-25 แนวคิด AI ที่สำคัญที่สุดในตอนนี้ (เมษายน 2026) 54 คะแนน · 4 ความคิดเห็น · 2026-04-03 ฉันได้เรียนรู้อะไรจาก Bluehole: Communication 16 คะแนน · 0 ความคิดเห็น · 2020-09-18 จงเดิมพันกับข้อความเสมอ (2014) 14 คะแนน · 3 ความคิดเห็น · 2025-12-28 คู่มือคอนเทนต์มาร์เก็ตติ้ง 2021 11 คะแนน · 0 ความคิดเห็น · 2021-01-08 1 ความคิดเห็น GN⁺ 2024-05-27 ความคิดเห็นจาก Hacker News มีประสบการณ์เกี่ยวกับ “โค้ดแย่” อยู่บ้าง แม้มักจะทำงานคนเดียว แต่ก็เคยเขียนโค้ดในทีมที่แค่ใช้งานได้แต่ยังไม่เหมาะที่สุด เวลาพยายามรีแฟกเตอร์โค้ดเก่าพร้อมกับงานใหม่ก็มักถูกปฏิเสธ และแม้จะเปิด ticket สำหรับการรีแฟกเตอร์หรือแก้ไขที่จำเป็นไว้ ก็มักถูกเลื่อนลำดับความสำคัญลงหรือถูกเมิน ถ้าทำคนเดียวก็จัดลำดับความสำคัญให้งานที่จำเป็นได้ แต่ในทีม การตัดสินใจที่เป็นทางเลือกรอง อาจคงอยู่ตลอดไป หรือถูกปล่อยไว้จนถึงจังหวะที่ “ระบบล่ม” หลังจากนั้นใน postmortem พอชี้ไปที่ ticket ที่เคยขอให้แก้ระเบิดเวลานี้มาตั้งแต่หลายเดือนก่อน ก็ถูกมองว่าเป็น “การกล่าวโทษ” หรือ “ก้าวร้าว” สุดท้ายทางออกจึงกลายเป็นเหมือนต้องไม่เขียนโค้ดแบบทางเลือกรองเลย ทำให้เวลาเขียนโค้ดรู้สึกหงุดหงิดและกังวลมากขึ้น ในปี 2017 ยังเคยถูกติดต่อให้ไปแก้โค้ดที่เขียนไว้เมื่อปี 2003/2004 ด้วย ซึ่งโค้ดนั้นยังรันอยู่ใน production การได้กลับไปดูโค้ดที่พังและส่วนที่เคยประนีประนอมไว้ แล้วตระหนักว่าคนรับผิดชอบก็คือตัวเอง เป็นประสบการณ์ที่ทำให้ถ่อมตัวลงไม่น้อย และหลังจากนั้นมุมมองต่อ โค้ดที่ดูแลรักษาได้และการทำเอกสาร ก็เปลี่ยนไปอย่างมาก ขึ้นอยู่กับทีมและบริษัท เคยเจอทีมจำนวนมากที่ส่งเสริมให้นักพัฒนาใช้เวลาดูแลรักษาโค้ดและรีแฟกเตอร์ บางครั้งถึงขั้นบังคับให้ทำแต่งานนั้น และให้ความสำคัญกับ งานที่ขับเคลื่อนโดยวิศวกรรม มากกว่าความต้องการผลิตภัณฑ์แบบสุ่ม ๆ อีกทั้งยังปรับกำหนดการเพื่อให้ทำงานให้เสร็จอย่างถูกต้องด้วย ประสบการณ์แบบนี้พบได้ทั่วไปสำหรับผม/ฉัน ตั้งแต่บริษัทใหญ่ใน S&P 500 บริษัทขนาด 100 ล้าน–1 พันล้านดอลลาร์ ไปจนถึงสตาร์ทอัพ ในกรณีเหล่านี้มักมี software engineer และผู้จัดการที่มีประสบการณ์ ซึ่งสามารถประนีประนอมอย่างสมเหตุสมผลและดูแลความจำเป็นทางธุรกิจไปพร้อมกันได้ และวิศวกรมักได้โต้ตอบกับลูกค้าโดยตรงด้วย แก่นสำคัญคือความสมดุล และความสมดุลนั้นมักเกิดจากคนที่ตัดสินได้อย่างสมดุล ถ้ามุ่งแต่ “ความสมบูรณ์แบบ” ก็จะนำไปสู่การรีแฟกเตอร์ไม่รู้จบและไม่ได้ปล่อยของ แต่ถ้าเมิน technical debt หรือคุณภาพที่แย่ ก็อาจทำให้ธุรกิจพังลงเมื่อเวลาผ่านไป จุดที่ควรยืนอยู่ตรงไหนขึ้นอยู่กับผลิตภัณฑ์ อุตสาหกรรม ลูกค้า และธุรกิจ ไม่ก็ตายในฐานะฮีโร่ หรือมีชีวิตอยู่นานพอที่จะเห็นชื่อตัวเองใน git blame เมื่อ 10 ปีก่อน “ใช้งานได้แต่ยังไม่เหมาะที่สุด” มักเป็นการประนีประนอมที่ยอมรับได้เมื่อเวลามีน้อยและมีงานต้องทำมาก คำขวัญสไตล์ MBA อย่าง “ความสมบูรณ์แบบคือศัตรูของสิ่งที่ดี” ก็เป็นวลีที่หยิบมาใช้ได้เวลามีบางอย่างขาดไป การที่ในปี 2017 ถูกเรียกไปแก้โค้ดที่เขียนไว้ในปี 2003/2004 ก็หมายความว่าเราทุกคนล้วนเป็นนักเดินทางข้ามเวลา เราใจดีกับตัวเองในอดีต และหยาบคายกับตัวเองในอนาคตนิดหน่อย ตัวผม/ฉันในอดีตยังเด็กและไร้เดียงสา แต่ก็ productive และฝ่าฟันมาได้มาก ใช้เวลาสองวันกว่าจะเข้าใจโค้ด แต่สุดท้ายก็พบว่ามันค่อนข้างฉลาด และที่ตัวผม/ฉันในปัจจุบันลืมไปหมดอาจเป็นเพราะความจำไม่ดีก็ได้ ตัวผม/ฉันในอนาคตจะแก้ความผิดพลาดทั้งหมดให้ถูกต้อง เขาจะแก่กว่าและฉลาดกว่า เปลี่ยน XXX และ TBD ให้เป็นโค้ดอันชาญฉลาด นำไอเดียดี ๆ ไปทำจริง และมีเวลาไม่จำกัดในการทำไอเดียที่งั้น ๆ ใหม่อีกครั้ง ถ้ามีคอมเมนต์ที่ดีกว่านี้ ทั้งสามคนนี้อาจกลายเป็นคนเดียวกันก็ได้ ผม/ฉันมองว่าท่าทีแบบผู้ชอบธรรมที่เป็น “คนคนนั้น” นั้นเป็นอันตราย การที่ senior developer สามารถพูดถึงความผิดพลาดและงานที่พังของตัวเองได้ เป็นเรื่องที่ปลดปล่อยและดีต่อสุขภาพอย่างมาก นอกจากจะเป็นโอกาสในการเรียนรู้แล้ว ยังแสดงให้เห็นถึง วัฒนธรรมที่เปิดกว้าง และช่วยต่อสู้กับ impostor syndrome ด้วย ท่าทีแบบ perfectionism ตรงกันข้ามกับสิ่งนี้ เพราะมีแต่ “พยายามให้มากขึ้นแล้วอย่าทำพลาด” จึงไม่มีอะไรให้เรียนรู้ มีแต่เรียกร้องความพยายามส่วนบุคคลมากขึ้น อย่างน้อยสองครั้ง “คนคนนั้น” ไม่ยอมรับความผิดพลาดใหญ่ ๆ และหลีกเลี่ยงแม้จะต้องเสียลูกค้าดี ๆ ไป แถมคงนินทาลับหลังด้วย ครั้งหนึ่ง junior ใส่เวอร์ชันซอฟต์แวร์ผิดในรายงาน ซึ่งเป็นความผิดพลาดเล็ก ๆ และผม/ฉันรับไว้เอง ทั้งที่แค่บอกลูกค้าว่า “มีข้อผิดพลาด และนี่คือรายงานที่แก้ไขแล้ว” ก็พอ แต่หัวหน้ากลับคิดแต่เรื่อง “เราจะปิดเรื่องนี้และรักษาหน้าตาว่าเราสมบูรณ์แบบได้ไหม?” คนเดียวกันนี้ใช้ความผิดพลาดของคนอื่นเป็นโอกาสเรียกร้องส่วนลด การชดเชย หรือของฟรี โดยรวมแล้วคิดว่าคนส่วนใหญ่ก็ทำงานของตัวเองและค่อย ๆ ดีขึ้น ใน configuration management ของเรามีของที่ผม/ฉันเขียนไว้จำนวนหนึ่ง ซึ่งในเชิงฟังก์ชันก็ทำงานได้ดี แต่พอใช้เครื่องมือนั้นมา 1–2 ปี ก็เริ่มเรียกได้ว่าคุณภาพค่อนข้างแย่ด้วยเหตุผลหลายอย่าง แต่ก็ไม่เป็นไร ถ้ามีเหตุผลให้เปลี่ยนก็ค่อยจัดระเบียบใหม่ และจนกว่าจะถึงตอนนั้น มันก็ยังเป็นตัวอย่างของ แนวปฏิบัติที่ไม่ดี และแนวทางที่ดีกว่า ถ้าหาจุดให้วิจารณ์ในตัวเองไม่เจอ ก็แปลว่าคุณไม่ได้พัฒนา การแบ่งปันการวิจารณ์ตัวเองแบบนั้นทำให้คนอื่นได้เรียนรู้จากความผิดพลาดของเรา และรู้ว่าการเรียนรู้จากความผิดพลาดของตัวเองก็เป็นเรื่องที่ทำได้ ใน code review มักได้ยินคำพูดอย่าง “ทำไมไม่แค่ไม่ทำพลาดแบบนั้นล่ะ” หรือ “ทำไมไม่แค่ทำแบบนี้ล่ะ” อยู่บ่อย ๆ ช่วงนี้ผม/ฉันตอบว่า “คงเป็นเพราะ IQ คุณสูงกว่าผม/ฉันมั้งครับ/ค่ะ ผม/ฉัน IQ ต่ำกว่า เลยต้องทำงานที่โง่กว่าและเรียบง่ายกว่า” บางครั้งอีกฝ่ายก็หน้าแดงเมื่อรู้ตัวว่าตัวเองทำตัวเหมือนเนิร์ดตัวเล็ก ๆ ที่ดูถูกคนอื่นโดยไม่ทบทวนตัวเองแค่ไหน ผม/ฉันค่อนข้างแพ้คำถามที่ขึ้นต้นว่า “ทำไมไม่แค่ … ล่ะ?” แค่ได้ยินสามคำนั้นก็มักเดาได้แล้วว่าข้อเสนอที่จะตามมาคืออะไร ไม่ใช่เพราะมันซับซ้อนมาก แต่เพราะโดยมากมันคือ วิธีชัดเจนที่นึกออกเป็นอย่างแรก และมักถูกพิจารณาอย่างรอบคอบหรือถูกลองไปแล้ว ตัวคำถามเองไม่ได้แย่ แต่สมมติฐานว่า “ไอเดียของฉันง่ายมาก” และ “คุณนึกความคิดที่ชัดเจนและง่ายขนาดนี้ไม่ออก” ทำให้รู้สึกรำคาญหรือถูกดูหมิ่น ในทางกลับกัน เวลาผม/ฉันถามคนอื่น ก็พยายามเลี่ยงคำว่า “ทำไมไม่แค่” และอาจถามว่า “ผม/ฉันเข้าใจได้ไหมว่ามีเหตุผลบางอย่างที่ไม่ได้ทำ X?” หรือแค่ถามเหตุผลอย่างสุภาพน่าจะดีกว่า ถ้าเป็นคำถามที่เกิดจากการขาดบริบท ก็อาจป้องกันได้ด้วยการอธิบายก่อนว่าวิธีที่ชัดเจนที่สุดใช้ไม่ได้เพราะอะไร หรือมี requirement และ input ของปัญหาที่จุกจิกอะไรบ้าง ก่อนจะอธิบายสิ่งที่ทำไปแล้ว ถ้าเป็นโค้ดที่ commit ไปแล้ว เป้าหมายก็คือลดการมาวิจารณ์ย้อนหลังด้วยคอมเมนต์ใน commit หรือ merge request บางครั้งการไม่โต้แย้ง แต่บอกตรง ๆ ว่าเคยลองวิธีนั้นแล้วและทำไมมันใช้ไม่ได้ พร้อมถามอย่างจริงใจว่ามีไอเดียอื่นไหม ก็มีประโยชน์ ถ้าเป็นข้อเสนอที่ผม/ฉันไม่เคยนึกถึงจริง ๆ และดูเหมือนจะแก้ปัญหาได้ ก็จะบอกว่าเป็นไอเดียที่ดีและขอให้ช่วย implement แม้ตอนนั้นจะมีแรงยั่วยุให้ตอบโต้สมมติฐานหรือน้ำเสียงของอีกฝ่าย แต่ผม/ฉันพยายามเลือกที่จะยอมรับมันและอายสักครู่แทน เป็นตัวอย่างการประยุกต์ใช้ grug brain ได้ดีมาก https://grugbrain.dev/ “ถ้าต้องเลือกระหว่างความซับซ้อนกับการสู้ตัวต่อตัวกับไทแรนโนซอรัส grug จะเลือกไทแรนโนซอรัส อย่างน้อย grug ก็มองเห็นไทแรนโนซอรัสได้” ถ้าไม่ได้พูดเล่น คำถามแรกก็ไม่ช่วยอะไรและเกือบจะเป็นพฤติกรรมใจร้าย ทุกคนก็พลาดกันได้บ้างเป็นครั้งคราว คำถามที่สองโดยทั่วไปอาจเป็นฟีดแบ็กที่ใช้ได้ ทักษะและความรู้ของผู้คนไม่ได้ทับซ้อนกันเสมอไป สิ่งที่ซับซ้อนสุด ๆ สำหรับ A อาจไม่ซับซ้อนสำหรับ B และกลับกันได้ด้วย โดยไม่จำเป็นว่าฝ่ายไหนฉลาดกว่า A อาจไม่รู้ SQL และ B อาจไม่รู้ pandas สมมติว่าในเทคสแต็กมีทั้ง SQL และ pandas อยู่แล้ว บางครั้งการย้ายโค้ดบางส่วนจาก SQL ไปเป็น pandas หรือกลับกันก็อาจสมเหตุสมผล บางคนถนัดสไตล์เชิงวัตถุ บางคนถนัดสไตล์เชิงฟังก์ชัน อะไรสมเหตุสมผลกว่ากันไม่ได้ชัดเจนเสมอไป ดังนั้นคำถามแบบนี้อาจเป็นคำถามที่ดีได้ ถ้าข้อเสนอไม่ดี ก็อธิบายว่าทำไมถึงไม่ดี ถ้าดี ก็พิจารณาว่าคุ้มทำตอนนี้ไหม ถ้าอยู่กึ่งกลางหรือไม่มีเวลา ก็ยอมรับแล้วเดินหน้าต่อได้ อีกทางเลือกคือแค่เห็นด้วยอย่างชัดเจนไปเลย อาจตอบว่า “ใช่ครับ/ค่ะ โง่จริง ๆ เนอะ?” หรือ “ใช่ครับ/ค่ะ บางทีอาจไม่ควรทำแบบนั้นก็ได้” หรือ “จะลองคิดดูครับ/ค่ะ” แบบนี้อีกฝ่ายจะทำให้เรารู้สึกอับอายหรือรู้สึกผิดเพราะทำสิ่งที่ไม่ดีที่สุดได้ยาก ผมมองว่าจุดประสงค์ของคำพูดแบบนี้มักเป็นการ สร้างความเหนือกว่าด้วยความอับอาย นี่คือการเลือกไม่เล่นเกมนั้น และโดยปกตินั่นคือหมากที่ชนะ ถ้าเขาพูดไปเพราะไม่รู้ ก็ไม่จำเป็นต้องรับเป็นการโจมตีแล้วทำให้อีกฝ่ายอับอายเพื่อให้ต้องชดใช้ ผมหาบล็อกหรือบทความที่เคยอ่านไม่เจอแล้ว แต่สารคือ “อย่า สันนิษฐานว่าไร้ความสามารถ เพียงเพราะเห็นสิ่งที่ไม่เหมาะที่สุดในโค้ด” คนที่เขียนโค้ดนั้นอาจมีเหตุผลที่ทำให้ทำ “สิ่งที่ถูกต้อง” ทันทีไม่ได้ เช่น เดดไลน์กระชั้น ลำดับความสำคัญอื่น หรือปัจจัยอื่น ๆ แม้ตอนเขียนโค้ดจะสมบูรณ์แบบแล้ว การเติบโตของโค้ดเบสและการเปลี่ยนแปลงของข้อกำหนดก็อาจทำให้มันแย่ลงได้ ตัวอย่างเช่น ถ้ามีรายการที่ต้องเก็บ 10 รายการ ไฟล์ธรรมดาอาจเป็นตัวเลือกที่ใช้งานได้จริง แต่ถ้ากลายเป็น 10,000 รายการ ก็อาจต้องใช้ฐานข้อมูล แต่ถ้าตั้งแต่แรกใช้ฐานข้อมูลเพื่อ 10 รายการ ก็คงถูกบ่นว่าออกแบบเกินจำเป็น ถ้ามีคลาส 2 คลาส if/else ก็เพียงพอ แต่ถ้ามี 20 คลาส อาจต้องใช้ Factory pattern และถ้าทำตั้งแต่แรกก็คงดูเหมือนสถาปัตยกรรมอวกาศ การพยายามทำนายการเติบโตแบบนี้แล้วทายผิดจะทำให้ได้โค้ดที่ซับซ้อน โปรเจกต์ที่พัฒนาต่อเนื่องจะเติบโตเกินตัวมันเองอย่างเป็นระบบ ยังมีรั้วของเชสเตอร์ตันด้วย สิ่งที่ดูโง่ในโค้ดอาจเคยมีความสำคัญจริง ๆ ในอดีต แย่กว่านั้นคือ ตอนนี้มันอาจยังสำคัญกับ edge case ที่พบได้น้อย แต่เรายังไม่เห็นเหตุผลก็ได้ ผมเคยเขียนเรื่องที่เกี่ยวข้องไว้ที่นี่: https://camhashemi.com/posts/building-through-uncertainty/ ผมเคยเจอคอมเมนต์เป็นพิษเกี่ยวกับบทความบล็อกทั้งที่นี่และใน reddit อยู่หลายครั้ง ตอนนั้นผมใช้วิธีเพิ่มลิงก์ไปยังคอมเมนต์เป็นพิษนั้นไว้ในบทความแบบไม่ตัดสิน เพื่อ ส่องไฟให้เห็น ปกติก็ไม่มีอะไรเกิดขึ้น แต่บางครั้งก็ช่วยพาการสนทนากลับไปในทิศทางที่ดีต่อสุขภาพกว่าได้ ผมเองก็เจอมาไม่น้อย บางส่วนอาจสมควรแล้ว แต่ส่วนใหญ่น่าจะไม่ใช่ บางอันก็พูดถูกอยู่บ้าง แต่ไม่เป็นประโยชน์หรือเป็นอันตรายต่อคอมมูนิตี้โดยตรง การพูดสิ่งที่ถูกด้วยวิธีที่ผิด ก็ยังคงเป็นการพูดผิดอยู่ดี การลิงก์คอมเมนต์เป็นพิษแบบไม่ตัดสินไม่ใช่ความคิดที่แย่เสมอไป ถ้าคอมเมนต์ถูกทำให้ตายแล้วก็อาจทำไม่ได้เสมอ แต่ถึงอย่างไรผมก็ไม่โต้กลับด้วยวิธีเดียวกัน ผมก็ทำได้ แต่ได้เรียนรู้แล้วว่าน้ำมันเบนซินไม่ใช่น้ำยาดับเพลิงที่มีประสิทธิภาพ ถ้าผมผิด ผมจะพยายามยอมรับทันทีในที่เดียวกับที่เกิดความผิดพลาดนั้น ผมไม่ชอบเป็นพิเศษกับการขอโทษแบบส่วนตัวหลังจากโจมตีต่อสาธารณะ มันมีเส้นอยู่ ผมรู้สึกว่าผมทำงานได้ค่อนข้างดี ทำมานานประมาณ 40 ปี และได้เรียนรู้อะไรมากมายตลอดเวลานั้น ผมเคยทำงานในสภาพแวดล้อมที่เข้มงวดซึ่งไม่ยอมรับงานคุณภาพต่ำ จึงทำให้การทำงานที่ใช้ได้กลายเป็นนิสัย โดยทั่วไปผมหลีกเลี่ยงการตัดสินคนอื่นต่อสาธารณะ มันไม่ช่วยอะไร และผมก็ไม่ได้ถูกเสมอไป อย่างไรก็ตาม ถ้าเป็นสถานการณ์ที่ต้องทำงานร่วมกันหรือใช้ของของคนนั้น ก็อาจต่างออกไป ผมเคยถูกโจมตีอย่างรุนแรงเพียงเพราะไม่ยอมรับขยะ แต่ผมก็ไม่ได้ทำตัวแบบ Linus Torvalds ถ้าเป็นไปได้ ผมจะบอกด้วยความเคารพว่างานนั้นสำหรับผมรับไม่ได้ ถึงอย่างนั้นก็ยังปรับปรุงและเรียนรู้สิ่งใหม่ได้เสมอ และบางครั้งก็เรียนรู้จากที่ที่คาดไม่ถึงเลย การเปิดรับการเรียนรู้แบบนี้โดยพื้นฐานแล้วเป็นนโยบายที่ดี ผมถูกขึ้นมาได้ด้วยการผิดแล้วเรียนรู้ “วิจารณญาณที่ดีมาจากประสบการณ์ และประสบการณ์มาจากวิจารณญาณที่แย่” หนึ่งในพอดแคสต์ที่ผมชอบคือ well there's your problem บน YouTube มักจะปักหมุดคอมเมนต์ที่บ่นพอดแคสต์ไว้แทบทุกครั้ง ส่วนใหญ่เป็นคำบ่นระดับ “ฉันไม่ชอบพอดแคสต์นี้ ดังนั้นมันควรกลายเป็นพอดแคสต์อื่น” และคอมเมนต์ที่ถูกปักหมุดทุกครั้งก็มักใกล้เคียงกับการตีความตอนนั้นแบบโง่ที่สุดเท่าที่เป็นไปได้ ผมไม่รู้ว่ามันช่วยลดคอมเมนต์แบบนั้นได้ไหม แต่ก็มีความหมายในเชิงอุปมาเหมือนเอา หมวกคนโง่ ไปสวมให้คนที่เข้าร่วมวาทกรรมแบบนั้น ผมเห็นด้วยว่าวิศวกรบางคนมีทัศนคติที่แย่ ใคร ๆ ก็เขียนโค้ดแย่ได้ และตรรกะที่ว่าโค้ดทุกตัวแย่และเป็นหนี้ก็มีส่วนที่สมเหตุสมผล บทความนี้น่าสนใจเมื่ออ่านคู่กับ “No more pink mustache” ในบทความนั้น Lyft ถูกบรรยายว่า “พังในระดับที่ไม่น่าเชื่อ” และสาเหตุของคุณภาพมักไม่ใช่คนที่นั่งอยู่บนเก้าอี้ แต่เป็น องค์กร :-) [1] https://rachelbythebay.com/w/2020/02/29/poof/ ผมอ่านบทความนี้ในปี 2018 และดีใจที่มันถูกหยิบขึ้นมาอีกครั้ง มันเป็นหนึ่งในบทความที่ทำให้ผมตั้งคำถามกับตัวเอง ถ้าเราไม่สามารถกำจัดแนวคิดแบบสัมบูรณ์หรือสุดโต่งได้ เราจะสร้าง ฟิลเตอร์ แบบไหนเมื่อเจอบทสนทนาหรือคนแบบนี้ ผมมีโมเดลของตัวเอง แต่ก็อยากรู้ว่าคนอื่นใช้กลยุทธ์อะไรกัน คนแบบนี้พยายามยึดครอง พื้นที่ทางอารมณ์ ที่ไม่ใช่ของตัวเอง โดยปกติเขามักคำนวณไว้ล่วงหน้าแล้วว่า “ทำได้” ซึ่งหมายความว่าเขามองอีกฝ่ายว่าอ่อนแอ มีทางเลือกสามแบบ ยอมแพ้และยกพื้นที่นั้นให้ แล้วใช้ชีวิตต่อไป ยิ่งนอนไม่หลับเพราะความไม่ยุติธรรมน้อยเท่าไรก็ยิ่งดี เผชิญหน้าตรง ๆ คนเหล่านี้เตรียมพร้อมจะสู้ แต่จุดยืนของพวกเขาโดยเนื้อแท้แล้วไร้เหตุผล ดังนั้นยิ่งถูกดึงเข้าไปในพื้นที่ความคิดของพวกเขาน้อยเท่าไรก็ยิ่ง “ชนะ” หรือวางตัวจากที่สูงกว่า คือเอาหลักฐานทางสังคมว่าพวกเขาผิดเข้าไปในพื้นที่ของพวกเขา ในกรณีของบทความต้นทาง ก็คือโปรแกรมเมอร์ที่ทำงานได้อย่างมีผลิตภาพ เคารพงานของกันและกัน และไม่จ้องจับผิด เมื่อมีใครแนะนำว่า “ถ้าทำแบบนี้อาจดีกว่า” นั่นไม่ได้เป็นการโจมตีหรือดูถูกความสามารถของผมเสมอไป คนที่ให้คำแนะนำอาจเป็นคนโง่ที่ไม่ถนัดเรื่องความสัมพันธ์ระหว่างบุคคล หรืออาจเป็นแค่คนโง่เต็มตัวก็ได้ ไม่เป็นไรที่บางส่วนของโลกจะไม่เห็นด้วยกับฉัน การที่ผู้คนแสดงความคิดเห็นคัดค้านหรือไม่เห็นด้วย ไม่ได้หมายความว่าพวกเขากำลังคุกคามฉัน เป็นบทความที่แปลก ฟังเหมือนทวีต เนื้อหาน้อย และชื่อเรื่องไม่สะท้อนตัวบท จึงดูเหมือน คลิกเบต ไม่ได้คัดค้านประเด็นหลัก แต่ก็มีอีกด้านหนึ่งเช่นกัน จำเป็นต้องมี ความสามารถในการรับฟีดแบ็ก ด้วย คนส่วนใหญ่สามารถรับฟีดแบ็กและนำไปปรับใช้ได้ เพียงแต่บางคนให้ฟีดแบ็กได้แย่มาก แล้วกลับคิดว่าอีกฝ่ายรับฟีดแบ็กไม่ได้ คนเหล่านี้คิดว่าวิธีให้ฟีดแบ็กที่ตนชอบนั้นดีที่สุด และทุกคนควรรู้สึกเหมือนกัน หากไม่เป็นเช่นนั้นก็เห็นว่าอีกฝ่ายต้องเปลี่ยน แน่นอนว่านั่นผิด แต่ถ้าบอกเรื่องนี้กับพวกเขา พวกเขาก็จะแสดงให้เห็นเองว่าทำไมในประโยคแรกถึงพูดว่า “ส่วนใหญ่”
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ถ้าทำคนเดียวก็จัดลำดับความสำคัญให้งานที่จำเป็นได้ แต่ในทีม การตัดสินใจที่เป็นทางเลือกรอง อาจคงอยู่ตลอดไป หรือถูกปล่อยไว้จนถึงจังหวะที่ “ระบบล่ม” หลังจากนั้นใน postmortem พอชี้ไปที่ ticket ที่เคยขอให้แก้ระเบิดเวลานี้มาตั้งแต่หลายเดือนก่อน ก็ถูกมองว่าเป็น “การกล่าวโทษ” หรือ “ก้าวร้าว” สุดท้ายทางออกจึงกลายเป็นเหมือนต้องไม่เขียนโค้ดแบบทางเลือกรองเลย ทำให้เวลาเขียนโค้ดรู้สึกหงุดหงิดและกังวลมากขึ้น
ในปี 2017 ยังเคยถูกติดต่อให้ไปแก้โค้ดที่เขียนไว้เมื่อปี 2003/2004 ด้วย ซึ่งโค้ดนั้นยังรันอยู่ใน production การได้กลับไปดูโค้ดที่พังและส่วนที่เคยประนีประนอมไว้ แล้วตระหนักว่าคนรับผิดชอบก็คือตัวเอง เป็นประสบการณ์ที่ทำให้ถ่อมตัวลงไม่น้อย และหลังจากนั้นมุมมองต่อ โค้ดที่ดูแลรักษาได้และการทำเอกสาร ก็เปลี่ยนไปอย่างมาก
ประสบการณ์แบบนี้พบได้ทั่วไปสำหรับผม/ฉัน ตั้งแต่บริษัทใหญ่ใน S&P 500 บริษัทขนาด 100 ล้าน–1 พันล้านดอลลาร์ ไปจนถึงสตาร์ทอัพ ในกรณีเหล่านี้มักมี software engineer และผู้จัดการที่มีประสบการณ์ ซึ่งสามารถประนีประนอมอย่างสมเหตุสมผลและดูแลความจำเป็นทางธุรกิจไปพร้อมกันได้ และวิศวกรมักได้โต้ตอบกับลูกค้าโดยตรงด้วย
แก่นสำคัญคือความสมดุล และความสมดุลนั้นมักเกิดจากคนที่ตัดสินได้อย่างสมดุล ถ้ามุ่งแต่ “ความสมบูรณ์แบบ” ก็จะนำไปสู่การรีแฟกเตอร์ไม่รู้จบและไม่ได้ปล่อยของ แต่ถ้าเมิน technical debt หรือคุณภาพที่แย่ ก็อาจทำให้ธุรกิจพังลงเมื่อเวลาผ่านไป จุดที่ควรยืนอยู่ตรงไหนขึ้นอยู่กับผลิตภัณฑ์ อุตสาหกรรม ลูกค้า และธุรกิจ
ตัวผม/ฉันในอดีตยังเด็กและไร้เดียงสา แต่ก็ productive และฝ่าฟันมาได้มาก ใช้เวลาสองวันกว่าจะเข้าใจโค้ด แต่สุดท้ายก็พบว่ามันค่อนข้างฉลาด และที่ตัวผม/ฉันในปัจจุบันลืมไปหมดอาจเป็นเพราะความจำไม่ดีก็ได้
ตัวผม/ฉันในอนาคตจะแก้ความผิดพลาดทั้งหมดให้ถูกต้อง เขาจะแก่กว่าและฉลาดกว่า เปลี่ยน XXX และ TBD ให้เป็นโค้ดอันชาญฉลาด นำไอเดียดี ๆ ไปทำจริง และมีเวลาไม่จำกัดในการทำไอเดียที่งั้น ๆ ใหม่อีกครั้ง ถ้ามีคอมเมนต์ที่ดีกว่านี้ ทั้งสามคนนี้อาจกลายเป็นคนเดียวกันก็ได้
นอกจากจะเป็นโอกาสในการเรียนรู้แล้ว ยังแสดงให้เห็นถึง วัฒนธรรมที่เปิดกว้าง และช่วยต่อสู้กับ impostor syndrome ด้วย ท่าทีแบบ perfectionism ตรงกันข้ามกับสิ่งนี้ เพราะมีแต่ “พยายามให้มากขึ้นแล้วอย่าทำพลาด” จึงไม่มีอะไรให้เรียนรู้ มีแต่เรียกร้องความพยายามส่วนบุคคลมากขึ้น
ครั้งหนึ่ง junior ใส่เวอร์ชันซอฟต์แวร์ผิดในรายงาน ซึ่งเป็นความผิดพลาดเล็ก ๆ และผม/ฉันรับไว้เอง ทั้งที่แค่บอกลูกค้าว่า “มีข้อผิดพลาด และนี่คือรายงานที่แก้ไขแล้ว” ก็พอ แต่หัวหน้ากลับคิดแต่เรื่อง “เราจะปิดเรื่องนี้และรักษาหน้าตาว่าเราสมบูรณ์แบบได้ไหม?” คนเดียวกันนี้ใช้ความผิดพลาดของคนอื่นเป็นโอกาสเรียกร้องส่วนลด การชดเชย หรือของฟรี
แต่ก็ไม่เป็นไร ถ้ามีเหตุผลให้เปลี่ยนก็ค่อยจัดระเบียบใหม่ และจนกว่าจะถึงตอนนั้น มันก็ยังเป็นตัวอย่างของ แนวปฏิบัติที่ไม่ดี และแนวทางที่ดีกว่า
ช่วงนี้ผม/ฉันตอบว่า “คงเป็นเพราะ IQ คุณสูงกว่าผม/ฉันมั้งครับ/ค่ะ ผม/ฉัน IQ ต่ำกว่า เลยต้องทำงานที่โง่กว่าและเรียบง่ายกว่า” บางครั้งอีกฝ่ายก็หน้าแดงเมื่อรู้ตัวว่าตัวเองทำตัวเหมือนเนิร์ดตัวเล็ก ๆ ที่ดูถูกคนอื่นโดยไม่ทบทวนตัวเองแค่ไหน
ตัวคำถามเองไม่ได้แย่ แต่สมมติฐานว่า “ไอเดียของฉันง่ายมาก” และ “คุณนึกความคิดที่ชัดเจนและง่ายขนาดนี้ไม่ออก” ทำให้รู้สึกรำคาญหรือถูกดูหมิ่น ในทางกลับกัน เวลาผม/ฉันถามคนอื่น ก็พยายามเลี่ยงคำว่า “ทำไมไม่แค่” และอาจถามว่า “ผม/ฉันเข้าใจได้ไหมว่ามีเหตุผลบางอย่างที่ไม่ได้ทำ X?” หรือแค่ถามเหตุผลอย่างสุภาพน่าจะดีกว่า
ถ้าเป็นคำถามที่เกิดจากการขาดบริบท ก็อาจป้องกันได้ด้วยการอธิบายก่อนว่าวิธีที่ชัดเจนที่สุดใช้ไม่ได้เพราะอะไร หรือมี requirement และ input ของปัญหาที่จุกจิกอะไรบ้าง ก่อนจะอธิบายสิ่งที่ทำไปแล้ว ถ้าเป็นโค้ดที่ commit ไปแล้ว เป้าหมายก็คือลดการมาวิจารณ์ย้อนหลังด้วยคอมเมนต์ใน commit หรือ merge request บางครั้งการไม่โต้แย้ง แต่บอกตรง ๆ ว่าเคยลองวิธีนั้นแล้วและทำไมมันใช้ไม่ได้ พร้อมถามอย่างจริงใจว่ามีไอเดียอื่นไหม ก็มีประโยชน์
ถ้าเป็นข้อเสนอที่ผม/ฉันไม่เคยนึกถึงจริง ๆ และดูเหมือนจะแก้ปัญหาได้ ก็จะบอกว่าเป็นไอเดียที่ดีและขอให้ช่วย implement แม้ตอนนั้นจะมีแรงยั่วยุให้ตอบโต้สมมติฐานหรือน้ำเสียงของอีกฝ่าย แต่ผม/ฉันพยายามเลือกที่จะยอมรับมันและอายสักครู่แทน
“ถ้าต้องเลือกระหว่างความซับซ้อนกับการสู้ตัวต่อตัวกับไทแรนโนซอรัส grug จะเลือกไทแรนโนซอรัส อย่างน้อย grug ก็มองเห็นไทแรนโนซอรัสได้”
คำถามที่สองโดยทั่วไปอาจเป็นฟีดแบ็กที่ใช้ได้ ทักษะและความรู้ของผู้คนไม่ได้ทับซ้อนกันเสมอไป สิ่งที่ซับซ้อนสุด ๆ สำหรับ A อาจไม่ซับซ้อนสำหรับ B และกลับกันได้ด้วย โดยไม่จำเป็นว่าฝ่ายไหนฉลาดกว่า A อาจไม่รู้ SQL และ B อาจไม่รู้ pandas
สมมติว่าในเทคสแต็กมีทั้ง SQL และ pandas อยู่แล้ว บางครั้งการย้ายโค้ดบางส่วนจาก SQL ไปเป็น pandas หรือกลับกันก็อาจสมเหตุสมผล บางคนถนัดสไตล์เชิงวัตถุ บางคนถนัดสไตล์เชิงฟังก์ชัน อะไรสมเหตุสมผลกว่ากันไม่ได้ชัดเจนเสมอไป ดังนั้นคำถามแบบนี้อาจเป็นคำถามที่ดีได้ ถ้าข้อเสนอไม่ดี ก็อธิบายว่าทำไมถึงไม่ดี ถ้าดี ก็พิจารณาว่าคุ้มทำตอนนี้ไหม ถ้าอยู่กึ่งกลางหรือไม่มีเวลา ก็ยอมรับแล้วเดินหน้าต่อได้
แบบนี้อีกฝ่ายจะทำให้เรารู้สึกอับอายหรือรู้สึกผิดเพราะทำสิ่งที่ไม่ดีที่สุดได้ยาก ผมมองว่าจุดประสงค์ของคำพูดแบบนี้มักเป็นการ สร้างความเหนือกว่าด้วยความอับอาย นี่คือการเลือกไม่เล่นเกมนั้น และโดยปกตินั่นคือหมากที่ชนะ
ตัวอย่างเช่น ถ้ามีรายการที่ต้องเก็บ 10 รายการ ไฟล์ธรรมดาอาจเป็นตัวเลือกที่ใช้งานได้จริง แต่ถ้ากลายเป็น 10,000 รายการ ก็อาจต้องใช้ฐานข้อมูล แต่ถ้าตั้งแต่แรกใช้ฐานข้อมูลเพื่อ 10 รายการ ก็คงถูกบ่นว่าออกแบบเกินจำเป็น
ถ้ามีคลาส 2 คลาส if/else ก็เพียงพอ แต่ถ้ามี 20 คลาส อาจต้องใช้ Factory pattern และถ้าทำตั้งแต่แรกก็คงดูเหมือนสถาปัตยกรรมอวกาศ การพยายามทำนายการเติบโตแบบนี้แล้วทายผิดจะทำให้ได้โค้ดที่ซับซ้อน โปรเจกต์ที่พัฒนาต่อเนื่องจะเติบโตเกินตัวมันเองอย่างเป็นระบบ
การลิงก์คอมเมนต์เป็นพิษแบบไม่ตัดสินไม่ใช่ความคิดที่แย่เสมอไป ถ้าคอมเมนต์ถูกทำให้ตายแล้วก็อาจทำไม่ได้เสมอ แต่ถึงอย่างไรผมก็ไม่โต้กลับด้วยวิธีเดียวกัน ผมก็ทำได้ แต่ได้เรียนรู้แล้วว่าน้ำมันเบนซินไม่ใช่น้ำยาดับเพลิงที่มีประสิทธิภาพ
ถ้าผมผิด ผมจะพยายามยอมรับทันทีในที่เดียวกับที่เกิดความผิดพลาดนั้น ผมไม่ชอบเป็นพิเศษกับการขอโทษแบบส่วนตัวหลังจากโจมตีต่อสาธารณะ
มันมีเส้นอยู่ ผมรู้สึกว่าผมทำงานได้ค่อนข้างดี ทำมานานประมาณ 40 ปี และได้เรียนรู้อะไรมากมายตลอดเวลานั้น ผมเคยทำงานในสภาพแวดล้อมที่เข้มงวดซึ่งไม่ยอมรับงานคุณภาพต่ำ จึงทำให้การทำงานที่ใช้ได้กลายเป็นนิสัย
โดยทั่วไปผมหลีกเลี่ยงการตัดสินคนอื่นต่อสาธารณะ มันไม่ช่วยอะไร และผมก็ไม่ได้ถูกเสมอไป อย่างไรก็ตาม ถ้าเป็นสถานการณ์ที่ต้องทำงานร่วมกันหรือใช้ของของคนนั้น ก็อาจต่างออกไป ผมเคยถูกโจมตีอย่างรุนแรงเพียงเพราะไม่ยอมรับขยะ แต่ผมก็ไม่ได้ทำตัวแบบ Linus Torvalds ถ้าเป็นไปได้ ผมจะบอกด้วยความเคารพว่างานนั้นสำหรับผมรับไม่ได้
ถึงอย่างนั้นก็ยังปรับปรุงและเรียนรู้สิ่งใหม่ได้เสมอ และบางครั้งก็เรียนรู้จากที่ที่คาดไม่ถึงเลย การเปิดรับการเรียนรู้แบบนี้โดยพื้นฐานแล้วเป็นนโยบายที่ดี ผมถูกขึ้นมาได้ด้วยการผิดแล้วเรียนรู้ “วิจารณญาณที่ดีมาจากประสบการณ์ และประสบการณ์มาจากวิจารณญาณที่แย่”
ผมไม่รู้ว่ามันช่วยลดคอมเมนต์แบบนั้นได้ไหม แต่ก็มีความหมายในเชิงอุปมาเหมือนเอา หมวกคนโง่ ไปสวมให้คนที่เข้าร่วมวาทกรรมแบบนั้น
บทความนี้น่าสนใจเมื่ออ่านคู่กับ “No more pink mustache” ในบทความนั้น Lyft ถูกบรรยายว่า “พังในระดับที่ไม่น่าเชื่อ” และสาเหตุของคุณภาพมักไม่ใช่คนที่นั่งอยู่บนเก้าอี้ แต่เป็น องค์กร :-)
[1] https://rachelbythebay.com/w/2020/02/29/poof/
มีทางเลือกสามแบบ ยอมแพ้และยกพื้นที่นั้นให้ แล้วใช้ชีวิตต่อไป ยิ่งนอนไม่หลับเพราะความไม่ยุติธรรมน้อยเท่าไรก็ยิ่งดี เผชิญหน้าตรง ๆ คนเหล่านี้เตรียมพร้อมจะสู้ แต่จุดยืนของพวกเขาโดยเนื้อแท้แล้วไร้เหตุผล ดังนั้นยิ่งถูกดึงเข้าไปในพื้นที่ความคิดของพวกเขาน้อยเท่าไรก็ยิ่ง “ชนะ” หรือวางตัวจากที่สูงกว่า คือเอาหลักฐานทางสังคมว่าพวกเขาผิดเข้าไปในพื้นที่ของพวกเขา ในกรณีของบทความต้นทาง ก็คือโปรแกรมเมอร์ที่ทำงานได้อย่างมีผลิตภาพ เคารพงานของกันและกัน และไม่จ้องจับผิด
คนที่ให้คำแนะนำอาจเป็นคนโง่ที่ไม่ถนัดเรื่องความสัมพันธ์ระหว่างบุคคล หรืออาจเป็นแค่คนโง่เต็มตัวก็ได้ ไม่เป็นไรที่บางส่วนของโลกจะไม่เห็นด้วยกับฉัน การที่ผู้คนแสดงความคิดเห็นคัดค้านหรือไม่เห็นด้วย ไม่ได้หมายความว่าพวกเขากำลังคุกคามฉัน
คนเหล่านี้คิดว่าวิธีให้ฟีดแบ็กที่ตนชอบนั้นดีที่สุด และทุกคนควรรู้สึกเหมือนกัน หากไม่เป็นเช่นนั้นก็เห็นว่าอีกฝ่ายต้องเปลี่ยน แน่นอนว่านั่นผิด แต่ถ้าบอกเรื่องนี้กับพวกเขา พวกเขาก็จะแสดงให้เห็นเองว่าทำไมในประโยคแรกถึงพูดว่า “ส่วนใหญ่”