- ใน วัฒนธรรมวิศวกรรมซอฟต์แวร์ โครงสร้างที่ให้การยอมรับคนที่สร้างระบบซับซ้อนมากกว่า ขณะที่คนที่เลือกวิธีแก้ปัญหาแบบเรียบง่ายกลับไม่ได้รับการประเมินคุณค่า ยังคงดำรงอยู่
- ใน การประเมินเลื่อนตำแหน่ง การสัมภาษณ์ และการรีวิวการออกแบบ ความซับซ้อนมักถูกเข้าใจผิดว่าเป็น “อิทธิพล” ทำให้เกิดแนวโน้มในการเพิ่ม abstraction และความสามารถในการขยายระบบโดยไม่จำเป็น
- การ implement แบบเรียบง่ายมักกลายเป็น “ผลงานที่มองไม่เห็น” แต่ โครงสร้างที่ซับซ้อนนั้นเติมคำบรรยายและเอกสารให้แฟ้มขอเลื่อนตำแหน่งได้ง่ายกว่า
- ความเชี่ยวชาญที่แท้จริงไม่ได้อยู่ที่การใช้เครื่องมือให้มากขึ้น แต่คือ วิจารณญาณและความมั่นใจที่จะรู้ว่าเมื่อไรควรตัดความซับซ้อนทิ้ง
- ทั้งวิศวกรและผู้นำ ต้องทำให้ความเรียบง่ายมองเห็นได้ และสร้างระบบประเมิน/ให้รางวัลที่ยอมรับสิ่งนี้อย่างเป็นทางการ
ความเรียบง่าย vs ความซับซ้อน: ความไม่สมดุลของเรื่องเล่าเพื่อการเลื่อนตำแหน่ง
- กรณีของวิศวกรสองคนในทีมเดียวกัน: Engineer A ปล่อยฟีเจอร์ได้ภายในไม่กี่วันด้วย โค้ดกระชับ 50 บรรทัด ส่วน Engineer B ใช้เวลา 3 สัปดาห์โดยเพิ่ม abstraction layer ใหม่, ระบบ pub/sub และ configuration framework
- งานของ Engineer B สามารถเขียนลงในแฟ้มขอเลื่อนตำแหน่งได้ว่า “ออกแบบสถาปัตยกรรมแบบ event-driven ที่ขยายได้, เพิ่ม abstraction layer ที่นำกลับมาใช้ซ้ำได้, สร้าง configuration framework”
- แต่งานของ Engineer A อธิบายได้เพียงสามคำว่า “implement ฟีเจอร์ X”
- ทั้งที่จริงแล้วเป็นงานที่ดีกว่า แต่เพราะทำให้มันดูเรียบง่าย จึงกลายเป็น ผลงานที่มองไม่เห็น
- ไม่มีใครได้เลื่อนตำแหน่งจาก “ความซับซ้อนที่หลีกเลี่ยงได้” — ที่ความซับซ้อนดูฉลาดก็เพราะระบบประเมินถูกออกแบบมาให้ให้รางวัลกับมัน
โครงสร้างที่ทำให้ความซับซ้อนยิ่งแข็งแรงขึ้นในการสัมภาษณ์และรีวิวการออกแบบ
- ในการสัมภาษณ์ system design หากเสนอวิธีแก้ปัญหาแบบเรียบง่าย (ฐานข้อมูลเดียว, API ที่ตรงไปตรงมา, caching layer) ผู้สัมภาษณ์ก็มักกดดันด้วยคำถามว่า “แล้วถ้ามีผู้ใช้สิบล้านคนล่ะ?”
- ยิ่งเพิ่ม service, queue, sharding มากเท่าไร ก็ยิ่งได้ประสบการณ์ว่าผู้สัมภาษณ์พอใจมากขึ้น
- บทเรียนที่ผู้สมัครได้รับคือ “คำตอบแบบง่ายนั้นยังไม่พอ”
- ผู้สัมภาษณ์อาจมีเหตุผลที่สมเหตุสมผลในการกดดันเช่นนี้ (ดูความสามารถในการคิดภายใต้แรงกดดัน, ตรวจสอบ ความเข้าใจระบบกระจาย) แต่ข้อความที่ส่งไปถึงผู้สมัครคือ “ความซับซ้อนนั้นน่าประทับใจ”
- ใน design review ก็เกิดรูปแบบเดิมซ้ำๆ เมื่อมีคำถามว่า “ไม่ควร future-proof ไว้หน่อยหรือ?” จนทำให้เพิ่ม layer และ abstraction ที่ไม่จำเป็น
- ไม่ได้เพิ่มเพราะปัญหาต้องการ แต่เพิ่มเพราะห้องประชุมคาดหวัง
- มีหลายกรณีที่ abstraction ที่สร้างขึ้นเพื่อหลีกเลี่ยงโค้ดซ้ำไม่กี่บรรทัด กลับทำให้การทำความเข้าใจและการบำรุงรักษายากขึ้น
- โค้ดอาจดู “เป็นมืออาชีพ” มากขึ้น แต่ผู้ใช้ก็ไม่ได้ฟีเจอร์เร็วขึ้น และวิศวกรคนถัดไปต้องเสียเวลาครึ่งวันเพื่อทำความเข้าใจ abstraction ก่อนจะแก้ไขอะไรได้
ความซับซ้อนที่เหมาะสม vs ความซับซ้อนที่ไม่สมเหตุสมผล (Unearned Complexity)
- ตัวความซับซ้อนเองไม่ใช่ปัญหา — การประมวลผลธุรกรรมนับล้านรายการต้องใช้ระบบกระจาย และเมื่อมี 10 ทีม ทำผลิตภัณฑ์เดียวกันก็จำเป็นต้องมี ขอบเขตของ service
- ปัญหาคือ ความซับซ้อนที่ไม่จำเป็น: ความต่างระหว่าง “ถึงขีดจำกัดของฐานข้อมูลแล้วจึงต้องทำ sharding” กับ “อีก 3 ปีอาจถึงขีดจำกัด งั้นทำ sharding ตั้งแต่ตอนนี้เลย”
- โค้ดและสถาปัตยกรรมของวิศวกรที่เข้าใจเรื่องนี้จะให้ความรู้สึกว่า “ก็ต้องเป็นแบบนี้แหละ” ไม่มีทั้งความมหัศจรรย์หรือความแพรวพราว และไม่ทำให้คนอ่านรู้สึกว่าตัวเองโง่เพราะตามไม่ทัน
- เส้นทางจริงสู่ระดับ senior ไม่ใช่การเรียนรู้เครื่องมือและแพตเทิร์นให้มากขึ้น แต่คือการรู้ว่าเมื่อไรไม่ควรใช้มัน — ใครๆ ก็เพิ่มความซับซ้อนได้ แต่การเอามันออกต้องใช้ประสบการณ์และความมั่นใจ
แนวทางปฏิบัติสำหรับวิศวกร
- ต้องทำให้ความเรียบง่าย มองเห็นได้ — เพราะตัวงานไม่ได้เล่าเรื่องแทนตัวเอง และระบบประเมินก็ไม่ได้ถูกออกแบบมาให้ได้ยินเรื่องนั้น
- แทนที่จะเขียนว่า “implement ฟีเจอร์ X” ให้เขียนว่า “ประเมิน 3 แนวทาง รวมถึงสถาปัตยกรรม event-driven และ custom abstraction layer แล้วสรุปว่าการ implement แบบเรียบง่ายตอบโจทย์ทั้งความต้องการปัจจุบันและที่คาดการณ์ไว้ จึงปล่อยใช้งานได้ใน 2 วันและรันต่อเนื่อง 6 เดือนโดยไม่มี incident”
- การตัดสินใจว่าจะไม่สร้างบางอย่างก็เป็นการตัดสินใจเช่นกัน และเป็นการตัดสินใจที่สำคัญ — จึงต้องมีการบันทึกเอกสารให้เหมาะสม
- ใน design review เมื่อมีคำถามว่า “ไม่ควร future-proof หรือ?” อย่ายอมตามง่ายๆ แต่ให้เสนอว่า “ถ้าจะเพิ่มทีหลังต้องใช้เวลาประมาณนี้ ถ้าเพิ่มตอนนี้จะมีต้นทุนเท่านี้ การรอไว้ก่อนดีกว่า”
- ไม่ใช่การเถียงกลับ แต่เป็นการแสดงให้เห็นว่าคุณได้พิจารณามันแล้ว
- คุยกับผู้จัดการโดยตรงว่า “อยากให้วิธีการบันทึกงานสะท้อนไม่ใช่แค่โค้ด แต่รวมถึง การตัดสินใจที่ฉันได้ทำลงไป” — ในมุมของผู้จัดการเอง นี่คือการได้รับภาษาที่จะใช้สนับสนุนคุณ
- หากทำทั้งหมดนี้แล้ว ทีมก็ยังเลื่อนตำแหน่งให้เฉพาะคนที่สร้างระบบซับซ้อนที่สุด นั่นก็เป็นข้อมูลที่มีประโยชน์เช่นกัน — บางองค์กร ให้คุณค่ากับความเรียบง่ายอย่างจริงจัง ขณะที่บางองค์กรพูดเช่นนั้นแต่กลับให้รางวัลกับสิ่งตรงกันข้าม
แนวทางปฏิบัติสำหรับผู้นำสายวิศวกรรม
- การกำหนดแรงจูงใจเป็นความรับผิดชอบของผู้นำ — เกณฑ์เลื่อนตำแหน่งส่วนใหญ่มักถูกออกแบบมาให้ให้รางวัลกับความซับซ้อน และ “ผลกระทบ” มักถูกวัดจากขนาดและขอบเขตของสิ่งที่สร้างขึ้น
- ควรสะท้อนในการประเมินไม่ใช่แค่สิ่งที่สร้าง แต่รวมถึง สิ่งที่หลีกเลี่ยงไม่สร้าง ด้วย
- ใน design review แทนที่จะถามว่า “คำนึงถึง scalability หรือยัง?” ให้เปลี่ยนเป็น “เวอร์ชันที่เรียบง่ายที่สุดที่ปล่อยใช้งานได้คืออะไร และสัญญาณที่ชัดเจนว่าจำเป็นต้องเพิ่มความซับซ้อนคืออะไร?”
- คำถามเดียวนี้เปลี่ยนเกมได้: ทำให้ความเรียบง่ายเป็นค่าเริ่มต้น และให้ ภาระการพิสูจน์ตกอยู่กับความซับซ้อน
- ในการพูดคุยเรื่องเลื่อนตำแหน่ง เมื่อเห็นแฟ้มที่เต็มไปด้วยรายการระบบน่าประทับใจ ก็ควรถามกลับว่า “ทั้งหมดนั้นจำเป็นจริงหรือ? ระบบ pub/sub จำเป็นจริงไหม หรือแค่ดูดีในเอกสาร?”
- เมื่อสมาชิกทีมปล่อยงานที่สะอาดและเรียบง่าย ผู้นำต้องช่วยเขียนเรื่องเล่าให้เขา — ถ้า “ประเมินหลายแนวทางแล้วเลือกวิธีที่เรียบง่ายที่สุดในการแก้ปัญหา” จะกลายเป็นตัวอย่างการเลื่อนตำแหน่งที่น่าเชื่อถือได้ ผู้นำก็ต้องปฏิบัติต่อมันเช่นนั้นจริงๆ
- จงระวังสิ่งที่คุณประกาศชื่นชมในช่องทางของทีมต่อสาธารณะ — หากชมแต่โครงการใหญ่และซับซ้อน ผู้คนก็จะ optimize ไปทางนั้น
- ต้องยอมรับทั้ง วิศวกรที่ลบโค้ดออก, และวิศวกรที่พูดว่า “ยังไม่จำเป็น” แล้วปรากฏว่าพูดถูก
10 ความคิดเห็น
การออกแบบที่ขับเคลื่อนด้วยเรซูเม่...
ฉันไม่ได้คิดว่าข้อเสนอที่ออกมาในบทความนี้ไร้ความหมายนะ แต่ฉันคิดว่ามันอ่อนแรงเกินไปที่จะเอาชนะ "การออกแบบขนาดใหญ่" ได้ เพราะฝั่งนั้นอธิบายได้ง่ายมากจริง ๆ :(
ความเห็นจาก Hacker News
ในคำถามสัมภาษณ์ มีการยกสถานการณ์ว่าคนสองคนส่งสเปรดชีตหากันทางอีเมล
ฉันตอบว่า จะย้ายไปใช้ Google Sheets แต่ดูเหมือนผู้สัมภาษณ์อยากให้ฉันออกแบบเครื่องมือขึ้นมาเอง
ตอนนั้นก็รู้สึกแปลก ๆ แต่จนถึงตอนนี้ก็ยังไม่แน่ใจว่าควรได้บทเรียนอะไรจากเรื่องนี้
ควรยอมรับคำตอบที่ดี แล้วค่อยชี้นำต่อว่า “นี่เป็นสถานการณ์สมมุติเพื่อประเมินการออกแบบเชิงเทคนิค งั้นลองออกแบบระบบใหม่กัน”
ถ้าผู้สมัครรับกรอบนั้นไม่ได้ ก็ค่อยนับเป็นอีกหนึ่งสัญญาณในการประเมิน
ถ้าเป็นฉัน ฉันจะถามว่า “ให้สมมุติว่าไม่มีโซลูชันที่มีอยู่แล้ว แล้วออกแบบใหม่เลยไหม?”
มันเหมือนกับ เวอร์ชัน system design ของการเถียงกันเรื่องโจทย์ algorithm ที่ผู้สัมภาษณ์อยากได้ยินแค่คำตอบที่ตัวเองต้องการ
ซึ่งจริง ๆ แล้วเป็นการตัดสินใจที่ถูกต้อง แต่ Patrick Collison โทรมาด้วยตัวเองแล้วถามว่า “แม้จะไม่ผ่านสัมภาษณ์ แต่เข้าใจเจตนาไหม”
สุดท้ายก็ได้สัมภาษณ์ใหม่และผ่าน
เป็นเกร็ดที่แสดงให้เห็นว่าการเข้าใจ เป้าหมายของการสัมภาษณ์ สำคัญแค่ไหน
บริษัท เรือเฟอร์รี รายใหญ่แห่งหนึ่งใช้ Google Sheets จัดการตำแหน่งเรือและการจัดพนักงาน เพื่อนฉันบอกว่า “นี่ไม่ใช่สิ่งที่บริษัทใหญ่ควรทำ”
แต่ฉันกลับคิดว่านี่เป็นการแก้ปัญหาด้วยเครื่องมือที่พิสูจน์แล้วว่ายอดเยี่ยม
ทำให้ดำเนินงานได้โดยไม่ต้องมีทีมพัฒนาภายในหรือจ้างภายนอกราคาแพง
มันเป็นประสบการณ์ที่ทำให้ฉัน ฝังความอวดดีของตัวเองไว้ลึก ๆ
ให้คู่สนทนาอธิบายก่อนว่ามีอะไรไม่เข้ากันตรงไหน แล้วค่อยเริ่มออกแบบทางเทคนิค
เหตุผลที่ใช้ Sheets ไม่ได้มีได้หลายอย่าง — ข้อจำกัดด้านฟีเจอร์, การเข้าถึงในจีน, นโยบายบริษัท, ปัญหาเครือข่าย ฯลฯ
ลูกค้าอาจต้องการโซลูชันแบบ custom เพราะเหตุผลพวกนี้อยู่แล้ว
กล่าวคือ หน้าที่ของนักพัฒนาไม่ใช่แค่บอกว่า “ไปใช้ Google Sheets สิ” แต่คือ การเข้าใจบริบทของลูกค้า
เครื่องมือเขียนโค้ดด้วย AI กำลังทำให้ปัญหานี้แย่ลงอย่างแนบเนียน
ตอนนี้สามารถสร้าง สถาปัตยกรรมที่ซับซ้อน ได้ใน 5 นาที แต่ต้นทุนการดูแลรักษายังเท่าเดิม
ผลคือโครงสร้างที่หวือหวากว่าถูกสร้างขึ้นอย่างรวดเร็ว และเอกสารสำหรับใช้ขอเลื่อนตำแหน่งก็เสร็จไว
แต่ในความเป็นจริงกลับไม่มีใครเข้าใจโค้ดนั้นทั้งหมด
เกณฑ์ของความเรียบง่ายที่แท้จริงคือ “คนถัดไปจะเข้าใจได้โดยไม่ต้องถามอะไรไหม” และโค้ดที่ AI สร้างก็ยังสอบไม่ผ่านข้อนี้อย่างสมบูรณ์
ตอนนี้มันก็แค่จะหนักขึ้นอีก
เพราะอย่างนั้นฉันจึงใช้ วัฒนธรรมความเข้าใจโค้ดขององค์กร เป็นเกณฑ์ในการเลือกงาน
ฉันไม่อยากเจอสถานการณ์ที่ไม่มีใครรู้ระบบอีกแล้ว
ถ้าเป้าหมายคือการแก้ปัญหา ไม่ว่าจะเป็นเครื่องมือที่ AI สร้างหรือเครื่องมือที่ซื้อมา มันก็ต้องแก้ปัญหาได้
แต่ถ้าผลิตภัณฑ์สำเร็จรูปไม่เหมาะ ก็สุดท้ายจะมีโซลูชัน custom ที่สร้างขึ้นเองมากขึ้น
เพียงแต่ถ้าไม่มีใครเข้าใจมัน คนถัดไปก็คงสร้างใหม่อีกอยู่ดี
ถึงอย่างนั้น ในแง่ที่ทำให้ผู้ใช้กับผู้สร้างใกล้กันมากขึ้น มันอาจถือเป็นพัฒนาการก็ได้
ตัวอย่างเช่น การระบุแนวทางอย่าง “KISS”, “YAGNI” ไว้ใน
AGENTS.mdก็ช่วยได้ปัญหาคือ “คนถัดไป” นั้นสุดท้ายมักเป็น ตัวฉันเองในอีก 6 เดือนข้างหน้า
AI เองก็เจอปัญหาเดียวกันจากข้อจำกัดของ context window
นักพัฒนาหลายคนเอาแต่ไล่ตามสแตกยอดนิยม โดยไม่คำนึงถึงความง่ายในการดูแลระบบ
AI เองก็ไม่ได้บอกว่า “นี่มันออกแบบเกินความจำเป็นนะ”
ถ้าคุณอยากได้ Kubernetes กับ ElasticSearch มันก็จะทำให้ตามนั้น
จากมุมมองของคนที่เคยผ่านทั้ง FAANG และสตาร์ตอัปมาแล้ว ประเด็นสำคัญคือ การหาสมดุลระหว่างความซับซ้อนกับความเรียบง่าย
ในบริษัทใหญ่ การแฮ็กแก้ขัดอาจทำลาย productivity ของคนนับพันได้ และ
ในสตาร์ตอัป โครงสร้างพื้นฐานที่มากเกินไปก็อาจทำให้บริษัทพังได้
วิศวกรที่ชำนาญจริงคือคนที่แยกสองสถานการณ์นี้ออก และเลือก trade-off ที่เหมาะสม จากประสบการณ์ได้
ตอนทำงานที่ Amazon (2005~2008) มีรางวัลเชิงสัญลักษณ์ของวัฒนธรรมบริษัทอยู่สองอย่าง
รางวัล “Just Do It” สื่อถึง การแก้ปัญหาเชิงรุก, ส่วนรางวัล “Door Desk” สื่อถึง ความประหยัดและความเรียบง่าย
มีเรื่องเล่าว่าพนักงานคนหนึ่งได้รางวัลเพราะเอาทีวีที่ไม่มีประโยชน์ออกไป และของรางวัลก็คือทีวีนั้นเอง
ความเรียบง่ายในฐานะอุปลักษณ์จึงค่อนข้างกำกวมเมื่อมาอยู่ในโลกจริง
ถ้าจะผลักดันเรื่องความเรียบง่าย ต้อง พูดด้วยภาษาธุรกิจ
เช่น “incident ลดลง 80%”, “ต้นทุนลดลง 40%”, “ประสิทธิภาพดีขึ้น 33%”
ตัวความเรียบง่ายเองมักไม่ถูกประเมิน แต่ ผลลัพธ์ของมัน ถูกให้คุณค่าสูง
ฉันเคยแปลงงาน refactoring ให้เป็นโมเดลต้นทุน วัด KPI และลด MTTR ลงได้ 60%
ต้องโชว์ตัวเลขแบบนี้ถึงจะได้รับการยอมรับ
ในฐานะผู้จัดการ ฉันชอบ โค้ดที่เรียบง่าย
แต่ก็เพราะทีมของฉันประกอบด้วยคนที่มีทักษะสูง
ถ้าเป็นทีมที่ประสบการณ์น้อย ก็อาจเกิดเรื่องแบบ The Parable of The Toaster ได้
ยิ่งอายุมากขึ้นก็ยิ่ง ต้านทานความซับซ้อน
แต่ฝ่ายผู้นำมักเข้าใจผิดว่าเป็นการคัดค้านเพราะ “ไม่เข้าใจ”
โปรเจกต์ที่อยู่รอดได้นานที่สุดมักเป็นสิ่งที่เรียบง่ายและเปลี่ยนแทนได้ง่าย
เครื่องมือ AI ทำให้แนวทางแบบนี้ง่ายขึ้น — ทดลองคอมโพเนนต์ใน sample project ที่แยกอิสระ แล้วค่อยรวมโค้ดที่พิสูจน์แล้วเข้าโปรเจกต์จริง
แม้จะอยู่ในสภาพแวดล้อมอินทราเน็ตที่ไม่ได้ต่อ AI ตรง ๆ แต่วิธีนี้ก็มีประโยชน์มาก
เพราะแบบนั้นฉันจึงเสนอว่า “ฉันทำแบบซับซ้อนก็ได้ แต่ลองเริ่มจากเวอร์ชันง่ายก่อนเถอะ”
ส่วนใหญ่แล้วเวอร์ชันง่ายนั้นกลับกลายเป็น โค้ดโปรดักชันที่รันอยู่หลายปี
นักพัฒนาที่ส่งมอบโซลูชันเรียบง่ายได้เร็ว จะมีเวลาเหลือไปทำฟีเจอร์อื่นได้อีกหลายอย่าง
ส่วนคนที่ยึดติดกับโซลูชันซับซ้อนจะใช้เวลาหลายสัปดาห์ไปกับฟีเจอร์เดียว
สุดท้ายแล้วใน ตัวชี้วัดด้าน productivity แนวทางที่เรียบง่ายมักดูน่าดึงดูดกว่า
ตัวฉันเองก็สร้างอาชีพจากการเป็นคนที่ ส่งมอบผลลัพธ์อย่างสม่ำเสมอ มากกว่าจะเป็นคนที่มี “ไอเดียใหญ่”
หนึ่งในคำถามสัมภาษณ์ของบริษัทเราคือโจทย์ ออกแบบระบบห้องสมุดสาธารณะ
เริ่มจากห้องสมุดเมืองเล็ก แล้วค่อยขยายเป็นระดับประเทศ
คำตอบที่ดีที่สุดคือ “ต่อให้เป็นขนาดสูงสุด ก็ใช้แค่เซิร์ฟเวอร์ระดับกลางกับ Postgres ก็พอ”
ทั้งที่ในโลกจริง 10 กับ 10,000 ต่างกันไม่มากขนาดนั้น และบ่อยครั้งก็เป็น ผู้สัมภาษณ์ที่ประสบการณ์น้อย ซึ่งแค่อ่าน prompt ตามสคริปต์
หลังจากนั้นโครงสร้างพื้นฐานที่เกินจำเป็นกับ การพัฒนาเพื่อใส่ในเรซูเม่ ต่างหากที่ทำให้ปัญหาใหญ่ขึ้น
ฉันคิดว่า AI ท้ายที่สุดแล้วคือ เครื่องมือที่ขยายความสามารถของผู้ใช้
สำหรับนักพัฒนาที่ชำนาญ มันช่วยเพิ่ม productivity แต่สำหรับคนที่ยังไม่ชำนาญ มันกลับเป็น เครื่องมือที่ขยายความสับสนได้อย่างรวดเร็ว
ตรงกันข้าม มันมักเพิ่ม wrapper function และการแปลง type ที่ไม่จำเป็น
ฉันจึงรู้สึกว่า AI โน้มเอียงไปทาง “เพิ่มโค้ดเข้าไปอีก” มากกว่า
เพียงแต่ก็น่ากังวลที่ “vibe coding” แบบผิวเผินกำลังเพิ่มขึ้น
แม้แต่คนสัมภาษณ์ที่ผมเคยพบก็ยังชอบความซับซ้อนกันนะ
คงไม่ถึงกับหวังว่าจะได้รับการประเมินว่าความเรียบง่ายเป็นข้อดีหรอกครับ ความจริงคือ บางครั้งคนที่ทำให้เรื่องมันซับซ้อนจนเกิดปัญหา แล้วค่อยมาเก็บกวาดแก้ไขทีหลัง ยังได้เลื่อนตำแหน่งเลยด้วยซ้ำ
ปัญหาการออกแบบเกินความจำเป็นเพื่ออวดความสามารถ แทนที่จะออกแบบเพื่อให้บริการใช้งานได้จริงนั้นมีอยู่ดาษดื่น
ผมคิดว่าผู้ประเมินเองก็ควรมีความเข้าใจที่ดีด้วย
และก็จริงที่ควรต้องได้รับคำอธิบายอย่างเพียงพอเช่นกัน
ถ้ามีคนที่อยู่ตำแหน่งสูงพอจะประเมินเรื่องแบบนั้นได้ ทุกอย่างก็คงไม่เป็นไร แต่ปัญหาคือตั้งแต่แรกมันทำไม่ได้ เลยทำให้สิ่งแบบนี้ไม่ได้รับการประเมินอย่างยุติธรรม และเพราะแบบนั้น คนประเภทนั้นก็เลยขึ้นไปข้างบนไม่ได้...
นี่แหละคือวงจรอุบาทว์...
ในมุมของบริษัท ดูเหมือนว่าถ้าประสบความสำเร็จในฐานะวิศวกรที่มีความสมดุลแล้วไต่เต้าขึ้นไปได้ จึงจะรักษาหลักการของวิศวกร/วิศวกรรมที่ดีเอาไว้ได้ครับ
ความจริงส่วนใหญ่ไม่ใช่ว่าแค่ทำฟังก์ชันให้ใช้งานได้อย่างเดียว เทียบกับคนที่ออกแบบให้ขยายต่อได้และยังจัดการ trade-off ได้ดีไม่ใช่หรือครับ
ถึงจะทำงานอย่างซับซ้อน แต่สุดท้ายก็พูดได้ว่าเป็นการพัฒนาฟังก์ชัน X
ดังนั้นความต่างจึงอยู่ที่ว่าเราจะสื่อสารสิ่งนั้นกับผู้ประเมินด้วยวิธีไหน