ฉันไม่ใช่วิศวกรซอฟต์แวร์
(huronbikes.mataroa.blog)- การปฏิเสธอัตลักษณ์ว่าเป็น วิศวกรซอฟต์แวร์ เริ่มต้นจากคำประเมินเมื่อ 23 ปีก่อนที่ว่า “เป็นแฮ็กเกอร์ที่ดี แต่ไม่ใช่วิศวกร”
- กระบวนทัศน์เอเจนต์ ให้ความรู้สึกเหมือนเป็นวิธีใช้โปรแกรมที่ไม่เป็นเชิงกำหนดแน่นอนมาสร้างโปรแกรมที่ควรต้องเป็นเชิงกำหนดแน่นอน
- ความเชื่อที่มีต่อโค้ดอยู่ที่ ความอ่านง่าย, ความเข้าใจได้, ประสิทธิภาพ, ความสามารถในการให้เหตุผล, และความสามารถในการทำซ้ำที่อินพุตเดียวกันต้องให้เอาต์พุตเดียวกัน
- agentic user flows ในที่ทำงานและ KPI การใช้งาน AI ถูกมองว่าเป็นแนวทางที่ให้ความสำคัญกับตัวชี้วัดและอินพุตภาษาธรรมชาติมากกว่าโค้ดที่ดี
- ภาพอนาคตของอุตสาหกรรม AI ดูเหมือนจะไม่ได้หยุดแค่การแทนที่การพัฒนาซอฟต์แวร์ แต่กำลังจินตนาการถึงการสร้าง คูเมืองล้อมรอบความคิดเอง
วิศวกรรมซอฟต์แวร์และกระบวนทัศน์เอเจนต์
- ท่าทีที่ตัดตัวเองออกจากอัตลักษณ์ของ วิศวกรซอฟต์แวร์ เริ่มจากประสบการณ์เมื่อ 23 ปีก่อนที่ได้ยินจากเพื่อนร่วมงานว่าเป็น “แฮ็กเกอร์ที่ดี” แต่ไม่ใช่วิศวกร
- ช่วงหลังมานี้ “กระบวนทัศน์เอเจนต์ แบบใหม่” ดูคล้ายกับการขอให้เครื่องจักรอย่าง Waylon Smithers อย่าทำพลาด แล้วนำผลลัพธ์นั้นไปห่อหุ้มว่าเป็นวิศวกรรมซอฟต์แวร์ระดับผู้เชี่ยวชาญ
- วิธีเขียนโปรแกรมที่ควรต้องเป็นเชิงกำหนดแน่นอนด้วยโปรแกรมที่ให้ผลลัพธ์ไม่เป็นเชิงกำหนดแน่นอน กำลังถูกเสนอให้เป็นอนาคตของวิศวกรรมซอฟต์แวร์
- ความเชื่อพื้นฐานที่มีต่อโค้ดยังคงอยู่ที่ ความอ่านง่าย, ความเข้าใจได้, ประสิทธิภาพ, ความสามารถในการให้เหตุผลที่เพียงพอ, และความสามารถในการทำซ้ำที่อินพุตเดียวกันให้เอาต์พุตเดียวกัน
- ในระบบจริง ความสามารถในการทำซ้ำก็ยากอยู่แล้ว ดังนั้นการเขียนโค้ดเองไม่ควรถูกสร้างขึ้นบน “ผืนทรายที่เคลื่อนไหวตลอดเวลา”
- รายละเอียดอย่างผลกระทบของวิวที่ประกอบด้วยซับคิวรีย่อยที่เชื่อมกันและนิพจน์การรวมต่อ ประสิทธิภาพของคิวรี, การกลับด้านของการควบคุม (Inversion-of-Control), และการออกแบบที่แยกฟังก์ชันออกจากเมธอดเพื่อให้ทดสอบแยกได้อย่างอิสระ ยังคงสำคัญเสมอ
ความไม่ไว้วางใจต่อกระแสการพัฒนาที่มี AI เป็นศูนย์กลาง
- agentic user flows ที่ถูก要求ในที่ทำงานมีความหมายไม่ชัดเจน และก็ยากจะเชื่อได้ว่ากล่องข้อความสำหรับป้อนภาษาธรรมชาติจะดีกว่าการเลือกจากชุดตัวเลือกเล็ก ๆ อย่างไร
- มีความเคลื่อนไหวที่จะใช้เอเจนต์ในทุกขั้นตอนของวงจรชีวิตการพัฒนาซอฟต์แวร์ และถึงขั้นมีคนบอกว่าการเขียนโค้ดด้วยมือต่อไปจะถูกมองเหมือนการเขียน COBOL
- เอเจนต์ดูเหมือนเป็นตัวห่อพรอมป์ต์ LLM ที่ประเมินเอาต์พุตตามบริบท และเอาต์พุตจริงก็มักให้ความรู้สึกว่ายังไม่เพียงพอ
- ปริมาณการใช้งาน AI ถูกติดตามเป็น KPI แต่ตลอด 23 ปีที่ผ่านมา การเขียนโค้ดที่ดีสำคัญกว่าตัวชี้วัด KPI
- โค้ดที่เคยเขียนในอดีตเคยถูกประเมินว่า “ดูเหมือนเขียนโดยคนเรียนคณิตศาสตร์มา” และผู้เขียนรับคำนี้เป็นคำชมอย่างมาก
- การอิมพลีเมนต์ของสตาฟฟ์ซอฟต์แวร์เอนจิเนียร์คนหนึ่งในที่ทำงานเดียวกันไม่มี explicit interface, เปิดเผย DI container เป็นสมาชิก public static และใช้การตั้งค่าแบบ CSV ไม่ใช่เพราะเหมาะกับข้อมูลแบบตาราง แต่เพราะ “ผู้ใช้ฝั่งธุรกิจใช้งานง่าย”
- การพูดว่าอิมพลีเมนต์นั้นแย่มากทำให้เกิดปัญหา และเหตุการณ์นี้ก็นำไปสู่ข้อสรุปเชิงเสียดสีว่าตัวเองคงไม่ใช่วิศวกรซอฟต์แวร์
- แม้จะได้รับคำแนะนำจากคนที่มองว่าฉลาดอยู่สองครั้งว่า AI คืออนาคตของการเขียนซอฟต์แวร์และของทั้งอุตสาหกรรม จึงควรยอมรับมัน แต่ท่าทีแบบนั้นก็ดูสะเพร่า
- ซอฟต์แวร์ AI ที่ได้ลองใช้ให้ความรู้สึกว่าไม่ได้ช่วยกระบวนการคิด แต่กลับรบกวนหรือเข้ายึดมันไปอย่างจริงจัง และการยึดครองเช่นนั้นก็น่ากังวล
- ผู้นำบริษัท AI รายใหญ่พูดถึงอนาคตของอุตสาหกรรมการพัฒนาซอฟต์แวร์อย่างร่าเริง พร้อมประกาศว่าผลิตภัณฑ์ของพวกเขาจะส่งผล รุนแรงต่อการจ้างงาน และใช้คำว่า “intelligence too cheap to meter”
- อนาคตนั้นน่ากลัวไม่ใช่เพราะเครื่องจักรจะเปลี่ยนทุกคนให้เป็นคลิปหนีบกระดาษ แต่เพราะพวกเขากำลังจินตนาการถึงการสร้าง คูเมืองล้อมรอบความคิดเอง
1 ความคิดเห็น
ความคิดเห็นจาก Lobste.rs
ในหนังสือของ Mary Walton เกี่ยวกับ W. Edwards Deming มีเรื่องเล่าแบบนี้อยู่ เรื่องของคนงานโรงงานคนหนึ่งที่เครื่องเสียจนผลิตได้แต่ ของเสีย เขารายงานไปแล้วแต่ฝ่ายซ่อมบำรุงมาช้า ระหว่างที่กำลังจะซ่อมเอง หัวหน้าก็เดินมาบอกให้เดินเครื่องต่อไป
สุดท้ายมันก็คือคำสั่งให้ “ผลิตของเสียต่อไป” และเขาพูดว่า “แล้ว ความภาคภูมิใจในฐานะคนทำงาน ของผมอยู่ตรงไหน? ถ้าหัวหน้าปฏิบัติกับผมดีได้สักครึ่งหนึ่งของที่ปฏิบัติกับเครื่องจักรก็คงดี” เขาไม่ได้อยากผลิตของเสียแล้วรับเงินจากมัน
น่าอ่านไหม?
แม้ประสบการณ์ของผมจะน้อยกว่าผู้เขียนมาก แต่ช่วงต้นอาชีพผมก็เคยพยายามย้ายบาง workflow ออกจาก CSV เพราะปัญหาหลายอย่างของ CSV แล้วตอนนั้นก็ได้รับคำตอบว่า “สำหรับ workflow ทางธุรกิจ CSV ง่ายกว่า”
ตอนนั้นผมก็รู้สึกเหมือนผู้เขียนว่าคำตอบนี้แย่มาก แต่พอเวลาผ่านไปก็เริ่มคิดว่าการตัดสินแบบนั้นน่าจะใกล้เคียงกับความถูกต้องมากกว่า
ถ้ายังทุกข์ใจกับความเห็นโง่ ๆ แนว “มีคนเคยบอกเมื่อ 23 ปีก่อนว่าฉันไม่ใช่วิศวกรซอฟต์แวร์” วิธีแก้ก็คือเลิกใส่ใจความเห็นของคนอื่นขนาดนั้น
ถ้าคุณหงุดหงิดกับนโยบายโง่ ๆ ของนายจ้างหรือความไม่เอาจริงเอาจังของเพื่อนร่วมงาน ก็ไปหาบริษัทอื่นได้ โลกนี้มีคนอยู่ 8 พันล้านคน หลายคนอยากให้คอมพิวเตอร์ช่วยทำอะไรบางอย่าง และในจำนวนนั้นก็มีอีกมากที่ยอมจ่ายค่าการเขียนโปรแกรม
มันฟังดูเหมือน “ตอนเริ่มทำงานที่ร้านเบเกอรี่ครั้งแรก มีเพื่อนร่วมงานบอกว่าครัวซองต์เป็นแผนสมคบคิดของ Big Dairy เพื่อขายเนยเพิ่ม ผมเลยเอามันมาเป็นรากฐานของโลกทัศน์ และสรุปว่าไม่มีทางทำงานร้านเบเกอรี่อีกต่อไปได้” ถ้าไม่มีการบอกอายุของผู้เขียน ผมคงเดาว่าเป็นเด็กมัธยม แต่ถ้าพูดถึงเรื่องเมื่อ 23 ปีก่อน ก็เลยวัยนั้นมานานมากแล้ว
ใจความไม่ได้อยู่ที่ผู้เขียนไม่ได้เป็นวิศวกรซอฟต์แวร์จริง ๆ อันที่จริงเขาน่าจะทำงานภายใต้ตำแหน่งนั้นมานานมากแล้ว ใจความคือท่าทีที่เขาปฏิเสธจะนิยามตัวเองด้วยตำแหน่งนั้น เป็น ปฏิกิริยา ต่อสิ่งที่อุตสาหกรรมนี้เปลี่ยนไปมากกว่า
มันเหมือนกำลังพูดว่า “นี่ไม่ใช่วิศวกรรม แต่มันคือเรื่องเหลวไหล ถ้าการเป็นวิศวกรซอฟต์แวร์หมายถึงแบบนี้ งั้นฉันก็ไม่ใช่แบบนั้น”
โดยส่วนตัวผมเข้าใจความรู้สึกนั้นดี หลายครั้งผมรู้สึกว่าการเรียกสิ่งที่พวกเราทำกันในฐานะนักพัฒนาซอฟต์แวร์ว่า “วิศวกรรม” เป็นการดูหมิ่นสาขาวิศวกรรมอื่น ๆ โดยเฉพาะเมื่อเรายังแทบไม่สนใจสิ่งที่เราสร้างกันจริง ๆ
วิศวกรโยธามองเรื่องสะพานถล่มเป็นเรื่องร้ายแรงมาก และถ้าเกิดการพังทลายครั้งใหญ่ ทั้งวงการจะตอบสนอง เรียนรู้ และพยายามไม่ให้เกิดขึ้นอีก แต่ฝั่ง “วิศวกร” ซอฟต์แวร์กลับสามารถทำ production ล่มซ้ำแล้วซ้ำอีกจากสาเหตุที่ป้องกันได้ทั้งหมด และยังเขียนมันลงเรซูเม่ว่าเป็นความสำเร็จได้อีก
สำหรับกระแสของวิศวกรรมซอฟต์แวร์ในตอนนี้ ที่ไม่สนใจโค้ดที่ deploy จริง และมีแนวโน้มจะมอบหมายการเขียนนั้นให้ “สติปัญญา” แบบอื่น คุณก็คงเดาได้ว่าผมคิดอย่างไร
ผมเข้าใจว่าทำไมเรื่องแบบนี้ถึงเกิดขึ้น และไม่อยากอ้างว่าตัวเองมีคำตอบครบทุกอย่างว่าควรทำอย่างไร แต่เราไม่ควรแสร้งทำว่ามันเป็นงานจริงจัง เป็น “วิศวกรรม” แต่อย่างใด