วิศวกรประเภทที่บอกว่า “ทำไม่ได้” เฉยๆ เป็นปรากฏการณ์ของยุค ZIRP
(seangoedecke.com)- วิศวกรประเภทที่บอกว่า “ทำไม่ได้” เฉยๆ คือภาพต้นแบบของสายซีเนียร์ที่โดยพื้นฐานจะคอยสกัดการเปลี่ยนโค้ด ชะลอฟีเจอร์ที่ซับซ้อน และทำให้มีการเขียนโค้ดให้น้อยที่สุดเท่าที่ทำได้
- ในช่วง ZIRP การสูญเสียประสิทธิภาพการทำงานมีความสำคัญน้อยกว่า เพราะอัตราดอกเบี้ยต่ำและการจ้างงานที่ขยายตัว ทำให้บทบาทที่คอยกันข้อเสนอทางเทคนิคสุดโต่งมีประโยชน์ต่อบริษัท
- หลังดอกเบี้ยปรับขึ้น บริษัทเทคโนโลยีปลดวิศวกรออก 5~20% และหันมาให้ความสำคัญกับรายได้มากกว่าราคาหุ้น ทำให้เกราะคุ้มกันที่คอยพูดว่า “ทำไม่ได้” แทนผู้บริหารลดลง
- LLM เพิ่มแรงกดดันด้วย PR ที่สร้างโดย AI และโค้ดที่ใช้งานได้ดีพอสมควร แต่การเปลี่ยนแปลงหลักไม่ใช่ AI หากเป็นแรงจูงใจทางเศรษฐกิจที่เปลี่ยนไปหลังการสิ้นสุดของ ZIRP
- บทบาทนี้ไม่ได้หายไป แต่เหมาะกับงานในขอบเขตของ วิศวกรรมล้วนๆ มากกว่า และต้องยอมรับขอบเขตที่แคบลงกับการมองเห็นที่น้อยลงเมื่อเทียบกับยุค 2010s
บทบาทของ “วิศวกรที่บอกว่าแค่ทำไม่ได้”
- วิศวกรประเภทที่บอกว่า “ทำไม่ได้” เฉยๆ เป็นภาพต้นแบบที่อยู่ระหว่างวิศวกรซีเนียร์กับสตาฟ โดยใกล้เคียงกับบทบาทที่คอยชะลอการพัฒนาฟีเจอร์ สกัดการเปลี่ยนแปลงที่เพิ่มความซับซ้อน และทำให้มีการเขียนโค้ดให้น้อยที่สุดเท่าที่จะทำได้
- ฝั่งตรงข้ามคือ วิศวกรประเภทที่บอกว่า “ทำได้” เฉยๆ ซึ่งให้ความสำคัญกับการเดินหน้าอย่างรวดเร็ว อนุมัติการเปลี่ยนโค้ดเป็นค่าเริ่มต้น ให้ความสำคัญกับ MTTR มากกว่า MTBF และมีแนวโน้มจะปล่อยโค้ดจำนวนมาก
- วิศวกรส่วนใหญ่อยู่ระหว่างสองขั้วนี้ แต่ประเด็นที่โฟกัสที่นี่คือวิศวกรที่นิยามตัวเองอย่างหนักแน่นกับบทบาท “ทำไม่ได้”
- ในยุค AI ไม่เพียงต้องปฏิเสธ PR ของวิศวกรจูเนียร์จำนวนมาก แต่ยังต้องปฏิเสธโค้ดที่ AI สร้างขึ้นอีกมากมาย และบางครั้งก็เป็นโค้ดที่ผู้จัดการหรือ VP สร้างเองจนปฏิเสธได้ยากในเชิงการเมือง
- เป็นครั้งแรกในเส้นทางอาชีพที่พวกเขาถูกกดดันอย่างหนักให้ลดมาตรฐานและพูดว่า “ได้” แต่สาเหตุหลักอยู่ที่ การสิ้นสุดของ ZIRP มากกว่าตัว AI เอง
สภาพแวดล้อมที่ ZIRP สร้างขึ้น
- ZIRP ย่อมาจาก “นโยบายดอกเบี้ยเป็นศูนย์” และหมายถึงยุคการพัฒนาซอฟต์แวร์ระหว่างปี 2008 ถึง 2022 ที่ธนาคารปล่อยกู้ให้บริษัทในอัตราดอกเบี้ยใกล้ศูนย์
- นักลงทุนเทเงินกู้ดังกล่าวไปแทบทุกอย่าง และบริษัทเทคโนโลยีก็มีแรงจูงใจสูงที่จะจ้างวิศวกรต่อเนื่องเพื่อทำโครงการที่มีความเสี่ยงต่ำและคาดหวังผลตอบแทนสูง
- บริษัทที่ประสบความสำเร็จขยายจำนวนวิศวกรจากหลักสิบไปเป็นหลักพัน และมอบหมายงานอย่างโปรเจกต์โอเพนซอร์สที่เป็นเรื่องรอบข้าง การย้ายเทคโนโลยีแบบไม่รู้จบ หรือการเขียนระบบใหม่ด้วยภาษาอื่น
- สำหรับวิศวกรซอฟต์แวร์ นี่คือช่วงเวลาที่มีอำนาจต่อรองสูง และแทบจะทำงานแบบไหนก็ยังได้รับค่าตอบแทนสูง
- ผู้บริหารมีทีมที่โตเร็วเกินกว่าจะใส่ใจรายละเอียดได้ และเพราะจำนวนวิศวกรที่เพิ่มขึ้นเองก็ช่วยราคาหุ้น จึงไม่ได้มองหลายกิจกรรมว่าเป็นปัญหาใหญ่
- แต่เมื่อมีวิศวกรมากเกินไปเคลื่อนไหวได้อย่างอิสระ ระบบก็อาจกลายเป็นสิ่งที่ควบคุมไม่ได้ และนี่เองที่ทำให้ “วิศวกรประเภทที่บอกว่า “ทำไม่ได้” เฉยๆ” มีประโยชน์ต่อบริษัท
ทำไมคำว่า “ทำไม่ได้” จึงมีคุณค่าในยุค ZIRP
- เพราะ การสูญเสียประสิทธิภาพการทำงาน ไม่ใช่ปัญหาใหญ่ บริษัทจึงทนได้แม้วิศวกรครึ่งหนึ่งจะติดอยู่ในลูปเสนอการเปลี่ยนแปลงแล้วถูกปฏิเสธ
- วิธีนี้ยังมีผลทำให้วิศวกรไม่เข้าไปกระทบระบบแกนหลักของธุรกิจด้วย
- มันยังช่วยควบคุม วิศวกร 5% ที่คลั่งเสรีภาพทางเทคนิคจนเสนอแนวคิดสุดโต่ง เช่น ย้ายไปใช้ฐานข้อมูลทำเอง
- ชื่อเสียงว่าเป็นบริษัทที่มีมาตรฐานทางเทคนิคสูงมากก็เป็นผลดีต่อการจ้างงาน และในยุค ZIRP ทุกบริษัทเทคโนโลยีก็กำลังเปิดรับคนอยู่เสมอ
- คำพูดที่ว่า “จูเนียร์สร้างโค้ดเยอะ ซีเนียร์สร้างน้อย ส่วนสตาฟลบโค้ด” ฟังดูน่าดึงดูดเพราะทำให้ผู้เชี่ยวชาญแทบไม่ต้องขยับตัว แต่ก็ไม่ถูกต้องนัก เพราะวิศวกรสตาฟเองก็ควรสามารถสร้างโค้ดที่ใช้งานได้จริงจำนวนมากอย่างรวดเร็วเมื่อจำเป็น
การเปลี่ยนแปลงหลัง ZIRP สิ้นสุด
- เมื่อธนาคารขึ้นดอกเบี้ย บริษัทเทคโนโลยีแทบทั้งหมดก็ปลดวิศวกรออกทันที 5~20%
- การรักษาองค์กรวิศวกรรมที่พองตัวไว้เพื่อดันราคาหุ้นไม่คุ้มกำไรอีกต่อไป และบริษัทต้องหาเงินให้ได้จริง
- คำว่า “ต้องหาเงิน” ในที่นี้ไม่ได้หมายความว่าจำเป็นต้องมีกำไร แต่หมายถึงอย่างน้อยต้องสร้างรายได้
- การยอมรับต่อสาธารณะว่าบริษัทสั่งให้วิศวกรหลายร้อยคนทำงานที่ไม่ก่อรายได้ ไม่ใช่คำอธิบายเรื่องการปลดคนที่ดีนัก
- การสิ้นสุดของ ZIRP เกิดขึ้นใกล้เคียงกับการมาของ ChatGPT ทำให้บริษัทสามารถอธิบายการปลดคนว่าเป็นเพราะพลังของ AI ได้
- ข้อความแบบ “ด้วยเทคโนโลยีพลิกโลกนี้ เราจะส่งมอบมูลค่าได้มากขึ้น 10 เท่าด้วยวิศวกรเพียงครึ่งหนึ่ง” ฟังดูทรงพลัง แต่ถ้าเป็นจริง เหตุใดจึงไม่เก็บวิศวกรไว้เพื่อส่งมอบมูลค่า 20 เท่าเสียเลย
บริษัทที่โฟกัสมากขึ้นและเกราะคุ้มกันที่ลดลง
- บริษัทเทคโนโลยีมีสมาธิกับสิ่งที่ทำมากกว่าช่วงใดในรอบ 20 ปี และตอนนี้กำลังไล่ล่าความสามารถกับฟีเจอร์ใหม่ๆ ที่ทำเงินได้อย่างสิ้นหวัง มากกว่าจะทำเรื่องสุ่มๆ จำนวนมาก
- สภาพแวดล้อมใหม่นี้ไม่เป็นมิตรต่อ วิศวกรประเภทที่บอกว่า “ทำไม่ได้” เฉยๆ อย่างชัดเจน
- แต่ก่อนวิศวกรแบบนี้ได้รับการสนับสนุนโดยนัยจากผู้บริหาร และแม้ใครจะบ่นก็ยังอาจจบลงด้วยประโยคประมาณว่า “เรารู้ว่าเขาทำอะไรอยู่ ถ้าบอกว่าไม่ได้ก็เชื่อเขา”
- ตอนนี้แรงสนับสนุนนั้นหายไปแล้ว และพฤติกรรมแบบเดิมกลับถูกผู้บริหารวิจารณ์หรือแม้แต่กลับคำอย่างแข็งขัน
- พวกเขาถูกบอกให้เป็นทีมเพลเยอร์มากขึ้น ให้หาวิธีพูดว่าได้ หรือไม่ก็ไม่ได้รับคำปรึกษาในเรื่องตัดสินใจสำคัญอีกต่อไป
- พฤติกรรมที่เคยได้รับรางวัลก่อนปี 2022 กำลังนำไปสู่การประเมินผลงานที่แย่ และบางครั้งการเปลี่ยนทางวัฒนธรรมก็ตามหลังการเปลี่ยนแรงจูงใจทางเศรษฐกิจอยู่หลายปี
- การเปลี่ยนแปลงนี้ไม่ได้พึ่ง AI และแม้ LLM จะไม่ได้เกิดขึ้นในทศวรรษนี้ บริษัทก็คงยังปลดวิศวกรอยู่ดี และวิศวกรที่ทำหน้าที่พูดว่า “ทำไม่ได้” ก็คงยังสับสนว่าทำไมพฤติกรรมเดิมจึงถูกลงโทษ
แรงกระแทกที่ AI ซ้ำเติม
- หาก ZIRP ยังไม่จบลง LLM อาจกลายเป็นเหตุผลสนับสนุนที่หนักแน่นให้กับ “วิศวกรประเภทที่บอกว่า “ทำไม่ได้” เฉยๆ”
- บริษัทที่ไม่อาจตั้งคำถามกับการเขียนโค้ดแบบมี AI ช่วยได้ทั้งต่อสาธารณะและภายในองค์กร คงต้องพึ่งพาวิศวกรกลุ่มนี้อย่างมากเพื่อกันไม่ให้สึนามิโค้ด AI ถาโถมใส่บริษัท
- แต่ในความเป็นจริง LLM กลับทำหน้าที่เหมือนการซ้ำเติมแผลเดิม
- พวกเขาต้องทนดู PR ที่ AI สร้างขึ้น ที่เมื่อก่อนคงถูกบล็อกไว้ถูก merge เข้าไป และยังถูกเรียกร้องให้ใช้เครื่องมือแบบนั้นด้วย
- ที่แย่กว่านั้นคือเครื่องมือ AI โดยรวมแล้วใช้งานได้จริง
- มันยังไม่ได้ก่อหายนะแบบชัดเจน โค้ดอาจสะอาดน้อยลงเล็กน้อยและความเข้าใจต่ำลงหน่อย แต่ก็ใช้งานได้ดีพอ
- โดยเฉพาะในสภาพแวดล้อมที่บริษัทกำลังลองสิ่งใหม่จำนวนมากแล้วทิ้งสิ่งที่ล้มเหลว โค้ดแบบ “ดีพอ” ก็ใช้ได้ผล
- ต่อให้มองว่าอุบัติเหตุช่วงหลังเพิ่มขึ้นจริง ก็อาจเป็นเพราะการมองผิด หรือปัจจัยอื่นหลัง ZIRP จบ เช่น ความเร็วที่สูงขึ้นและการปลดคน อาจเป็นสาเหตุสำคัญกว่า
- “วิศวกรประเภทที่บอกว่า “ทำไม่ได้” เฉยๆ” จึงเผชิญภัยคุกคามไม่ใช่แค่ต่อการทำมาหากิน แต่ต่ออัตลักษณ์ของตนเองด้วย
- พวกเขาต้องยอมรับว่าบทบาททางเทคนิคนี้เคยพึ่งพาสภาพเศรษฐกิจอันผิดปกติอย่างมากของอุตสาหกรรมเทคโนโลยี หรือไม่ก็ต้องยืนกรานต่อไปว่าจุดจบกำลังใกล้เข้ามาเต็มที
วิศวกรรมล้วนๆ และวิศวกรรมที่ไม่ล้วน
- “วิศวกรประเภทที่บอกว่า “ทำไม่ได้” เฉยๆ” จะไม่หายไป แต่ก็ไม่ได้เหมาะกับทุกบริษัทเทคโนโลยีอีกต่อไป
- Pure and impure software engineering แยก วิศวกรรมล้วนๆ ว่าเป็นงานที่มีขอบเขตชัดเจนและมีเป้าหมายทางเทคนิคเป็นหลัก เช่น คอมไพเลอร์หรือ language runtime
- ส่วน วิศวกรรมที่ไม่ล้วน คือ งานที่ขอบเขตไม่ชัดและมีเป้าหมายที่ขับเคลื่อนโดยลูกค้า เช่น การลองทำฟีเจอร์ใหม่ที่ไม่แน่ว่าจะสำเร็จหรือไม่
- ในยุค ZIRP บริษัทเทคโนโลยีทำงานแบบล้วนๆ อย่าง React) มากกว่ามาก และยังมีแนวโน้มปฏิบัติต่องานที่ไม่ล้วนราวกับเป็นงานล้วนด้วย
- “วิศวกรประเภทที่บอกว่า “ทำไม่ได้” เฉยๆ” เหมาะกับงานล้วนๆ มาก
- เพราะโค้ดเบสแบบล้วนต้องการมาตรฐานคุณภาพที่สูงกว่ามาก และทนรอบการพัฒนาที่ช้ากว่าได้
- บริษัทเทคโนโลยีส่วนใหญ่ยังคงมีงานลักษณะนี้อยู่บ้าง เช่น งานโครงสร้างพื้นฐานแกนหลัก
- งานนี้จำเป็น แต่ไม่ได้ต้องการทีมวิศวกรรมขนาดยักษ์ และก็มักไม่ค่อยได้รับ สปอตไลต์
- หากยังอยากเป็น “วิศวกรประเภทที่บอกว่า “ทำไม่ได้” เฉยๆ” ก็ควรย้ายไปทำบทบาทลักษณะนี้ แต่ต้องยอมรับขอบเขตที่จำกัดกว่ายุค 2010s
ข้อถกเถียงและมุมมองที่เติมเต็ม
- บน lobste.rs และ Reddit มีคำวิจารณ์ว่า ผลกระทบของโค้ด AI ต้องใช้เวลาจึงจะเห็นชัด จึงยังเร็วเกินไปที่จะสรุปว่า “โดยรวมใช้งานได้จริง”
- ข้อโต้แย้งว่า “ยังเร็วเกินไปจะพูด” เป็นสิ่งที่ยากจะบอกว่าผิด แต่ก็ดูชัดว่าโค้ด AI ยังไม่ได้อันตรายถึงขั้นร้ายแรงในทันที
- ยังมีข้อโต้แย้งด้วยว่าภาพต้นแบบ “วิศวกรประเภทที่บอกว่า “ทำไม่ได้” เฉยๆ” มีอยู่มาหลายสิบปีก่อน ZIRP แล้ว โดยยก Linus Torvalds เป็นตัวอย่าง
- มุมมองนี้ไม่ได้บอกว่าภาพต้นแบบดังกล่าวถูก ZIRP สร้างขึ้น แต่บอกว่า ZIRP ขยายช่องว่างของบทบาทนี้ให้กว้างขึ้นอย่างไม่เป็นธรรมชาติ และตอนนี้มันกำลังหดกลับลง
- ยังมีข้อโต้แย้งว่าการใช้ภาษาแบบ dynamic และเครื่องมือ observability/feature flag ที่ยังไม่สุกงอม เป็นสิ่งที่สร้างช่องว่างให้บทบาทนี้
- บน Hacker News ก็มีหลายความเห็นว่าทฤษฎีนี้ยังต้องการหลักฐานที่แน่นหนากว่านี้
- มุมมองนี้ตั้งอยู่บนหน้าต่างเล็กๆ ของประสบการณ์ส่วนบุคคล และการเหมารวมว่าอุตสาหกรรมก่อนและหลัง ZIRP เป็นอย่างไรอาจต่างกันไปในแต่ละคน
- หากจะตรวจสอบเรื่องนี้ อาจสำรวจวิศวกรระดับซีเนียร์ขึ้นไปหลายร้อยคนในปี 2010 และ 2026 แล้วถามว่าในหนึ่งสัปดาห์พวกเขาพูดว่า “ทำไม่ได้” กี่ครั้ง และคำปฏิเสธเหล่านั้นถูกกลับคำบ่อยแค่ไหน
- การพูดว่า “ทำไม่ได้” เป็นสิ่งจำเป็นทั้งก่อนและหลัง ZIRP แต่หลัง ZIRP ความต่างคือผู้บริหารเรียนรู้ทักษะนี้ได้อย่างรวดเร็ว ทำให้ความจำเป็นของกลุ่มวิศวกรที่คอยพูดแทนลดลง
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
โค้ดคือหนี้ การที่วิศวกรพูดว่า “ไม่” ไม่ใช่เพราะยึดติดกับคุณภาพโค้ดแบบอัตวิสัย แต่เป็นเพราะ ต้องการลดความซับซ้อน
ทุกวันนี้ฝ่ายบริหารมักเข้าใจคำว่า “คุณภาพ” ผิด คุณภาพหมายถึงปริมาณความพยายามที่เหมาะสมในการสร้างผลิตภัณฑ์ให้ได้เร็วที่สุดและด้วยต้นทุนต่ำที่สุด โดยคำนึงด้วยว่าทีมวิศวกรจะสามารถเพิ่มหรือแก้ไขโค้ดได้ง่าย
มีคำอธิบายที่ดีกว่านี้อยู่ที่นี่: https://www.nair.sh/guides-and-opinions/communicating-your-e...
ความพยายามจะทำให้สิ่งที่คนนั้นทำและเหตุผลของมันกลายเป็นกฎตายตัวเป็นลายลักษณ์อักษร ย่อมล้มเหลวอยู่แล้ว
ปัญหาของ เศรษฐศาสตร์บนโต๊ะ แบบนี้คือมันสร้างเหตุผลได้ทั้งสองทาง
คุณจะเรียกมันว่า “การสิ้นสุดยุคดอกเบี้ยศูนย์และการผงาดขึ้นของวิศวกรสายปฏิเสธล้วน ๆ” ก็ได้ ต้นทุนของเงินทุนแพงขึ้น บริษัทจึงต้องใช้เงินนั้นอย่างฉลาดขึ้น และยิ่งต้องการ วิจารณญาณของวิศวกรที่กล้าพูดว่าไม่ เพื่อไม่ให้เงินถูกเผากับเรื่องไม่จำเป็น
ยิ่งอ่านก็ยิ่งคิดว่า “คำศัพท์เท่ ๆ มีมาครบ ทั้งยุค ZIRP ทั้งวิศวกรสาย no แต่แม้จะดูเหมือนมีอินไซต์ พอลงลึกแล้วกลับไม่ตรงกับประสบการณ์ของฉันในสนามซอฟต์แวร์ยุคนั้นเลย และยังวินิจฉัยการเปลี่ยนแปลงครั้งใหญ่จาก AI ตอนนี้ได้ไม่ถูกด้วย” กล่าวคือมันฟังเหมือน คำพูดตามกระแสไร้สาระ และก็ดีที่แม้ตัวบทความจะไม่มีปุ่มโหวตลง แต่คอมมูนิตี้ช่วยชี้ให้เห็น
ต่อให้โปรเจกต์ AI ล้มเหลวก็ไม่เป็นไร ตราบใดที่มันล้มเหลวได้เร็วพอแล้วไปทำอย่างอื่นต่อได้ การทำให้ถูกตั้งแต่แรกจึงสำคัญเฉพาะในโปรเจกต์ระยะยาวที่ต้องลงทุนตั้งต้นสูง
การพูดว่า “ถึงครึ่งหนึ่งของวิศวกรในบริษัทจะติดอยู่ในลูปที่เสนอการเปลี่ยนแปลงไม่รู้จบแล้วโดนปฏิเสธตลอด ก็ไม่เป็นไรเลย เพราะยังไงก็ไม่จำเป็นต้องมีประสิทธิผล และอย่างน้อยวิธีนั้นก็ไม่ไปกระทบระบบแกนหลักของธุรกิจ” นี่ก็เป็นมุมมองแบบหนึ่งแหละ ค่อนข้าง ถากถาง
มองย้อนกลับไปมันฟังดูประชดประชัน แต่ในตอนนั้นคนอธิบายข้อเท็จจริงชุดเดียวกันนี้ด้วยวิธีอื่นที่กระทบความรู้สึกคนให้น้อยกว่า
คนที่ทำ Metaverse อยู่ใน Facebook เป็นกำลังหลักที่สร้างต้นแบบโมเดลธุรกิจใหม่ หรือเป็นแค่คนที่ทำงานให้ดูยุ่ง ๆ กันแน่ กว่าจะรู้ชัดก็ต้องรอทีหลัง
นี่เป็นการตีความที่ค่อนข้างสุดโต่ง ถ้า ZIRP จบลงแล้วทำให้ทุกอย่างโฟกัสมากขึ้น ข้อสรุปที่เป็นธรรมชาติก็น่าจะเป็นว่าไม่ใช่ต้องปฏิเสธให้น้อยลง แต่ต้อง ปฏิเสธให้มากขึ้น ไม่ใช่หรือ?
ถ้าจะอ้างว่า ZIRP สร้างงานปลอมสารพัดแบบขึ้นมา และยังสร้างลำดับชั้นเพื่อควบคุมงานปลอมนั้นอีก ก็ต้องบิดเหตุผลกันพอสมควร
ชอบการแบ่งว่าเป็นวิศวกรแบบ “yes ล้วน ๆ” กับ “no ล้วน ๆ” และมุมมองที่ให้ MTTR สำคัญกว่า MTBF
ฉันชัดเจนว่าอยู่ฝั่ง “yes ล้วน ๆ” แต่ก็มีข้อแม้อยู่ว่า การเลือกสถาปัตยกรรมที่ไม่ดีอาจเจ็บปวดมากเวลาต้องมาแก้ทีหลัง และฟีเจอร์ก็มักแก้ยากกว่ามากหลังมีผู้ใช้แล้วเมื่อเทียบกับก่อนเปิดตัว ดังนั้นฉันก็เป็นพวก “no นิดหน่อย” หรืออย่างน้อยก็ “ขอคิดก่อนสักแป๊บ” เหมือนกัน
สมดุลระหว่าง “yes ล้วน ๆ” กับ “no ล้วน ๆ” ขึ้นอยู่กับโปรเจกต์มาก ถ้าเป็นการเงินหรือการแพทย์ ค่าเริ่มต้นเป็น “ไม่” อาจดีกว่า แต่ถ้าเป็นไอเดียสตาร์ตอัปแปลก ๆ ก็ YOLO
การขอเวลาเพื่อจัดระเบียบจริง ๆ แล้วก็เท่ากับ การพูดว่าไม่ หัวหน้าฝ่ายพัฒนาควรมีอำนาจนั้นและควรใช้มันจริง ๆ ถ้าไม่เคยใช้เลย ก็แทบไม่ต่างจากไม่มีอำนาจนั้น
อย่ากลายเป็นวิศวกรที่พูดแต่ “ไม่” โดยไม่มีทางเลือกอื่น นั่นไม่ใช่วิศวกรที่ดี แต่คือคนขี้เกียจที่อยากดูดี
บ่อยครั้งวิศวกรมักเสนอทางออกที่แม้ไม่อุดมคติเพราะข้อจำกัดของระบบ legacy แต่ก็จำเป็น และไม่ คุณไม่สามารถเขียนทั้งระบบใหม่เพื่อทำให้เป็น “วิธีที่ถูกต้อง” ได้ การพูดว่า “ไม่” หรือชี้ว่าทางแก้ไม่สมบูรณ์แบบ ไม่ได้ทำให้คุณกลายเป็น อัจฉริยะเหนือมนุษย์
ในที่ประชุมกับฝั่งธุรกิจ เขาวางท่าข่มคนอื่นเพราะตัวเองเขียนโค้ดเป็น และที่แย่ที่สุดคือเวลาที่ไม่เห็นด้วยกับข้อเสนอ เขา ไม่เคยเสนอทางเลือกเลย ทำงานด้วยยากมาก
นี่แหละมั้งคนแบบ ZIRP ที่บทความนี้กำลังพูดถึง
ถ้า LLM และเอเจนต์ยังมีข้อบกพร่อง ก็มีแนวโน้มหนึ่งที่ขายแนวคิดว่าแทนที่จะรอให้มันดีขึ้น เราควร ลดมาตรฐานลง เหมือนกับที่บอกว่า “ให้โฟกัสที่ MTTR”
โค้ดแย่เหรอ? ก็อย่าอ่าน อย่าตรวจ และเอาคนที่เป็นคอขวดออกจากลูปเสีย เรื่องเล่าแบบนี้กำลังแพร่กระจายอยู่ทั่วไป
เทคโนโลยีนี้มีประโยชน์มากพอสมควร ดังนั้นแทนที่จะคอยแก้แค่อาการ อยากให้โฟกัสกับการปรับปรุงเครื่องมือ วิธีทำงานกับมันให้ดีขึ้น และปรับกระบวนการให้สอดคล้องกันมากกว่า
มีเรื่องให้ทำได้ไม่รู้จบ แต่ปัญหาคือจะจัดสรรเวลาอย่างไรระหว่างเวลาที่ใช้กับโปรเจ็กต์จริง กับเวลาที่ใช้ไปกับการปรับปรุงเหล่านั้น
เขาบอกว่า “ยิ่งมีวิศวกรมากก็ยิ่งดีกับราคาหุ้น… แต่เมื่อธนาคารขึ้นดอกเบี้ย… การคงองค์กรวิศวกรรมที่อุ้ยอ้ายไว้เพื่อดันราคาหุ้นก็ไม่ทำกำไรอีกต่อไป” แล้วมีกลไกที่เป็นที่รู้จักไหมที่เชื่อม จำนวนวิศวกรซอฟต์แวร์กับราคาหุ้น เข้าด้วยกัน? หรือเป็นแค่ปรากฏการณ์ที่สังเกตได้จากประสบการณ์เฉยๆ?
ที่บอกว่า “เมื่อก่อนแค่บอกไม่รับ PR ที่จูเนียร์วิศวกรเขียนด้วยมือก็พอ แต่ตอนนี้มีโค้ดที่ AI สร้างไหลเข้ามาไม่หยุด และบางส่วนมาจากผู้จัดการกับ VP ที่ปฏิเสธได้ยากในเชิงการเมือง” นี่ช่างโลกพระเจ้า
ผมเคยทำงานในบริษัทเทคใหญ่ แต่ลาออกจากวงการไปก่อน InstructGPT และตัวอื่นๆ จะออกมา เลยไม่เคยเจอกับ การสร้างโค้ดด้วย LLM ภายในองค์กรเลย เรื่องแบบนี้เกิดขึ้นจริงเหรอ? ผู้บริหารระดับสูงและ VP เสนอการเปลี่ยนแปลงโค้ดที่ทำด้วย LLM กันจริงๆ เหรอ? ผมคงทนไม่ไหวแน่
ภาระทางการเมืองก็มีจริง จะให้พูดตรงๆ ว่า “ไม่ได้” ก็พูดยาก และการจะรีวิว PR ยาว 25,000 บรรทัดอย่างมีความหมายก็ค่อนข้างยาก เมื่อมันมาจากคนที่ไม่ค่อยรู้ด้วยซ้ำว่าตัวเองกำลังทำอะไร และตอบคำถามก็ไม่ได้
จะให้ยุติธรรมหน่อย เขาเป็นคนสร้าง liquid และอีกหลายส่วนของ Shopify มาตั้งแต่ช่วงแรกของบริษัท จึงไม่ใช่คนไร้ประสบการณ์ แต่ถึงอย่างนั้นก็เถอะ
ดูเหมือนเป็นสมมติฐานที่ตรวจสอบได้ยาก ถ้าบริษัทหนึ่งกำลังพยายามจะทำอะไรบางอย่างให้สำเร็จ การมีคนที่ช่วยจัดลำดับความสำคัญโดยบอกได้ว่าการตัดสินใจแบบไหนจะก่อให้เกิด ต้นทุนระยะยาว ก็ดูเป็นเรื่องสมเหตุสมผลไม่ใช่หรือ?