เหตุใดนักพัฒนาระดับซีเนียร์จึงสื่อสารความเชี่ยวชาญของตนไม่ได้

• นักพัฒนาระดับซีเนียร์ และคนที่ไม่ใช่นักพัฒนาตีความประโยคเดียวกันที่ว่า AI agent จะมาแทนที่นักพัฒนา ด้วยเกณฑ์คนละแบบ คือความเสถียรและการเรียนรู้ตลาด
• องค์กรธุรกิจต้องการปล่อยสู่ตลาดให้เร็วเพื่อรับฟีดแบ็กและลด ความไม่แน่นอน แต่ฝ่ายนักพัฒนาระดับซีเนียร์ระวังการเพิ่มขึ้นของความซับซ้อนที่อาจทำให้ระบบพัง
• หลังจากเริ่มมีลูกค้าแล้ว จะมีวัฏจักรสองแบบหมุนไปพร้อมกัน คือการสำรวจตลาดและการทำให้บริการดำเนินต่อเนื่อง และหน้าที่หลักของนักพัฒนาระดับซีเนียร์จะเปลี่ยนเป็นการ จัดการความซับซ้อน
• การโน้มน้าวไม่ได้จบแค่การบอกว่า “ความซับซ้อนคือปัญหา” แต่ต้องตอบสนองความต้องการเรื่องความเร็วของอีกฝ่ายด้วยการ ทดลองที่เร็วกว่า เช่น Google Forms หรือปุ่มใน UI เดิม
• AI ช่วยเพิ่มความเร็วในการปล่อยสู่ตลาด แต่ก็อาจทำลายความสามารถในการทำความเข้าใจ แก้ไข และดีบัก อีกทั้งไม่รับผิดชอบต่อผลลัพธ์ ดังนั้นนักพัฒนาระดับซีเนียร์จึงสามารถแยก Speed และ Scale ออกจากกันได้

---

เหตุใดจึงได้ยินประโยคเดียวกันด้วยเกณฑ์ที่ต่างกัน

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

สิ่งที่นักพัฒนาระดับซีเนียร์ระวัง

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

สิ่งที่องค์กรธุรกิจระวัง

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

วัฏจักรที่สองหลังจากเริ่มมีลูกค้า

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

จุดที่การสื่อสารล้มเหลว

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

จุดแข็งที่เป็นรูปธรรมของนักพัฒนาระดับซีเนียร์

• ความสามารถที่มีประโยชน์ที่สุดของนักพัฒนาระดับซีเนียร์คือการไม่สร้างสิ่งที่ไม่จำเป็น และการมองหาโอกาสใช้สิ่งที่มีอยู่แล้วซ้ำ
• หากต้องเก็บข้อมูลแบบสอบถาม ก็ใช้ Google Forms ได้เลย
• แทนที่จะสร้างฟีเจอร์ใหม่ทั้งชุดเพื่อทดสอบ อาจใส่ปุ่มลงใน UI เดิมแล้วดูว่าคนกดหรือไม่
• ก่อนนำบริการ analytics ใหม่เข้ามาใช้ ควรถามก่อนว่าการตัดสินใจที่สำคัญที่สุดซึ่งต้องพึ่ง analytics คืออะไร แล้วเริ่มจากการตัดสินใจเดียว กราฟเดียว ตัวชี้วัดเดียว
• แนวทางแบบนี้เหมือนกับการไม่อบเค้กวันเกิดทั้งก้อน แต่ปักเทียนหนึ่งเล่มลงบนแซนด์วิชแทน
• นักพัฒนาระดับซีเนียร์เรียนรู้วิธีใช้ซอฟต์แวร์ที่มีอยู่แล้วเพื่อมอบสิ่งที่ผู้คนต้องการ
• ประโยคสั้น ๆ ที่สื่อเรื่องนี้ได้คือ “Can we try something quicker?”
• “quicker” คือการยอมรับว่าความเร็วคือสิ่งที่อีกฝ่ายต้องการจริง ๆ
• “something” สื่อว่ามีวิธีอื่นในการบรรลุเป้าหมาย
• “try” แฝงความเป็นไปได้ว่าแม้จะยังไม่สมบูรณ์ แต่ก็อาจดีพอได้
• ประโยคนี้ยอมรับความเร็วในการลดความไม่แน่นอนที่บริษัทต้องการ ขณะเดียวกันก็เปิดพื้นที่ให้นักพัฒนาระดับซีเนียร์ใช้ความเชี่ยวชาญในการลด ใช้ซ้ำ และหลีกเลี่ยงเมื่อทำได้

แรงกดดันที่ AI เปลี่ยนไป และความรับผิดชอบที่ยังคงอยู่

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

นักพัฒนาระดับซีเนียร์ที่ใกล้เคียงบรรณาธิการมากกว่านักเขียน

• วิธีหนึ่งที่นักพัฒนาระดับซีเนียร์สามารถใช้ได้คือ การแยกออกจากกัน (decoupling)
• เป็นเวลานานที่มีเพียงนักพัฒนาซอฟต์แวร์เท่านั้นที่สร้างซอฟต์แวร์ได้ ดังนั้นนักพัฒนาจึงต้องรับผิดชอบทั้งสองวัฏจักร คือการเรียนรู้ตลาดและเสถียรภาพของบริการ
• โครงสร้างเดิมคือระบบเดียวต้องรองรับทั้งสองเป้าหมายพร้อมกัน
• หากมีคนละระบบสำหรับแต่ละเป้าหมาย ก็สามารถแยกความเร็วออกจากเสถียรภาพได้
• มันคล้ายกับนักเขียนนวนิยายที่รีบเขียนร่างแรกให้เสร็จ แล้วภายหลังจึงเข้าสู่กระบวนการตัดต่อ คัดส่วนที่ใช้ได้และทิ้งส่วนที่ใช้ไม่ได้
• งานของบรรณาธิการคือการนำชิ้นส่วนที่ทำงานได้ดีมาขัดเกลาให้กลายเป็นภาพรวมที่มีความกลมกลืน
• เวอร์ชัน Speed คือระบบที่สร้างมาเพื่อความเร็ว ซึ่งอาจเป็นพื้นที่ให้ AI agent, โค้ดที่สร้างขึ้นแต่ยังไม่ผ่านการทบทวน, นักพัฒนาจูเนียร์, ฝ่ายการตลาด ฯลฯ ใช้ทำให้ไอเดียเกิดขึ้นอย่างรวดเร็ว
• เวอร์ชัน Speed ไม่ได้มุ่งไปที่ความเข้าใจได้ แต่ตั้งเป้าให้ดีพอสำหรับรับฟีดแบ็กจากตลาด
• เวอร์ชัน Scale คือระบบที่สร้างมาเพื่อเสถียรภาพ โดยนักพัฒนาระดับซีเนียร์จะออกแบบให้เสถียร เข้าใจได้ และขยายต่อได้
• เวอร์ชัน Speed ช่วยให้ธุรกิจเรียนรู้จากตลาดต่อไปได้ ขณะที่นักพัฒนาระดับซีเนียร์ตามมาสร้างระบบที่ผ่านการทบทวนอย่างดีและเข้าใจได้
• การออกแบบของเวอร์ชัน Scale จะได้รับอิทธิพลจากสิ่งที่เวอร์ชัน Speed ทำงานได้ดีและสิ่งที่ทำงานไม่ได้ผล
• ฟีเจอร์จะถูกสร้างใน Speed แล้วจึงนำไปทำให้เสถียรใน Scale ภายหลัง
• รูปแบบการนำไปใช้จริงอาจยังไม่ชัดเจน แต่แก่นสำคัญคือการ แยกอย่างชัดเจน ระหว่างงานที่มุ่งหาความเร็วกับงานที่มุ่งหาเสถียรภาพ
• เมื่อได้รับคำขอที่ทะเยอทะยาน คุณอาจพูดได้ว่า “เวอร์ชัน Speed จะพร้อมภายใน 3 วัน และเวอร์ชัน Scale จะพร้อมประมาณ 6 สัปดาห์หลังจากนั้น”
• อีกฝ่ายได้ทั้งความเร็วและแรงขับเคลื่อน ส่วนนักพัฒนาระดับซีเนียร์ก็ได้เวลาในการสังเกตและออกแบบ
• เมื่อมองจากมุมนี้ นักพัฒนาระดับซีเนียร์อาจใกล้เคียงกับ บรรณาธิการซอฟต์แวร์ระดับซีเนียร์ มากกว่า “นักเขียนซอฟต์แวร์ระดับซีเนียร์”

[GN⁺]

ความคิดเห็นจาก Hacker News

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

  • ความแตกต่างใหญ่อย่างหนึ่งระหว่างจูเนียร์ที่ดูมีแววและ “จับทาง” ได้เร็ว กับจูเนียร์ที่เป็นไม่ได้แบบนั้น คือ ความสามารถในการสร้างแบบจำลองโลกที่แม่นยำได้อย่างรวดเร็ว
    คนที่เข้าใจและประยุกต์ใช้ “กฎฟิสิกส์” ของซอฟต์แวร์ได้ จะต่างจากคนที่แค่เขียนขั้นตอนเรียงไปโดยไม่พยายามเข้าใจแก่นของแต่ละขั้น
    จะเห็นชัดเป็นพิเศษเวลาไปสอน functional programming ให้คนที่คุ้นกับ object-oriented programming บางคนแบบจำลองเดิมพังทันที ขณะที่บางคนมองออกอย่างรวดเร็วว่าสามารถแปลจากโลกของตัวแปรไปสู่โลกของ monad ได้ค่อนข้างง่าย
  • บังเอิญเมื่อวานได้เจอบทความที่ Peter Naur เขียนไว้ในปี 1985 https://pages.cs.wisc.edu/~remzi/Naur.pdf แล้วมันทำให้คิดต่อไม่หยุด
    ผมทำงานอยู่ในบริษัทยักษ์ใหญ่แห่งหนึ่งเป็นส่วนใหญ่เกือบ 30 ปี และใช้เวลาพอสมควรทุกสัปดาห์ไปกับการตอบปัญหาที่คนมาใหม่เจอ หลายครั้งแค่ฟังคำถามก็พอมองออกทันทีว่ารากของปัญหาอยู่ที่แบบจำลองโลกของพวกเขา หรือ Theory ตามคำของ Naur นั้นยังไม่สมบูรณ์หรือบิดเบี้ยว จนทำให้การให้เหตุผลเป็นเรื่องยาก
    โจทย์คือการแปลงทฤษฎีของตัวเองให้อยู่ในรูปสัญลักษณ์อย่างข้อความหรือไดอะแกรม เพื่อให้คนที่มีประสบการณ์และสติปัญญามากพอสามารถสร้าง mental model ที่คล้ายกันขึ้นมาได้ พูดอีกอย่างคืออยากติดตั้งทฤษฎีของผมเข้าไปในหัวของคนอื่น
    ทฤษฎีในความหมายที่ Naur พูดถึงนั้นย้ายข้ามไปตรงๆ ไม่ได้ แต่งานของนักพัฒนาอาวุโสไม่ว่าจะในห้องเรียนหรือหน้างาน คือการดึงประสบการณ์มาใช้เพื่อหาวิธีทำให้ทฤษฎีแบบนั้นถูกสร้างซ้ำขึ้นมาได้ นั่นจึงเป็นเหตุผลว่าทำไมทักษะการสื่อสารถึงสำคัญ และทำไมการผ่านกระบวนการรับทฤษฎีที่ใช้งานได้จากคนอื่นหลายๆ ครั้งจึงช่วยสร้างสัญชาตญาณที่มีประสิทธิภาพ
    ตอนนี้สิ่งนี้กลายเป็นส่วนที่ให้ความรู้สึกคุ้มค่าที่สุดของงานแล้ว และตราบใดที่ยังรู้สึกว่าตัวเองทำหน้าที่นี้ได้อย่างมีความหมาย ก็ยังไม่อยากรีบเกษียณ
  • ถ้าทุกคนมีแบบจำลองโลกภายในเหมือนกันหมด ก็คงแทบไม่มี นวัตกรรม เลย ดังนั้นผมกลับมองว่านี่เป็นเรื่องดี
    เวลาฝึกและเมนเทอร์จูเนียร์ ผมพยายามชี้ให้เห็นว่าอะไรทำได้และรูปแบบไหนมักนำไปสู่ความล้มเหลว แต่การฝึกแบบนั้นมักเป็นชิ้นๆ และไม่สมบูรณ์
    ผมพยายามอธิบายให้ได้มากที่สุดว่าทำไมถึงทำแบบนั้น แต่แทบไม่ค่อยพูดตัดบทว่าอะไร “ห้ามทำ” คนที่ผมสอนมามักทำให้ผมแปลกใจกับวิธีแก้ปัญหาของพวกเขา และผมเองก็ได้เรียนรู้อยู่บ่อยๆ
    สำหรับคนที่ไม่สนใจผลงานของตัวเองและมองงานเป็นเพียงช่องทางรับเงินเดือน การฝึกมักได้ผลน้อยกว่า ไม่ได้หมายความว่าความคิดแบบนั้นผิด แต่ถ้าสร้างโลกทัศน์ต่อการทำงานบนฐานของความไม่ใส่ใจ ก็จะยากที่จะทำให้การฝึกฝนซึมลึกเข้าไปข้างใน
  • เคยเห็นคนเรียกมุมมองที่ว่าเมื่อส่งความรู้ผ่านคำพูดแล้วก็ถือว่าถ่ายทอดครบถ้วนว่า Transmissionism
    https://andymatuschak.org/books/
  • https://en.wikipedia.org/wiki/Tacit_knowledge

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

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

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

• ผมพบว่าความตั้งใจที่จะสื่อสารและแบ่งปันความเชี่ยวชาญของตัวเองนั้น โดยมากแล้วไม่มีความต้องการจากฝั่งนักพัฒนาจูเนียร์
  โดยทั่วไปนักพัฒนาไม่ได้สนใจมองหา เมนเทอร์ พวกเขาไม่แม้แต่จะดูโปรไฟล์ LinkedIn และไม่ได้มองผมว่าเป็นแหล่งความรู้และความเชี่ยวชาญที่เป็นไปได้
  ไม่ใช่ว่าหลังจากอยู่ในวงการมา 30 ปีแล้วผมไม่มีอะไรจะถ่ายทอด แต่คือไม่มีคนรับฟัง

  • ความอัดอั้นในที่ทำงานตอนนี้ก็คือเรื่องนี้เลย มีเรื่องโง่ๆ เกิดขึ้นมากมายแต่ไม่มีใครพยายามหลีกเลี่ยง
    นักพัฒนาประสบการณ์น้อยคนหนึ่งเสนอให้แทนที่ตัวตรวจสอบ URL ด้วย เวทมนตร์ AI ส่วนผมคัดค้านและเสนอทางออกแบบ fuzzy matching ที่อิงแคชที่เติมไว้ล่วงหน้าด้วย AI แต่ไม่มีใครสนใจ ตอนนี้โมเดล AI ล่มลงมาเฉยๆ แล้วระบบก็พัง ต้องกลับไปตรวจสอบทั้งระบบใหม่หมด
    นักพัฒนารุ่นน้องที่ได้เลื่อนตำแหน่งก่อนผมกำลังเขียนเอกสารว่าจะแก้เรื่องนี้อย่างไร แล้วก็ถามว่า “Dan, ช่วยเรื่องนี้หน่อยได้ไหม?” เขาได้เลื่อนเพราะวิธีขับเคลื่อนงานคือการเขียนเอกสารและประชุม ไม่ใช่การทำงานอย่างมีเหตุผล และตอนนี้เขากำลังจะใช้ผลงานของผมไปพิสูจน์ภาวะผู้นำของตัวเอง
    ยิ่งผมเสนอวิธีแก้ที่ดีกว่า ก็ยิ่งถูกมองว่าเป็นภัยคุกคามโดยนักพัฒนาที่ประสบการณ์น้อยกว่า และเพราะโดยรวมมันก็พอทำงานได้ ผู้จัดการก็เลยไม่ค่อยสนใจ อาจเป็นไปได้ว่าผมเองน่าจะรับมือได้ดีกว่านี้ แต่การต้องสู้กับเรื่องไร้สาระมันเหนื่อยมาก และผมแค่อยากเขียนโค้ดดีๆ
  • ซีเนียร์ที่ผมเคยร่วมงานด้วยมักเข้าออฟฟิศ ทำงานใกล้ชิดกับจูเนียร์ และแทบเหมือนมีอาการแพ้การคุยกับผู้คน
    ในทางกลับกัน จูเนียร์อยากคุย อยากกินข้าวด้วยกัน และอยากแชร์สิ่งที่ตัวเองทำอยู่ ซีเนียร์กลับตั้งกำแพงและอยู่คนเดียว
    อาจจะเป็นแค่ที่ทำงานของเราเองก็ได้ แต่ ออฟฟิศ สำคัญ
  • ตอนทำงานวิศวกรรมงานแรกที่ IBM ผมอยากให้มีคนแบบคุณอยู่ที่นั่น
    ซีเนียร์บางคนที่นั่นเวลาโดนจูเนียร์ถามอะไรจะโกรธ การจะไปถามคนที่ทำงานมา 20 ปีสักอย่างหนึ่งต้องรวบรวมความกล้ามากพออยู่แล้ว แต่ยังมีโอกาส 50% ที่เขาจะตอบกลับมาแบบแย่ๆ
    มันเป็นประสบการณ์การเรียนรู้ที่ดี และตอนนี้ผมเลยตั้งใจพยายามทำ เมนเทอริง แบบมีสติ
  • เสียใจที่คุณเจอประสบการณ์แบบนั้น แต่ก็มีคนที่อยากเรียนรู้จากซีเนียร์จริงๆ อยู่แน่นอน
    ตลอดหลายทศวรรษที่ผ่านมา ผมทำหน้าที่เมนเทอร์เป็นช่วงๆ และโชคดีที่ได้เจอ mentee ที่ยอดเยี่ยม หลายคนผมติดตามดูมาเกือบ 10 ปีแล้ว และตอนนี้พวกเขากำลังไปได้สวยมาก
    ผมอาจไม่มีคำแนะนำที่ช่วยได้มากนักว่าจะหาคนแบบนั้นอย่างไร แต่คนแบบนั้นมีอยู่จริง
  • ในงานแรกของผม อาชีพดันถูกล็อกให้เป็น ผู้ดูแลระบบ ที่สตาร์ตอัปแบบไม่ตั้งใจ และเพราะแทบไม่มีคนให้เรียนรู้ ผมเลยย้ายงานไปบริษัทอีกแห่งในอีกรัฐหนึ่ง โดยมีคนสัมภาษณ์ที่เป็น ผู้ดูแลระบบ เก่งมากซึ่งผมอยากเรียนรู้ด้วย
    แต่หลังจากผมไปถึงไม่นาน เขาก็แจ้งลาออกเพราะหาคนมารับช่วงแทนได้แล้ว สุดท้ายมันเลยไม่ค่อยลงเอยดีกับผมเท่าไร

• proof of concept ส่วนใหญ่ที่ผมเห็น พอเริ่มมีแรงส่งก็กลายเป็น production ไปเลย
  เคยมีหลายครั้งที่ทุกคนสัญญาว่า “ถ้ามันติดแล้วเราจะเขียนใหม่ตั้งแต่ต้น” แต่เรื่องนั้นไม่เคยเกิดขึ้น
  บทความนี้แตะเรื่องความรับผิดชอบและ accountability แต่คนที่เป็นฝ่ายรับความเสี่ยงไม่ค่อยมีสิ่งเหล่านั้น พวกเขารีบปล่อยไอเดียบ้าๆ ออกไปแล้วหวังว่าลูกค้าจะงับ พร้อมเก็บผลประโยชน์ ส่วนเรื่องจะทำให้มันใช้งานได้ ขยายได้ และไม่ให้ต้นทุนการรันสูงกว่าราคาขายได้อย่างไร ไม่ใช่ปัญหาของพวกเขา
  มีบริษัทที่พาลูปด้านขวาไปสุดทาง และตอนนี้สองในนั้นก็มีชื่อเสียงมาก พวกเขารีบปล่อยอะไรบางอย่างออกไป แล้วเพราะมันสเกลได้แค่เชิงเส้นก็ออกไปหาเงินเพิ่ม บริษัทเหล่านี้ถือว่าประสบความสำเร็จ มีผู้ใช้นับไม่ถ้วน และบางส่วนก็ยอมจ่ายเงิน นักพัฒนาอาวุโสหรือคนมีเหตุผลที่ถามว่า “มันยั่งยืนไหม มีทางออกไหม” จะถูกไล่ออก และคนที่เหลืออยู่ก็มีแต่ผู้ศรัทธา

  • นี่จึงเป็นเหตุผลว่าทำไมต้องมี ผู้นำทางวิศวกรรม ที่อาวุโสพอ ทั้งในฝั่ง individual contributor และฝั่งผู้จัดการ
    ถ้าวิศวกรเชื่อฟังผู้มีส่วนได้ส่วนเสียที่ไม่ใช่สายเทคนิคอย่างว่าง่าย ก็จะเกิดช่องว่างด้านความรับผิดชอบ และสุดท้ายเมื่อหายนะปะทุขึ้น คนที่ป้องกันตัวเองได้แย่ที่สุดก็จะโดนโทษ
    ในทางกลับกัน ถ้าขยายมุมมองให้กว้างพอและถามคำว่า “ทำไม” ให้มากพอ แทบทุกปัญหาทางธุรกิจสามารถแก้ได้อย่างสมเหตุสมผลโดยไม่ต้องผลักระบบเข้าไปในประตูทางเดียวที่น่ากลัว
    ไม่ใช่ทุกที่ที่จะให้อำนาจแบบนั้นกับฝ่ายวิศวกรรม แต่ที่ที่ไม่ให้ก็มักรั้งซีเนียร์ไว้ไม่ได้ เพราะซีเนียร์จะย้ายไปที่ที่การตัดสินใจของตนได้รับการยอมรับ บางครั้ง technical debt ก็เป็นทางเลือกที่ถูกต้องทางธุรกิจ แต่ถ้าเป็นวิศวกรที่อาวุโสพอ ก็ต้องเตรียมทางหนีทีไล่ไว้เสมอ
    อย่างไรก็ตาม จะเอาความบริสุทธิ์ของระบบมาไว้เหนือปัญหาทางธุรกิจไม่ได้ ต้นทุนของระบบเป็นสิ่งที่ธุรกิจต้องจ่าย ถ้าลืมเรื่องนี้ไป ก็จะสูญเสียฐานของอิทธิพลเช่นกัน
  • อย่างที่มีคำพูดเก่าแก่บอกไว้ ไม่มีอะไรถาวรเท่ากับแฮ็กชั่วคราว
  • ปัญหานี้มีมาก่อน AI coding agent นานมากแล้ว และ AI อาจทำให้มันแย่ลงได้
    บทสรุปของบทความจริงๆ ก็คือคำแนะนำเก่าแก่ที่ว่า “สร้างอันหนึ่งโดยตั้งใจว่าจะทิ้งมันไป” ผมเองก็อ่าน Mythical Man-Month มาแล้ว แต่ปัญหาคือจะโน้มน้าวคนที่มีอำนาจตัดสินใจอย่างไร
  • มันอาจเป็นปัญหาวัฒนธรรมองค์กรก็ได้ เมื่อก่อนเราเริ่มจากวิธีแก้ที่เร็วและเลอะเทอะแล้วมันกลายเป็นหายนะ เลยตั้งนโยบายเข้มไว้ว่า ทุกฟีเจอร์แบบ quick and dirty ต้องมี story ติดตามที่จะเข้าไปใน 1-2 สปรินต์ถัดไปเสมอ
    ถ้าผลลัพธ์ไม่ถึงความคาดหวัง เราก็ปิดหรือเอาฟีเจอร์นั้นออก ไม่อย่างนั้นก็ทบทวนแล้ว refactor ให้ถูกต้อง
    ทีมมีอิสระสูงและแทบไม่มีใครบ่นเรื่องกำหนดการ เพราะส่วนใหญ่แผนกอื่นตามหลังเราอยู่ มีแต่มาร์เก็ตติงที่มี “ไอเดีย” ตลอดเวลา
  • ถ้า “ต้นแบบ” ที่ใช้งานได้รองรับดีมานด์ได้ มีฟีเจอร์ที่ต้องการครบ และไม่มีเหตุผลให้สร้างใหม่ยกเว้นเพื่อเอาใจรสนิยมของนักพัฒนา แล้วจะเสียเวลาและแรงไปทำไม?
    การที่มันเป็นต้นแบบหรือ proof of concept นั้น โดยเนื้อแท้แล้วไม่สำคัญเลย ถ้าคุณไม่สามารถระบุปัญหาจริงๆ ออกมาเป็นรายการได้
    หลายทีมบ่นว่าจมอยู่ใน technical debt ว่ามันเป็นความเสี่ยงใหญ่และทำให้ช้าลง แต่ในบันทึก incident กลับแทบไม่มีเหตุการณ์ และก็ไม่มีอะไรชี้ว่ามาจากการรันโค้ดเสี่ยงๆ บน production ใน risk register ก็ไม่มีรายการว่า “โค้ดนี้เก่า แย่ และมี dependency ที่เลิกซัพพอร์ตแล้ว” และไม่มีทีมไหนอธิบายได้ว่า technical debt ทำให้ช้าลงอย่างไรและมากแค่ไหน
    ในทางกลับกัน ผมก็เคยเห็นทีมที่เอาเวลาหลายเดือนไปกับการ refactor ก่อนปล่อย เพราะคิดว่าตัวเองจะทำแอปที่เขียนไว้ให้ “ดีกว่าเดิม” ได้ มูลค่าทั้งหมดเลยถูกเลื่อนออกไป ผู้นำก็โกรธเป็นธรรมดา และความเชื่อใจก็แทบไม่เหลือ
    ต้องมีบทสนทนาที่ดีระหว่างทีมกับผู้มีส่วนได้ส่วนเสียเรื่องการส่งมอบ จึงจะทำให้ทุกฝ่ายพอใจได้ แต่ถ้าไม่มี ผู้มีส่วนได้ส่วนเสียจะชนะเสมอ

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

  • ตัวอย่างคลาสสิกคือ นักวิจัย ที่ถูกวัดผลจากงานตีพิมพ์และของใหม่ที่ปล่อยออกมา
    แต่ถ้าเป็นฝั่งผลิตภัณฑ์ ก็ควรต้องปรับฟีเจอร์ให้เข้ากับความต้องการของลูกค้า ดังนั้นควรบอกให้นักวิจัยหยุดเป็นฝ่ายผลักดัน

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

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

• ผมพยายามจะถ่ายทอดความรู้สึกแทบเหมือนกันนี้ให้ทีมฟังมาตั้งแต่หลายวันก่อน โดยเฉพาะประโยคที่ว่า “ต้องสร้างและทดสอบฟีเจอร์ใหม่ทั้งก้อนจริงหรือ? หรือแค่ใส่ปุ่มลงใน UI เดิมแล้วดูว่าคนกดไหม?” แทบจะตรงกันเป๊ะ
  ดูเหมือนว่าหลังจากฝั่งโปรดักต์ตัดสินใจว่าต่อไปนี้ไม่จำเป็นต้องใช้ความสามารถทางความคิดของตัวเองแล้ว วิศวกรก็รับความทุกข์ร่วมกันเป็นหมู่คณะ
  กลายเป็นว่าทำมันออกมาก่อน แล้วค่อยไปหาว่า user persona คืออะไรและมันมีประโยชน์ไหมทีหลัง หรือไม่ก็ไม่ต้องหาเลย
  เมื่อก่อนเราใช้เวลาไปกับการทำความเข้าใจโดเมน ผู้ใช้ และตำแหน่งของผลิตภัณฑ์ในกระบวนการต่างๆ แต่ตอนนี้กลับแค่ปล่อยสิ่งที่คิดว่าผู้ใช้ในจินตนาการน่าจะอยากได้ แล้วค่อยทดลองไปจนกว่าจะสำเร็จ
  ปัญหาตามที่ต้นฉบับพูดไว้เกิดขึ้นตรงนี้พอดี ทุกฟีเจอร์สุ่มๆ ที่ถูกสร้างด้วย vibe coding กลายเป็นแหล่งของความไม่เสถียรและความเสี่ยง และเพราะไม่มีใครมี mental model ที่ใช้งานได้ของสิ่งนั้น มันจึงดูแลต่อได้ด้วย vibe coding เพิ่มเข้าไปเท่านั้น

• ต่อให้คุณลดความซับซ้อนให้เหลือเป็นมิติการวัดเดียวได้ มันก็ยังเป็นเพียงองค์ประกอบหนึ่งในหลายอย่างของพื้นที่คำตอบ
  ยังมีคุณสมบัติอื่นอย่าง maintainability, scalability, reliability, resilience, antifragility, extensibility, generality, durability, composability ซึ่งไม่ได้ใช้ได้กับทุกกรณีเสมอไป
  ผมคิดว่าความสามารถในการพูดเรื่องนี้ในฐานะ trade-off ของพื้นที่คำตอบ แทนที่จะมองเป็นมิติเดียว คือสิ่งที่แยกซีเนียร์กับ Staff+ developer ออกจากกัน

  • ถ้าคุณเข้าใจคำว่า “ความซับซ้อน” ในแบบที่จูเนียร์มองจากหน้าตัดสุ่มเพียงด้านเดียวตอนแรก มันก็จะดูแย่และเกินจำเป็นเสมอ
    แต่ถ้าเข้าใจมันในฐานะองค์ประกอบที่จะทำให้การพัฒนาระบบนี้ในอีก 10 คน-ปีข้างหน้าง่ายและเร็วขึ้น มันก็หมายถึงการเลือกอ้อมด้านข้างในจุดที่แนวทางไร้เดียงสาพยายามพุ่งทะลุตรงๆ
    เหมือนนิทานกระต่ายกับเต่า การเร่งเผาทรัพยากรในสองสัปดาห์แรกเพื่อเก็บ low-hanging fruit, ผลลัพธ์ที่มองเห็นได้ และ MVP นั้น เข้าใจได้ไม่ยาก แต่พอความเร็วค่อยๆ ลดลงเพราะการออกแบบที่ยังไม่สุกงอมและการบำรุงรักษาระหว่างพัฒนา มันจึงกลายเป็นว่าที่ดู “เร็ว” อยู่ไม่กี่สัปดาห์ สุดท้ายกลับทำให้กำหนดการเลื่อนไป 6 เดือน
  • trade-off คือหัวใจ คนที่ไม่เขียนโปรแกรมมักจินตนาการว่าไม่มี trade-off
    แต่ถ้าเป็นโปรแกรมเมอร์ สุดท้ายต้องตระหนักว่าทุกแง่มุมที่เป็นไปได้ของการออกแบบล้วนเป็น trade-off
  • ปัจจัยหลายอย่างในกลุ่มนี้ได้รับผลโดยตรงจากความซับซ้อน
  • คุณพลาดสิ่งสำคัญที่สุดไปหนึ่งอย่าง คือ usability