ตระหนักไว้เสมอว่ามีคำว่า "Engineer" อยู่ในชื่อตำแหน่งของ "Software Engineer"
.
เป็นสิ่งนึงที่เรียนรู้มาจากอาจารย์ที่เคารพมากตอนป.ตรี อาจารย์ท่านถามว่า
.
"... รู้มั้ยทำไมงานพวกเราถึงถูกเรียกว่า Software Engineer ? ..."
.
"... ก็เพราะสิ่งที่เราต้องทำมันเป็นงาน *วิศวกรรม* ยังไงหละ ..."
.
สีหน้าสงสัยปนสนใจของเราทำให้ยังไม่ทันที่จะเอ่ยปากถาม อาจารย์ก็เดาออกทันทีว่าเราจะถามอะไร อาจารย์เลยตอบคำถามที่เรายังไม่ทันถามได้ทันที
.
"... วิศวกรซอฟต์แวร์หนะ เราไม่ได้แค่เขียนโปรแกรมให้ใช้งานได้นะ แต่หน้าที่ของเราคือต้องแก้ปัญหาทางคอมพิวเตอร์โดยคำนึงถึง *ความคุ้มค่าที่สุด* ให้ได้ด้วย ..."
.
ตั้งแต่นั้นเป็นต้นมา คำว่า "คุ้มค่าที่สุด" ก็ถูกฝังไว้ในหัวและกลายเป็นแกนกลางของการแก้ปัญหาใด ๆ ในทุกงานของเรา ความเข้าใจเพียงเบาบาง ณ ตอนนั้นก็ค่อย ๆ ถูกประสบการณ์หล่อหลอมให้เข้าใจมากขึ้นจนรู้แล้วว่ามันไม่ใช่แค่เรื่องของการพัฒนาซอฟต์แวร์ แต่กับทุกเรื่องในชีวิตเลย
.
อาจจะสงสัยว่าความคุ้มค่าที่สุดที่ว่าคืออะไร ? คำตอบคือ "เราต้องรู้ว่าจุดประสงค์ของงานนั้น ๆ คืออะไร สิ่งที่ได้กลับมามีมูลค่ามากน้อยแค่ไหน และเราต้องลงทุนลงแรงไปมากน้อยเพียงใดถึงจะคุ้มกับสิ่งที่ได้มา"
.
งานที่ทำแล้วใช้ครั้งเดียวทิ้ง ทำ Big-O แย่ ๆ โดยใช้เวลา 30 นาทีในการเขียนแล้วปล่อยให้มันรัน 1 ชั่วโมงเต็มก็ยังคุ้มค่ากว่าเขียนโปรแกรม 3 วันเต็มด้วย Big-O เทพ ๆ แต่รัน 1 นาทีเสร็จ ... แล้วก็โยนทิ้งไป
.
งานที่รันตลอดเวลา ลงทุนเขียนโปรแกรมเป็นเดือนให้ทำงานได้ ≤ O(log n) นี่แหละคือความเหมาะสมและคุ้มค่ากับสิ่งที่ได้มา
.
แต่ถ้างานมีเวลากระชั้น การนั่งทำ Big-O เทพ ๆ แล้วส่งงานไม่ทันก็อาจจะส่งผลเสียต่อธุรกิจ ก็ต้องสามารถบาลานซ์ได้ว่าจะต้องทำด้วย Big-O เท่าไหร่เพื่อให้ประสิทธิภาพยอมรับได้และส่งงานทัน แล้วค่อยมา Optimize ให้ดีขึ้นทีหลัง
.
Code Quality เทพเนียนกิ๊กแต่ Deliver งานตามกำหนดไม่ได้ รันโปรดักชั่นไม่สำเร็จ สเกลไม่รอด ธุรกิจพังไม่เป็นท่า บริษัทเจ๊ง ถ้าเทียบกับ Code Quality พอดี ๆ เขียนเทสต์ในส่วนที่จำเป็น ส่งงานทัน บริษัทกำไรเพิ่มแล้วค่อยมาปรับ Code Quality ให้สมบูรณ์ทีหลัง
.
งาน Software Engineer กับธุรกิจจึงเป็นเรื่องเกี่ยวข้องกัน หน้าที่นึงของ Software Engineer คือจะต้องสามารถนิยามคำว่า "ความคุ้มค่า" ของงานที่ตัวเองทำให้ได้
.
และการจะทำสิ่งนี้ได้นั้น เราจะต้อง "ประเมินมูลค่าของสิ่งที่ทำและสิ่งที่ตัดสินใจไม่ทำให้ได้"
.
การเขียนโปรแกรมดีเลิศ Code Quality ดี โค้ดดูแลง่าย - มีมูลค่าบวก
.
การเขียนโปรแกรมดีเกินไปจนสิ่งที่รับกลับมามีค่าน้อยกว่าแรงที่ลงลงไป (Overengineer) - มีมูลค่าลบ
.
การเขียนโปรแกรมแย่ แก้ทุกอย่างแบบ Quick & Dirty จนโค้ดดูแลไม่ได้ในระยะยาว (Technical Debt) - มีมูลค่าลบ
.
การเขียนโปรแกรมด้วยภาษาที่หาคนร่วมทีมได้ง่าย - มีมูลค่าบวก
.
การเขียนโปรแกรมด้วยภาษาที่ต้องควานหาคนทั้งปฐพีถึงจะเจอคนทำเป็นสักคน - มีมูลค่าลบ
.
การส่งงานทัน - มีมูลค่าบวก
.
การส่งงานไม่ทัน - มีมูลค่าลบ
.
การจะทำงานสักงานนึงก็ต้องเอาค่าด้านบนพวกนี้มาบวกกัน ดิฟนิดหน่อย อินทิเกรดนิดนึง (เพราะมันมีเรื่องเวลามาเกี่ยวข้อง ความคุ้มค่าระยะสั้น ความคุ้มค่าระยะยาว ล้วนมีผลต่อการตัดสินใจ) แล้วถึงตัดสินใจกันว่าจะเดินไปทางไหน
.
จะเห็นว่างานของ Software Engineer ไม่ใช่แค่เขียนโปรแกรมให้จบ ๆ ไป ไม่ใช่การเขียนให้ Code Quality ดีเลิศที่สุดในปฐพี ไม่ใช่การเขียนโค้ดที่ประสิทธิภาพล้ำจนเอาคนไปแข่ง ACM ได้ แต่เป็นการ "หาจุดคุ้มค่าที่สุดแล้วทำอย่างเหมาะสม" ต่างหาก
.
บ่อยครั้งมากที่มีคนถกเถียงกันเรื่อง Code Quality เอย เรื่องประสิทธิภาพการทำงานของโค้ดเอย เรื่องการเขียน Test เอย แล้วผลก็คือเสียงแตก จะบอกว่าไม่มีทางหรอกที่แต่ละคนจะให้คำตอบเหมือนกัน เพราะเรายังไม่ได้นิยามคำว่า "คุ้มค่า" ร่วมกันเลยนี่
.
เมื่อความคุ้มค่าไม่เหมือนกัน แล้วจะคาดหวังให้การตัดสินใจของแต่ละคนเหมือนกันได้ยังไงอ่ะ ?
.
ไม่ต้องไปถึงขั้นคนไม่รู้จักกันมาคุยกันใน Facebook Group หรอก แค่ในบริษัทตัวเอง ฝ่าย Business กับฝ่ายเขียนโปรแกรมก็ไม่สามารถคุยกันรู้เรื่องได้แล้วถ้าไม่สามารถคุยด้วยจุดมุ่งหมายเดียวกันได้
.
แล้วอะไรคือจุดมุ่งหมายร่วมกันของบริษัทหละ ?
.
"ธุรกิจก็คือธุรกิจ" ไม่ว่าจะทำอะไร ยังไงก็ต้อง Business-Driven อยู่แล้ว ถ้าไม่มีกำไรบริษัทแล้วจะไปต่อยังไง ถ้าสิ่งที่ทำกลับทำให้บริษัทขาดทุนแล้วจะเปิดบริษัทต่อไปทำไม หน้าที่ของ Software Engineer คือต้องประเมินมูลค่าออกมาเป็นตัวเลขและความคุ้มค่าให้ได้ เพื่อเอาสิ่งเหล่านี้ไปคุยกับฝ่าย Business หาจุดคุ้มค่าร่วมกันแล้วมุ่งหน้าสู่ทางนั้นเต็มอัตรา
.
ถ้ายังทำไม่ได้ นั่นแปลว่าคุณยังทำให้คนอื่นมองเห็นมูลค่าของงานที่คุณทำไม่ได้นั่นเอง
.
เป็นสกิลนึงที่อยากให้คนสาย Software Engineer ฝึกไว้ อย่าเอาแต่เขียนโปรแกรมไปวัน ๆ แต่เมื่อได้โจทย์อะไรมา เราจะต้องสามารถวิเคราะห์สถานการณ์ วางแผนไว้หลาย ๆ แบบ ประเมินมูลค่าของแต่ละแบบแล้วเลือกแผนที่ "คุ้มค่า" ที่สุด
.
เพราะมันไม่มีหรอกคำตอบที่ดีที่สุดสำหรับทุกสถานการณ์ มันมีแค่ "ทางที่เหมาะสมที่สุด" เท่านั้นแหละ
.
เหมือนที่เธอกับเราเหมาะสมกันไง 😳😳😳
