เลิกอ่านเพื่อสะสมความรู้ แต่จงเริ่มอ่านเพื่อแก้ปัญหา
รายการหนังสืออ่านสำหรับวิศวกรส่วนใหญ่มักเน้นไปที่การสะสมความรู้ แต่วิศวกรรมสมัยใหม่ให้รางวัลแก่ผู้ที่สามารถแก้ปัญหาคอขวด (bottlenecks) ได้
เมื่อไม่นานมานี้ วิศวกรระดับ Junior คนหนึ่งได้แสดงรายการ "10 อันดับหนังสือสำหรับวิศวกร" ให้ผมดู ซึ่งมันดูเหมือนกับรายการเมื่อสิบปีก่อนไม่มีผิด และมันยังคงตั้งอยู่บนสมมติฐานเดิมๆ
สมมติฐานนั้นคือการอ่านหนังสือให้มากพอจะทำให้คุณเป็นวิศวกรที่ดีขึ้น แต่ทีมที่มีประสิทธิภาพสูงไม่ได้เรียนรู้ด้วยวิธีนี้
วิศวกรที่เก่งที่สุดจะสร้างแผนการเรียนรู้โดยอิงจากข้อจำกัด (constraints)
รายการหนังสืออ่านทั่วไปมักสมมติว่าความรู้ทุกอย่างมีค่า แต่ในความเป็นจริง คุณค่าทางวิศวกรรมนั้นขึ้นอยู่กับบริบท
• วิศวกร Backend ที่กำลังเผชิญกับปัญหาด้านฐานข้อมูล ไม่จำเป็นต้องอ่านหนังสือเรื่อง Agile • ทีมที่ใช้จ่ายงบประมาณด้าน AI inference มากเกินไป ไม่จำเป็นต้องอ่านหนังสือเรื่อง craftsmanship ทั่วไป • สตาร์ทอัพที่กำลังเผชิญกับปัญหาเรื่อง latency ไม่จำเป็นต้องอ่านเรื่อง leadership framework
คนเหล่านี้ต้องการทางออกสำหรับปัญหาคอขวดเฉพาะหน้าที่พวกเขากำลังเผชิญ รายการหนังสืออ่านมักเน้นความครบถ้วน แต่ในงานวิศวกรรม สิ่งที่สำคัญกว่าคือความเกี่ยวข้อง (relevance)
พื้นฐานอย่างฐานข้อมูลและระบบเครือข่ายยังคงสำคัญ แต่แค่นั้นไม่เพียงพออีกต่อไป
ระบบสมัยใหม่มาพร้อมกับข้อจำกัดใหม่ๆ ตัวอย่างที่ชัดเจนคือต้นทุนของ AI inference ซึ่งรายการหนังสือแบบเดิมๆ มักไม่ค่อยครอบคลุมปัญหาเหล่านี้
ความท้าทายไม่ใช่แค่การเขียนซอฟต์แวร์ให้ถูกต้องอีกต่อไป แต่คือการสร้างระบบที่เชื่อถือได้ (reliable systems) บนองค์ประกอบที่มีความน่าจะเป็น (probabilistic components)
ในอดีต วิศวกรทำงานกับระบบแบบ deterministic ซึ่ง input แบบเดิมจะให้ output แบบเดิมเสมอ
แต่ในปัจจุบัน ระบบทำงานต่างออกไป Prompt หนึ่งอาจให้คำตอบที่ต่างกัน Agent อาจเลือกเส้นทางที่ต่างกัน หรือการอัปเกรดโมเดลอาจเปลี่ยนพฤติกรรมของระบบโดยที่คุณไม่ได้แก้ไขโค้ดเลยด้วยซ้ำ
คำถามใหม่ๆ คือ: • คุณจะประเมินคุณภาพได้อย่างไร? • คุณจะจัดการกับการเปลี่ยนแปลงเหล่านี้ได้อย่างไร?
สิ่งเหล่านี้ไม่ใช่กรณีพิเศษ (edge cases) แต่มันคืองานวิศวกรรมที่ต้องเจอในทุกๆ วัน
วิศวกรที่เก่งจะไม่ไม่อ่านหนังสือตั้งแต่หน้าแรกจนหน้าสุดท้าย แต่พวกเขาจะอ่านเพื่อทำความเข้าใจกลไก (mechanisms) พวกเขาจะหาคอขวด ระบุกลไกที่เกี่ยวข้อง และเรียนรู้เฉพาะสิ่งที่จำเป็นเท่านั้น
• หาก latency สูง ให้ศึกษาเรื่อง batching • หากปัญหาคือเรื่อง context ให้ศึกษาเรื่อง retrieval • หาก agent ทำงานผิดพลาด ให้ศึกษาเรื่อง evaluation
สิ่งนี้เชื่อมโยงการเรียนรู้เข้ากับการทำงานจริง (production) โดยตรง และทำให้ความรู้กลายเป็นพลังทวี (leverage)
ใช้ลูปการเรียนรู้นี้:
- ระบุปัญหาคอขวด
- หาแหล่งข้อมูลที่เจาะจงสำหรับปัญหานั้น
- นำทางออกไปปรับใช้
เลิกพยายามอ่านหนังสือให้จบตามรายการ แต่จงเริ่มพยายามปรับปรุงระบบให้ดีขึ้น
ก่อนจะเริ่มอ่านหนังสือเล่มถัดไป ลองถามตัวเองดูว่า: อะไรคือข้อจำกัดที่ใหญ่ที่สุดในระบบของฉัน?
มันคือเรื่อง Latency, ต้นทุน, Reliability หรือ Observability?
จงหาแหล่งข้อมูลที่จะมาจัดการกับคอขวดนั้น งานวิศวกรรมไม่ใช่การแข่งขันกันอ่านหนังสือ แต่มันคืออาชีพที่ว่าด้วยการแก้ปัญหาภายใต้ข้อจำกัด
ระบบจะเป็นตัวกำหนดว่าคุณควรจะเรียนรู้อะไรเป็นลำดับถัดไป