เราใช้ระดับของการทำ abstraction มากเกินไป
(unixsheikh.com)- ในอุตสาหกรรมเทคโนโลยี มีคนจำนวนมากขึ้นที่เรียนรู้แค่วิธีใช้เครื่องมือและระบบอัตโนมัติ แต่ไม่เข้าใจหลักการทำงานของชั้นล่างลงไป ทำให้ ความลึกทางเทคนิค อ่อนแอลง
- abstraction ทำให้งานง่ายขึ้นเหมือนพวงมาลัยหรือพาวเวอร์สเตียริง แต่เมื่อเกิดความเสียหายหรือระบบล่ม หากไม่มีคนที่รู้โครงสร้างภายใน ความสามารถในการกู้คืน ก็จะลดลง
- แรงกดดันเรื่องการออกผลิตภัณฑ์ให้เร็วและการลดต้นทุนผลักภาระหลายบทบาทไปรวมไว้ที่คนคนเดียวแบบ DevOps·DevSecOps และนำไปสู่ระบบอัตโนมัติมากขึ้นกับ ความเข้าใจเชิงลึก ที่น้อยลง
- ในสายความปลอดภัย การเชื่อเพียงไฟเขียวจากเครื่องมือทดสอบเจาะระบบแบบ GUI อาจทำให้เกิดสถานการณ์ที่การบุกรุกจริงไม่ถูกค้นพบนานเป็นเวลานาน
- คนที่เรียนรู้เทคโนโลยีควรรักษา ทัศนคติแบบวิศวกร ด้วยการไม่ไล่ตามแต่กระแส ลองทำงานที่เครื่องมือทำแทนด้วยตัวเอง และเจาะลึกลงไปถึงโค้ดกับชั้นล่างของระบบ
ช่องว่างของความเข้าใจทางเทคนิคที่ abstraction บดบัง
- ทุกวันนี้มี “ผู้เชี่ยวชาญ” จำนวนมากที่รู้วิธีตั้งค่าเครื่องมือ แต่ไม่เข้าใจว่าเทคโนโลยีทำงานอย่างไรในชั้นที่ลึกลงไป
- abstraction เองเป็นสิ่งจำเป็น
- พวงมาลัยคือ abstraction ที่ทำให้การขับรถง่ายขึ้น
- พาวเวอร์สเตียริงคือ abstraction อีกชั้นที่ช่วยให้ประสบการณ์การขับดีขึ้น
- ปัญหาจะปรากฏเมื่อ abstraction พังลง
- หากไม่มีคนที่เข้าใจเทคโนโลยีภายใน ก็ยากที่จะซ่อมชั้นที่เสียหาย
- แม้เครื่องมือจะแสดงว่าปกติ ก็อาจไม่สามารถตัดสินสถานะจริงของระบบได้
- อุตสาหกรรมเทคโนโลยีถูกขับเคลื่อนอย่างหนักด้วยรายได้และความเร็วในการออกสู่ตลาด
- ผลคือมีการนำ abstraction และระบบอัตโนมัติ มาใช้มากขึ้น
- คนจำนวนน้อยลงต้องรับงานมากขึ้น
- วิธีใช้เครื่องมือเฉพาะทางถูกเน้นมากกว่าความเข้าใจเชิงลึก
- บทบาทของโปรแกรมเมอร์และผู้ดูแลระบบแบบเดิมกำลังเปลี่ยนไปสู่การรวมงานพัฒนา ความปลอดภัย และปฏิบัติการไว้ในหน้าที่ของคนคนเดียว เช่น DevOps, DevSecOps
- เนื่องจากคนคนเดียวฝึกจนเชี่ยวชาญทั้งการพัฒนา ความปลอดภัย และการดูแลระบบได้ยาก จึงพยายามทำทุกอย่างให้เป็นอัตโนมัติมากที่สุด
- ผลลัพธ์คือบุคลากรเทคโนโลยียุคใหม่อาจเรียนรู้วิธีใช้เครื่องมือบางอย่าง แต่แทบไม่รู้เทคโนโลยีภายในเลย
ทัศนคติที่คนเรียนเทคโนโลยีควรมี
- ชีวิตสมัยใหม่พึ่งพาเทคโนโลยีอย่างมาก แต่ตัวเทคโนโลยีกลับยิ่งเข้าใจได้ยากขึ้นเรื่อย ๆ
- แม้แต่ในสายความปลอดภัย ก็มีคำวิจารณ์ว่าหลายคนรู้แค่วิธีใช้เครื่องมือทดสอบเจาะระบบที่เตรียมไว้ล่วงหน้า แต่ไม่ค่อยเข้าใจเรื่องความปลอดภัยจริง ๆ
- ถ้าเว็บ GUI ของเครื่องมือแสดงไฟเขียว ก็อาจสมมติว่าทุกอย่างปกติดี
- แม้ผู้โจมตีจริงจะเจาะระบบได้แล้วและกำลังขายข้อมูลบน darknet ก็อาจยังไม่ถูกตรวจพบว่ามีการรั่วไหลหรือการบุกรุก
- มีการเชื่อมโยงไปยัง บทความของ Slashdot ที่ยกตัวอย่างว่านักศึกษาบางคนไม่รู้แม้แต่แนวคิดเรื่องไฟล์และโฟลเดอร์
- แนวทางปฏิบัติที่คนเรียนเทคโนโลยีควรทำมีดังนี้
- อย่าตามแต่แฟชั่นหรือเทรนด์
- อย่าเรียนรู้แค่เครื่องมือ แต่ให้เข้าใจว่า เทคโนโลยีพื้นฐาน ทำงานอย่างไร
- ถ้าเป็นไปได้ ให้ลองทำงานที่เครื่องมือตั้งค่าทำแทนด้วยตนเองสักครั้ง
- ถ้าเป็นไปได้ ให้ลองดูโค้ดของเครื่องมือ
- เรียนรู้และทดลองต่อไปเรื่อย ๆ และเจาะลึกเทคโนโลยีที่ตนสนใจ
- ถ้าเป็นไปได้ ให้สร้าง homelab เพื่อใช้เป็นสนามทดลองสำหรับการเรียนรู้และการพังระบบ
- ตั้งคำถามกับสิ่งที่ยังไม่เข้าใจ และอย่าคิดเป็นค่าปริยายว่าคนอื่นต้องรู้ดีกว่าเสมอ
- ทั้งหมดนี้ไม่ได้หมายความว่าทุกคนต้องเข้าใจทุกอย่างจากหลักการแรก หรือห้ามใช้เครื่องมือ
- abstraction เป็นสิ่งจำเป็น
- เช่นเดียวกับที่คนขับรถบรรทุกมีหน้าที่ขับรถ และช่างมีหน้าที่ซ่อมรถบรรทุก ความเชี่ยวชาญเฉพาะทางยังคงมีอยู่
- ปัญหาหลักคือ ทัศนคติแบบวิศวกร ที่ผู้ทำงานกับเทคโนโลยีควรมี กำลังอ่อนแอลง
- ในการพัฒนาซอฟต์แวร์ บทบาทของผู้เชี่ยวชาญมากเกินไปกำลังถูกแทนที่ด้วยเครื่องมือและระบบอัตโนมัติ
- มีคนจำนวนน้อยลงเรื่อย ๆ ที่เข้าใจแม้แต่ชั้นที่อยู่ถัดลงไปจากชั้นที่ตัวเองทำงานอยู่
- หากนักพัฒนาเว็บสร้างเว็บไซต์ด้วยเครื่องมือหรือเฟรมเวิร์กที่เตรียมไว้ โดยไม่มีความรู้เรื่อง TCP/IP, DNS, HTTP, TLS หรือความปลอดภัยเลย เมื่อลองเกิดปัญหาขึ้น ความสามารถในการรับมือก็จะลดลงอย่างมาก
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
ในประวัติศาสตร์การบินก็คงเคยมีช่วงเวลาที่คนที่ขับเครื่องบินได้ยังสามารถออกแบบและสร้างมันได้ด้วย และผมสงสัยว่าในตอนนั้นพวกเขากังวลถึงอนาคตที่คนซึ่งไม่ได้เข้าใจ หลักการพื้นฐาน ของเครื่องจักรจริง ๆ จะมานั่งอยู่ในห้องนักบินหรือไม่
ตอนนี้เราคุ้นเคยกับความคิดที่ว่าการขับเครื่องบินกับการสร้างเครื่องบินเป็นทักษะและอาชีพคนละอย่างกัน และก็ยอมรับได้เป็นธรรมชาติว่า วิศวกรการบินไม่จำเป็นต้องรู้เรื่องการทำเหมืองบอกไซต์หรือการถลุงอะลูมิเนียม
ถ้ามองเห็นภาพรวมทั้งเส้นทางตั้งแต่ลอจิกเกตไปจนถึงเว็บรีเควสต์ได้ก็อุ่นใจ แต่ไม่ใช่สิ่งจำเป็น การที่วิศวกรซึ่งมีภาพรวมแบบนั้นลดน้อยลง น่าจะเป็นปรากฏการณ์ที่แสดงถึง ความเติบโตเต็มวัยของอุตสาหกรรมเทคโนโลยี และการแยกสาขาเฉพาะทาง มากกว่าจะเป็นสัญญาณเตือน
เช่น ในคำพูดทำนอง “กลับไปเขียนแอสเซมบลีกันเถอะ” แม้หลังจากภาษาระดับสูงกลายเป็นกระแสหลักแล้ว โปรแกรมเมอร์ก็ยังต้องรู้แอสเซมบลีไปอีกค่อนข้างนาน เพราะ abstraction ของคอมไพเลอร์และเครื่องมือดีบักยังรั่วอยู่
ปัญหาของวันนี้คือเราซ้อน abstraction ที่รั่ว เป็นชั้น ๆ โดยไม่ให้เวลามันเติบโตเต็มที่ ออกแบบไปในทางลดเวลาทำงานภายใต้สมมติฐานผิด ๆ ว่านักพัฒนาจะอยู่บน happy path เสมอ แต่ในความเป็นจริง เวลาส่วนใหญ่ถูกใช้ไปกับการดีบักสถานการณ์ที่ไม่เป็นไปตามแบบ หากทำให้ happy path เร็วขึ้น แต่ทำให้ unhappy path ช้าลง โดยรวมแล้วมักจะขาดทุนสุทธิ
ระบบอัตโนมัติของ Airbus ทำให้แทบเป็นไปไม่ได้ที่จะเกิด stall เว้นแต่จะมีบางอย่างผิดพลาดร้ายแรงจนย้อนกลับไปใช้กฎการควบคุมแบบ manual ดังนั้นเขาจึงไม่ได้เข้าใจอย่างถูกต้องว่า stall ทำงานอย่างไร ในเที่ยวบินนั้นสิ่งนั้นเกิดขึ้นพอดี และเมื่อกัปตันกลับเข้ามาในห้องนักบิน เขาก็มองออกทันทีว่าเป็น deep stall แต่ก็สายเกินไปแล้ว
วิดีโอ Mentour Pilot ที่เกี่ยวข้อง: https://invidious.protokolla.fi/watch?v=e5AGHEUxLME&t=1
กระบวนการบินมีข้อจำกัดทางกายภาพตั้งแต่แรก แต่คอมพิวติ้งและกรอบคิดเกี่ยวกับมันเปลี่ยนแปลงได้ไม่สิ้นสุดและมีขอบเขตการประยุกต์ใช้กว้างมาก ถ้าย้ายเรื่องไร้สาระที่ขายกันทุกวันนี้ไปเป็นอุปมาเรื่องการบิน มันก็ใกล้เคียงกับการขายการขี่ลาโดยเรียกว่าการบิน ลูกค้าจำนวนมากไม่มีความรู้พอจะแยกความต่างได้
วัตถุดิบสำคัญของความก้าวหน้าคือ เราจะกระโดดต่อยอดครั้งใหญ่บนพื้นฐานของสิ่งใดสิ่งหนึ่งได้ ก็ต่อเมื่อเราค้นพบวิธีทำให้สิ่งนั้นเรียบง่ายลง หากมันซับซ้อนเกินไป ก็จะมีขีดจำกัดต่อระยะทางและความสูงที่ไปถึงได้ คล้ายกับการขยายหนี้ทางเทคนิคไปสู่ระดับมนุษยชาติ
น่าเสียดายที่ในประวัติศาสตร์ เรามักมองไม่ค่อยออกเมื่อมีบางอย่างถูกทำให้ง่ายลงอีกขั้น เพราะเมื่อมองย้อนหลัง มันจะดูเป็นธรรมชาติและเหมือนเป็นเรื่องแน่นอนอยู่แล้ว
เด็กสมัยนี้ดูเหมือนจะไม่ได้รับการยอมรับมากพอ ไม่กี่สัปดาห์ก่อน ลูกชายของเพื่อนตื่นเต้นมากที่ได้โชว์ เกม Roblox ที่เขากำลังทำกับเพื่อน ๆ
ตอนนั้นเป็นวันขอบคุณพระเจ้าของแคนาดา มีครอบครัวและคนรู้จักอยู่กันเยอะ เขาเลือกไว้แล้วว่าแต่ละคนจะสนใจส่วนไหน และผมคือ “คนที่จะให้ดู Lua”
ผู้คนคิดว่าโทรศัพท์หรือแล็ปท็อปถูกล็อกไว้จนไม่กระตุ้นความอยากรู้อยากเห็น เด็ก ๆ ก็คงเป็นแบบนั้น แต่กลับกัน ผมว่าเป็นผู้ใหญ่ต่างหากที่อยากรู้อยากเห็นน้อยลง
แน่นอนว่ามันสร้างอยู่บน abstraction แต่แม้ในหมู่ภูเขาของ abstraction ระดับสูง ก็ยังมีหุบเขาที่คนกลุ่มน้อยซึ่งอยากรู้อยากเห็นเข้าไปเสมอ C64 BASIC เคยเปิดให้ POKE ไปยังที่อยู่หน่วยความจำใดก็ได้ แต่การได้ฟังเด็กอายุ 10 ขวบอธิบายเกมสะสม 3D ซับซ้อนที่มีองค์ประกอบ FPS ก็เป็นเรื่องเจ๋งไม่น้อย
ให้บรรยากาศเหมือนคนแก่ตะโกนใส่เมฆ
การที่บางคนเป็นผู้เชี่ยวชาญและบางคนทำได้แค่พอใช้ ไม่ใช่เรื่องใหม่ ทุกคนไม่อาจเป็นผู้กอบกู้เหมือนผู้เขียนที่ใช้ครึ่งหนึ่งของบทความสั้น ๆ นี้ไปกับการอวดตัวเอง
บทความนี้แทบไม่เกี่ยวกับ abstraction เลย หลังจากสองย่อหน้าแรก ผู้เขียนก็หมดความสนใจในประเด็นของตัวเองไปแล้ว
ตัวอย่างก็แย่มาก “มีคนใช้เฟรมเวิร์กสมัยใหม่แล้วถูกแฮ็ก แต่ปัญหาประสิทธิภาพไม่ได้เกิดจากการแฮ็ก หากเกิดจากเฟรมเวิร์กที่ช้าอย่างเลวร้าย” แล้วมันคือเฟรมเวิร์กอะไร รู้ได้อย่างไรว่าช้าเพียงจากการดู diff และการปรับแต่งเครื่องมือให้เหมาะกับประสิทธิภาพไม่ได้เกี่ยวอะไรกับ abstraction ตรงไหน
อีกปัญหาหนึ่งคือ เราเคยเลือกใช้ abstraction ที่ผิด อยู่หลายครั้ง ทุกวันนี้ในวงการซอฟต์แวร์มีวัฒนธรรมเดี่ยวที่โอหัง เชื่อว่าเรามาถึงปลายทางของประวัติศาสตร์และรู้ทุกอย่างหมดแล้ว
แต่จริง ๆ แล้ว ผมมองว่าเทคโนโลยีจำนวนมากในช่วงหลังเดินลงทางผิดไป จนราว ๆ ปี 2014 ทุกอย่างดูเหมือนกำลังไปในทิศทางที่ถูกต้อง แต่หลังจากนั้นความก้าวหน้ากลับถอยหลัง และทุกคนก็เริ่มใช้เฟรมเวิร์กที่ถูกโหมกระแสแบบเดียวกันหมด เมื่อบริษัทต่าง ๆ บังคับให้ทุกคนใช้เฟรมเวิร์กเหล่านี้ การพัฒนาซอฟต์แวร์ก็กลายเป็นงานที่ไม่มีประสิทธิภาพและบั่นทอนกำลังใจ
ผมสร้าง SDK สำหรับใช้ในโปรเจกต์ส่วนตัวขึ้นมาเอง ซึ่งมีประสิทธิภาพในการทำงานมากกว่าเฟรมเวิร์กกระแสหลักที่ใช้ในงานบริษัทอย่างน้อย 10 เท่า และโค้ดก็อ่านและดูแลรักษาง่ายกว่ามาก ถึงเอาไปให้จูเนียร์ที่ไม่รู้จักเฟรมเวิร์กนั้นดูก็ยังทำงานได้อย่างมีประสิทธิภาพ ผมใช้ SDK นี้สร้างแพลตฟอร์ม no-code BaaS แบบพาร์ตไทม์ใน 2 เดือนได้ ซึ่งผมคิดว่าถ้าใช้เครื่องมือและเฟรมเวิร์กกระแสหลัก ไม่ว่าผมหรือใครก็คงทำให้เสร็จภายใน 12 เดือนแบบฟูลไทม์ได้ยาก
แน่นอนว่ามันอาจมีจุดที่ดีกว่าเฟรมเวิร์กอื่น แต่ ความคุ้นเคยสร้างความเชี่ยวชาญ และความเชี่ยวชาญสร้างผลิตภาพ
ก่อนที่สกรู drywall จะเป็นที่นิยม ช่างฝีมือจำนวนมากเชื่อมั่นว่าสกรูช้ากว่าและแย่กว่า แต่ทั้งผู้เชี่ยวชาญด้านการตอกตะปูและผู้เชี่ยวชาญด้านการขันสกรูก็ทำงานได้เร็วและดีทั้งคู่
ไม่ว่าจะ frontend หรือ backend ก็มีเหตุผลที่เราใช้ “เฟรมเวิร์กเหล่านี้” คุณอาจไม่ชอบเหตุผลนั้น แต่การเขียนโปรแกรมในองค์กรไม่ได้มีแค่ความบริสุทธิ์ของภาษาเท่านั้น ยังมีปัจจัย ที่ทำเงินได้ อย่างความสามารถในการจ้างคน ความดูแลรักษาได้ และความต่อเนื่อง
ถ้าบริษัทใช้ SDK ที่คุณทำเฉพาะเอง แล้วคุณลาออกไปจะเกิดอะไรขึ้น? คุณอาจคิดว่าสอนคนอื่นได้ง่าย แต่การตัดสินใจด้านเทคโนโลยีของบริษัทมีปัจจัยมากกว่านั้นมาก
ประโยคที่ว่า “ผู้เชี่ยวชาญที่เรียกกันแบบนั้นในทุกวันนี้จำนวนมากรู้แค่วิธีตั้งค่าเครื่องมือฮิต ๆ บางอย่าง แต่ไม่เข้าใจเลยว่าในระดับที่ลึกกว่านั้นงานมันทำงานอย่างไร” กระแทกใจมาก
ทุกคนรู้ ขั้นตอนแบบท่องจำ อย่าง “ถ้าจะทำ X ให้เพิ่มบรรทัดนี้ในไฟล์ config” แต่พอต้องทำสิ่งที่ต่างจาก X เล็กน้อย หรือรูปแบบแปรผันของ X ก็ไม่รู้ว่าจะออกนอกสคริปต์อย่างไร แย่กว่านั้นคือทำให้คนเสียเวลาพยายามลากบทสนทนาจากสิ่งที่ไม่ค่อยใช่ X กลับไปเป็น X อีกครั้ง นึกถึงอุปมาคนทำกระเป๋าสตางค์หายแต่ไปหากันเฉพาะใต้เสาไฟ
ผมคิดว่าการสร้างระบบนิเวศทางเทคโนโลยีที่มีแค่ความรู้แคบ ๆ ก็ยังช่วย योगदानได้ หรือ “techosystem” แบบหนึ่งนั้นเป็นเรื่องที่ยอดเยี่ยม ถ้าพูดในแง่บวกน้อยลง ก็คือมันทำให้บริษัทจ้างแรงงานที่ถูกกว่าและต้องการทักษะน้อยลงได้
ในหลายกรณี ผมเชื่อว่า ทางออกธรรมดา ๆ ดีกว่าไม่มีทางออกเลย อินเทอร์เน็ตช่วงปี 1995–2005 สร้างขึ้นบนทางออกธรรมดา ๆ และมันสนุกมากจริง ๆ
ผู้เชี่ยวชาญสายเจาะลึกไม่ได้เป็นสายพันธุ์ที่กำลังสูญหาย และไม่ใช่ทรัพยากรจำกัดที่ถือครองความรู้ลับจากยุคก่อน abstraction ด้วย ตรงกันข้าม ตอนนี้มีมากกว่าที่เคย พวกเขาไม่ได้ถูกนิยามด้วยการเคยทำมาทั้งบนและล่างของ stack แต่ถูกนิยามด้วยความอยากรู้อยากเห็นที่จะมองเข้าไปในจุดที่ไม่ใช่ชั้นของตัวเอง
เพราะนอกจากจะมีชั้น abstraction เพิ่มขึ้นด้านบนแล้ว ชั้นด้านล่างก็เปลี่ยนไปเช่นกัน เช่น NVMe, WebGPU, WebAssembly, QUIC, AVX512
อย่างไรก็ดี ผมมองว่า ผู้เชี่ยวชาญสายเจาะลึก เป็นความฟุ่มเฟือยที่ทีมส่วนใหญ่ไม่จำเป็นต้องมี และหนึ่งในความสามารถสำคัญที่สุดของผู้จัดการด้านเทคโนโลยีคือการรู้ว่าเมื่อไรจำเป็นต้องจ้างคนแบบนั้นจริง ๆ
การเพิ่มขึ้นของระดับ abstraction เป็นสิ่งจำเป็น สมองมนุษย์ไม่ได้เก่งขึ้นมากเรื่อย ๆ ทุกปี แต่จำนวนเครื่องมือที่ใช้ได้เพิ่มขึ้น ดังนั้นถ้าจะโฟกัสก็ต้องมี abstraction
ผมไม่คิดว่านี่หมายความว่าอนาคตจะมืดมน โปรแกรมเมอร์ที่จัดการปัญหาทางธุรกิจสามารถมีผลิตภาพสูงมากในภาษาระดับสูงได้ โดยไม่ต้องรู้เรื่อง EUV, compiler, assembly, instruction set, kernel, USB protocol, HTTP, die, PCB ฯลฯ นักบินเองก็ไม่จำเป็นต้องรู้ทั้งหมดเรื่อง aerodynamics, tensile strength, aluminum, rubber, GPS ฯลฯ
แต่ ความไม่สอดคล้องของแรงจูงใจ ในสังคมสมัยใหม่เป็นเรื่องที่ควรค่าแก่การถกเถียงอย่างยิ่ง โดยทั่วไปผมไว้ใจนักบินมากกว่านักพัฒนาซอฟต์แวร์ธุรกิจ นักวิจัย หรือเจ้าหน้าที่ธนาคาร เพราะถ้าเครื่องตก นักบินจะไปถึงก่อนใคร
ซอฟต์แวร์สำหรับเครื่องยิงหินต้องการแนวทางที่ต่างจากแอป CRUD ที่ทั่วไปเกินไปซึ่งเปิดเผยอะไรอย่างจำนวนคฤหาสน์ที่คุณมี
โลกนี้มีซอฟต์แวร์โง่ ๆ อยู่มาก และนั่นก็ไม่เป็นไร “ปัญหาจริง” จำนวนมากก็ค่อนข้างโง่ และไม่ต้องการวิศวกรรมระดับวีรบุรุษ
ในจำนวนกรณีที่น่ากลัวมาก แค่ ซอฟต์แวร์ห่วย ๆ ที่ปะ ๆ ต่อ ๆ กันมาก็เพียงพอแล้ว
ผมเองก็ไม่ชอบ แต่ก็เริ่มคิดว่าเรามีทางเลือกแค่ใช้วิศวกรรมที่เหนือกว่าของตัวเองสร้างธุรกิจมาแข่งและชนะเพื่อพิสูจน์ว่าพวกเขาผิด หรือไม่ก็ยอมรับว่าผมกำลังตะโกนใส่ก้อนเมฆอยู่
เวลาโรงพยาบาลตัดสินใจซื้อ พวกเขาไม่ได้ตรวจคุณภาพซอฟต์แวร์เกินระดับประมาณ “ปุ่มนี้กดไม่ติด” มากนัก
วิธีที่บทความวิจารณ์ abstraction ใส่ไฮเปอร์ลิงก์ไว้ที่ประโยค “ทุกวันนี้มีนักเรียนบางคนที่ไม่รู้ด้วยซ้ำว่าไฟล์และโฟลเดอร์คืออะไร” นั้นเหมาะอย่างประหลาด
ลิงก์นั้นพาไปยังเธรด Slashdot จากนั้นต่อไปยังบทความของ PC Gamer แล้วบทความนั้นก็เขียนขยายและลิงก์ไปยังบทความของ Verge อีกที และบทความของ Verge ก็พาไปยังคำถามใน Stack Exchange
พูดอีกอย่างก็คือ cargo cult programming นั่นเอง ผมเคยเขียนเรื่องนี้ไว้เมื่อ 2 ปีก่อน [1] และปฏิกิริยาก็แบ่งเป็นสองขั้วสุด ๆ คือเห็นด้วยอย่างเต็มที่ หรือไม่ก็โจมตีอย่างรุนแรงว่าเป็นการ gatekeeping
ถ้ามีวิธีที่ดีกว่านี้ในการรักษาโรคนี้ โดยไม่ไปกระทบระบบภูมิคุ้มกันทางวิชาชีพของวิศวกรที่ทุ่มเทกับเทคโนโลยีโปรดของตัวเองอย่างลึกซึ้งก็คงดี
[1] https://medium.com/the-engineering-manager-guide/cargo-cult-...
ทั้งสองคนไม่เข้าใจคำถาม แต่เขาก็ไม่ได้ชี้แจงคำถามให้ชัดขึ้น หรือแม้แต่พิจารณาว่าปัญหาอาจอยู่ที่ตัวคำถามเอง
ประโยคที่ว่า “ให้ผู้เชี่ยวชาญ React.js ลองเปรียบเทียบแนวทาง SPA ต่าง ๆ เช่น การจัดการ DOM โดยตรง, เทมเพลตฝั่งไคลเอนต์แบบ MVC, การจัดการ DOM แบบคอมโพเนนต์, วิธีคอมไพล์เป็น vanilla JS” บอกตรง ๆ ว่าผมเองก็ไม่รู้เหมือนกันว่าหมายถึงอะไร
ไม่รู้ว่า “คอมไพล์เป็น vanilla JS” หมายถึงการคอมไพล์ TypeScript เป็น JavaScript หรือเปล่า และมันเกี่ยวอะไรกับ DOM ด้วย “การจัดการ DOM แบบคอมโพเนนต์ที่อิง MVC” ก็แปลกเหมือนกัน ให้ความรู้สึกเหมือนคนที่อ่านหนังสือ design patterns แล้วหักคะแนนคนที่ไม่ได้ใช้คำศัพท์เดียวกับตัวเอง มากกว่าจะเป็นคนที่เข้าใจการพัฒนาอย่างลึกซึ้งกว่า
คนที่เพลิดเพลินกับความพึงพอใจเมื่อทำงานได้ดีจริง ๆ โดยทั่วไปผมคิดว่าจะใช้เวลามากกว่าคนที่แค่อยากให้งานเสร็จ เพื่อพยายามทำความเข้าใจอะไรบางอย่างอย่างแท้จริง
แต่ความอยากรู้นั้นให้อะไรกับเราบ้าง? ผมนึกถึงเรื่องเล่านี้จาก fortune(6) และสงสัยว่าคนที่ไม่มีความอยากรู้อยากเห็นจะเข้าใจมันได้สักกี่คน
มือใหม่คนหนึ่งพยายามซ่อมเครื่อง Lisp ที่เสียด้วยการปิดแล้วเปิดเครื่องใหม่ Knight เห็นเข้าจึงพูดอย่างเข้มงวดว่า “แค่ปิดแล้วเปิดเครื่องใหม่โดยที่ยังไม่เข้าใจว่าอะไรผิดพลาดอยู่ เจ้าซ่อมเครื่องไม่ได้หรอก” Knight ปิดแล้วเปิดเครื่องใหม่ เครื่องก็ทำงาน
มันถูกใช้เหมือนเป็นไพ่ตัดสินว่า “คุณกำลัง gatekeeping อยู่ ดังนั้นฉันชนะ” ซึ่งเป็นความคิดที่ไร้สาระ ไม่มีอะไรผิดกับการปกป้องมาตรฐานความเชี่ยวชาญระดับสูง และนั่นก็เป็น gatekeeping โดยแก่นแท้ เวลาไปหาหมอ ผมรู้สึกขอบคุณมากที่การแพทย์เป็นอาชีพที่มีการ gatekeeping