ความสุขและพลังของความเข้าใจ

 (binaryigor.com)
3 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • หากเข้าใจซอฟต์แวร์อย่างลึกซึ้ง เราจะไม่ถูกเครื่องมือชี้นำ และสามารถมี การควบคุมและความเป็นเจ้าของ ต่อระบบที่ตนรับผิดชอบได้
  • การค้นหาและ LLM ให้คำตอบได้รวดเร็ว แต่การติดนิสัยคัดลอกวิธีแก้ที่อธิบายไม่ได้ อาจบั่นทอนความสามารถในการแก้ไขและ ความสามารถหลัก ได้
  • สำหรับสคริปต์ใช้ครั้งเดียวหรือ UI ภายในที่มีความเสี่ยงต่ำ การให้生成หรือคัดลอกมาแปะอาจสมเหตุสมผล แต่โค้ดที่ต้องดูแลระยะยาวควรสร้างด้วย เทคโนโลยีที่เข้าใจอย่างลึกซึ้ง
  • หากวัดผลิตภาพจากแค่ output อย่างจำนวนบรรทัดโค้ดหรือจำนวน PR ก็อาจบิดเบือนได้ง่าย ขณะที่ outcome อย่างรีลีสที่เสถียร การทำให้เรียบง่าย การทำอัตโนมัติ และการทดสอบ ใกล้กับคุณค่าระยะยาวมากกว่า
  • ซอฟต์แวร์สมัยใหม่ซับซ้อนขึ้นตั้งแต่รันไทม์ เครือข่าย ความปลอดภัย ฐานข้อมูล ไปจนถึง AI แต่หากเรียนรู้ หลักการพื้นฐาน ก็จะเข้าใจเครื่องมือและแนวทางใหม่ ๆ ได้เร็วขึ้น

การควบคุมและความสุขที่มาจากความเข้าใจ

  • ความเข้าใจอย่างลึกซึ้งคือ เงื่อนไขที่เป็นรูปธรรม สำหรับการแก้ไขและเปลี่ยนแปลงโค้ดกับระบบ
  • สิ่งที่เราไม่เข้าใจนั้นแก้ไขหรือเปลี่ยนแปลงได้ยาก และท้ายที่สุดการควบคุมกับความเป็นเจ้าของเหนือโค้ดที่เรารับผิดชอบก็จะอ่อนแอลง
  • ความเข้าใจไม่เพียงทำให้เราเป็นนายของเครื่องมือ แต่ยังให้ความพึงพอใจทางจิตใจด้วย
  • การกระทำที่ช่วยให้เราควบคุมสภาพแวดล้อมได้ดีขึ้น ย่อมเชื่อมโยงกับความรู้สึกเชิงบวกอย่างเป็นธรรมชาติ

ความเกียจคร้านของมนุษย์และการพึ่งพา LLM

  • มนุษย์มีแนวโน้มจะลดการใช้พลังงานและเพิ่มผลตอบแทนให้คุ้มกับการลงทุน
  • ความเกียจคร้าน นี้เป็นแรงจูงใจให้ทำงานที่น่าเบื่อและมีต้นทุนสูงให้เป็นอัตโนมัติ แต่ในการเรียนรู้และสร้างความชำนาญ มันอาจเป็นจุดอ่อนได้
  • ด้วยอินเทอร์เน็ตและ LLM เราสามารถได้คำตอบของปัญหาคล้าย ๆ กันในรูปแบบที่ต้องการอย่างง่ายดาย จึงยิ่งข้ามกระบวนการทำความเข้าใจได้ง่าย
  • แทนที่จะเรียน SQL ด้วยตนเอง หากเพียงบอกตารางและข้อมูลที่ต้องการกับ LLM แล้วคัดลอกผลลัพธ์มาใช้ มันอาจง่ายในตอนนั้น แต่ความสามารถในการใช้งานอย่างถูกต้องจะไม่สะสม
  • แม้ LLM จะสร้าง SQL ได้เร็วกว่า แต่ทักษะการอ่านและทำความเข้าใจที่เคยสร้างจากการฝึกทำซ้ำด้วยตนเองในอดีต หากไม่ใช้ก็จะถดถอยลง
  • LLM และเสิร์ชเอนจิน ในกรณีที่ดีที่สุดคือ ตัวคูณศักยภาพ (force multiplier) แต่ต้องมีพื้นฐานที่แข็งแรงก่อน
  • ทักษะและความรู้หลักนั้นยากจะรักษาไว้ได้ด้วยการค้นหา การเขียนพรอมป์ต และการตรวจสอบด้วยตนเองเพียงอย่างเดียว เราต้องมีส่วนร่วมในกระบวนการสร้างและประดิษฐ์ด้วยตนเอง
  • เราควรฝืนแนวโน้มความเกียจคร้านของตนเองเป็นประจำ ด้วยการอ่านเอกสารและซอร์ส ทำความเข้าใจเหตุผลของวิธีแก้และ trade-off ของเครื่องมือ รวมถึงออกแบบวิธีแก้และอัลกอริทึมด้วยตนเอง

สมดุลระหว่างผลิตภาพระยะสั้นกับความเข้าใจระยะยาว

  • ไม่จำเป็นต้องเข้าใจโค้ดและวิธีแก้ทุกอย่างอย่างสมบูรณ์ และสามารถใช้มาตรฐานต่างกันตามสถานการณ์ได้
  • สคริปต์ใช้ครั้งเดียว ที่มีความสำคัญและความเสี่ยงต่ำ จะคัดลอกหรือให้สร้างขึ้นมาก็ได้
  • UI หรือหน้าเว็บภายในที่มีผู้ใช้เพียงสองสามคนก็อาจอนุญาตให้ใช้วิธีเดียวกันได้
  • แต่โค้ดที่ต้องเป็นเจ้าของ ดูแลรักษา และพัฒนาต่อไปอีกหลายเดือนหรือหลายปี ควรถูกสร้างด้วยภาษาและเทคโนโลยีที่เราเข้าใจอย่างลึกซึ้ง
    • เราควรเข้าใจทุกบรรทัด ทุกคำ ทุกอักขระ และทุกตัวเลือกการตั้งค่า หรืออย่างน้อยก็มุ่งไปในทิศทางนั้น
    • แทนที่จะมุ่งผลิตผลงานจำนวนมากทันที ควรเพิ่มประสิทธิภาพเพื่อความเข้าใจระยะยาว การบำรุงรักษา และผลิตภาพในระยะยาว
  • หากเป็น MVP หรือฟีเจอร์ทดลองในผลิตภัณฑ์เดิมที่ยังไม่แน่ว่าจะสำเร็จหรือไม่ ก็อาจลดมาตรฐานด้านคุณภาพและความเข้าใจลงได้เล็กน้อย
  • การเลือกแบบนี้คล้ายกับการก่อ หนี้ทางการรับรู้
    • ตอนนี้เราจะเคลื่อนไหวได้เร็วขึ้น
    • แต่เมื่อผลิตภัณฑ์หรือฟีเจอร์นั้นเริ่มทำงานจริง หรือต้องแก้ไขและเปลี่ยนแปลง เราจะต้องจ่ายคืนมากขึ้นในภายหลัง
  • ถึงอย่างนั้น อย่างน้อยก็ควรเข้าใจและตรวจสอบให้มากพอที่จะพูดได้อย่างมั่นใจว่า “มันทำงานได้”
  • ในบางกรณี การสร้างขึ้นมาก่อนแล้วตรวจสอบ จากนั้นเขียนใหม่ทั้งหมดตั้งแต่ต้น ก็อาจเป็นกลยุทธ์ที่สมเหตุสมผล

ผลทบต้นของเทคโนโลยีสแตกและความชำนาญ

  • หากเป็นภาษาโปรแกรม ไลบรารี หรือเครื่องมือที่ใช้เป็นครั้งคราว ก็ไม่จำเป็นต้องลงทุนเวลาไปกับการเรียนรู้เชิงลึกและสร้างความชำนาญมากนัก
  • หากสามารถตรวจสอบผลลัพธ์ได้ บางครั้งการคัดลอกหรือให้สร้างสิ่งที่เข้าใจเพียงบางส่วนก็พอใช้ได้
  • แต่หากข้ามช่วงของการเรียนรู้และความยากลำบากไป เราก็กำลังลดโอกาสของตัวเองที่จะชำนาญและใช้งานเทคโนโลยีนั้นได้อย่างมีผลิตภาพ
  • ในเทคโนโลยีสแตกหลักที่ใช้อย่างสม่ำเสมอ ความชำนาญ อาจให้ผลตอบแทนมากขึ้นเป็นร้อยเท่าหรือพันเท่า
  • ความรู้และทักษะมี ผลทบต้น
    • ยิ่งรู้มาก ก็ยิ่งสร้างสิ่งต่าง ๆ ได้เร็วขึ้นด้วยตนเอง
    • ยังสามารถเรียนรู้ความรู้และทักษะใหม่ ๆ ได้เร็วขึ้นเรื่อย ๆ
    • ยิ่งความสามารถเพิ่มขึ้น ก็ยิ่งคิดวิธีแก้และไอเดียใหม่ ๆ ได้

ผลิตภาพที่มุ่ง Outcome มากกว่า Output

  • วิธีทำความเข้าใจและวัดผลิตภาพ แบ่งได้กว้าง ๆ เป็นแบบ เน้น output และ เน้น outcome
  • การวัดแบบ output นั้นง่ายและนับเป็นตัวเลขได้สะดวก
    • จำนวนบรรทัดโค้ดที่เขียน
    • จำนวน PR ที่เปิดและ merge
    • จำนวนฟีเจอร์ที่พัฒนา
    • จำนวนบั๊กที่พบและแก้ไข
    • จำนวนงานที่ทำเสร็จ
  • ตัวชี้วัดแบบเน้น output ถูกบิดเบือนได้ง่าย
    • อาจเขียนโค้ดยืดยาวเกินจำเป็น
    • อาจสร้าง PR เล็ก ๆ จำนวนมาก
    • อาจแยกงานออกเป็นชิ้นเล็ก ๆ อย่างไม่เป็นธรรมชาติ
    • อาจเพิ่มฟีเจอร์ที่ไม่มีประโยชน์
  • แม้ตัวเลขจะเพิ่มขึ้น ก็ยากจะรับประกันว่าเป็นทิศทางที่ถูกต้อง
    • PR มากขึ้นไม่ได้แปลว่าดีกว่าเสมอไป
    • การที่โค้ดเบสใหญ่ขึ้นก็ไม่ได้เป็นสิ่งพึงประสงค์เสมอ
    • บางครั้งแทนที่จะเพิ่มฟีเจอร์ การลบฟีเจอร์ที่ไม่มีคนใช้กลับดีกว่า
  • ตัวอย่างแบบเน้น outcome เชื่อมโยงกับคุณค่าระยะยาวโดยตรงมากกว่า
    • รีลีสโปรดักชันมีเสถียรภาพมากขึ้นด้วยกระบวนการ CI/CD ใหม่
    • การรีแฟกเตอร์และทำให้เรียบง่ายช่วยให้ดูแลรักษาและเปลี่ยนแปลงในอนาคตได้ง่ายขึ้น
    • การออกแบบวิธีเชื่อมต่อใหม่ทำให้เพิ่มพาร์ตเนอร์รายใหม่ได้เร็วขึ้นและประหยัดทรัพยากรคอมพิวต์
    • เพิ่ม การทดสอบ เพื่อจับบั๊กล่วงหน้าและป้องกัน regression
    • เพิ่มเมตริกและการแจ้งเตือนเพื่อค้นหาปัญหาและบั๊กที่อาจเกิดขึ้นได้เชิงรุก
    • ทำงานมือที่น่าเบื่อให้เป็นอัตโนมัติเพื่อประหยัดเวลาและลดโอกาสของความผิดพลาดร้ายแรง
  • ผลิตภาพและความเข้าใจในระยะยาวสอดคล้องกับตัวชี้วัดแบบเน้น outcome มากกว่า และ output ที่มากขึ้นก็ไม่ได้ดีกว่าเสมอไป

ซอฟต์แวร์ที่ซับซ้อนขึ้นและหลักการพื้นฐาน

  • ทฤษฎีบทพื้นฐานของวิศวกรรมซอฟต์แวร์สรุปได้ว่า “ปัญหาใด ๆ ในวิทยาการคอมพิวเตอร์สามารถแก้ได้ด้วยชั้นของการอ้อมอีกชั้นหนึ่ง แต่ปัญหาการมีชั้นอ้อมมากเกินไปเป็นข้อยกเว้น”
  • การพัฒนาซอฟต์แวร์สมัยใหม่มีความซับซ้อนมากจากหลายชั้นและหลายองค์ประกอบ
    • รันไทม์และแพลตฟอร์ม: เบราว์เซอร์ เซิร์ฟเวอร์ คลาวด์ โมบาย เดสก์ท็อป เอ็มเบดเด็ด
    • เครือข่าย: HTTP, DNS, TLS, TCP, UDP, IP, WebSockets, WebRTC, รวมถึงโปรโตคอลของฐานข้อมูลและ message broker
    • ความปลอดภัย การยืนยันตัวตน และการกำหนดสิทธิ์
    • ระบบปฏิบัติการ
    • เวอร์ชวลไลเซชัน คอนเทนเนอร์ไรเซชัน และการ orchestration ตระกูล Kubernetes
    • ฐานข้อมูล: SQL, NoSQL, แบบโลคัล แบบรีโมต และแบบกระจาย
    • ภาษาโปรแกรมระดับสูงและไปป์ไลน์ของคอมไพเลอร์ อินเทอร์พรีเตอร์ และทรานส์ไพเลอร์
    • ไลบรารี เฟรมเวิร์ก และแพ็กเกจเมเนเจอร์
    • API และบริการภายนอก
    • CI/CD, TDD, BDD, GitOps, IaC, DDD, EDA, Event Sourcing, CQRS, SSR, CSR, Clean Architecture, Hexagonal Architecture, Modular Monolith, Microservices, Microfrontends
    • LLM และ AI
  • ก็ยังมีเหตุผลที่เราจะรับมือกับความซับซ้อนนี้ได้
    • หลายระบบถูกออกแบบเกินความจำเป็น และสามารถทำให้เรียบง่ายลงได้มาก
    • ในช่วงเวลาหนึ่ง โดยทั่วไปเราจำเป็นต้องเชี่ยวชาญจริง ๆ เพียงส่วนเล็ก ๆ ของภูมิทัศน์การพัฒนาซอฟต์แวร์ทั้งหมด
    • ที่เหลือแค่รู้ในระดับรับรู้ก็อาจเพียงพอ
    • หากเข้าใจแพตเทิร์นและหลักการทั่วไปที่อยู่หลังเครื่องมือ ก็จะเป็นคานงัดในการเรียนรู้เครื่องมือ แนวทาง และเทคโนโลยีใหม่ ๆ

ขอบเขตและผลของหลักการพื้นฐาน

  • หลักการพื้นฐาน คือกฎ ข้อจำกัด และกลไกพื้นฐานที่เปลี่ยนแปลงไม่มาก ซึ่งอยู่ใต้เครื่องมือ ไลบรารี เฟรมเวิร์ก โปรโตคอล และองค์ประกอบที่ใช้ในการพัฒนาซอฟต์แวร์
  • ขอบเขตหลักครอบคลุมหลายด้าน
    • สถาปัตยกรรมคอมพิวเตอร์และฮาร์ดแวร์: โครงสร้าง CPU การประมวลผลคำสั่ง ลำดับชั้นหน่วยความจำ รีจิสเตอร์ แคช อุปกรณ์จัดเก็บข้อมูล
    • ภาษาเครื่อง แอสเซมบลี และภาษาระดับสูง: เหตุผลที่ต้องมีแอสเซมเบลอร์ คอมไพเลอร์ และอินเทอร์พรีเตอร์ รวมถึง trade-off ของแต่ละประเภทภาษา
    • ระบบปฏิบัติการ: โปรเซส เธรด การจัดตาราง ล็อก การซิงโครไนซ์ หน่วยความจำเสมือน ระบบไฟล์ IPC system call และ I/O
    • อัลกอริทึม โครงสร้างข้อมูล และการวิเคราะห์ความซับซ้อน
    • เครือข่าย: การสื่อสารระหว่างคอมพิวเตอร์ ความน่าเชื่อถือ throughput latency และโครงสร้างแบบลำดับชั้น
    • ฐานข้อมูลและระบบข้อมูล: ACID, ทรานแซกชัน ระดับการแยก อินเด็กซ์ วิธีจัดเก็บ ความสัมพันธ์ และการออกแบบโมเดลข้อมูล
    • การออกแบบซอฟต์แวร์และสถาปัตยกรรม: ความเป็นโมดูล การจัดการ dependency และความรับผิดชอบ การซ่อนข้อมูล การห่อหุ้ม ลำดับชั้น client-server อีเวนต์ coupling และ cohesion
    • สถานะและการไหลของข้อมูล: อัตลักษณ์ single source of truth การแก้ความขัดแย้ง แคชและ memoization การทำให้สถานะเป็นโมฆะ state machine ความสอดคล้อง และการซิงโครไนซ์
    • ระบบกระจาย: CAP theorem การทำสำเนา latency partition consensus service discovery และ eventual consistency
    • ภาวะพร้อมกันและการประมวลผลขนาน: ล็อก การซิงโครไนซ์ ความสามารถในการทำงานขนาน race condition และ deadlock
  • เราไม่จำเป็นต้องเชี่ยวชาญทุกด้าน และอาจเป็นไปไม่ได้ด้วย แต่ควรตั้งเป้าให้รู้แต่ละด้านไว้บ้าง และโดดเด่นจริงในบางด้านที่เลือก
  • เมื่อโฟกัสที่หลักการพื้นฐาน เมื่อเวลาผ่านไปจะเกิดเมตาสกิลที่เรียกว่า สัญชาตญาณสากล
  • หากเข้าใจอย่างลึกซึ้งว่าการประมวลผลและคอมพิวเตอร์ทำงานอย่างไร ทั้งแบบเดี่ยวและแบบคลัสเตอร์ เราจะถูกแกว่งไปตามรายละเอียดของเครื่องมือและเฟรมเวิร์กที่เปลี่ยนอยู่ตลอดน้อยลง
  • เมื่อไปถึงระดับนี้ การเรียนรู้เครื่องมือใหม่ที่กำลังเป็นกระแสก็จะง่ายขึ้นมาก

ความสุขและอิทธิพลของความเข้าใจ

  • ดังคำพูดของ Leonardo da Vinci ที่ว่า “ความสุขอันสูงส่งที่สุดคือความสุขจากความเข้าใจ”
  • ในการพัฒนาซอฟต์แวร์ ความเข้าใจไม่ได้ให้แค่ความสุข แต่ยังให้พลังและอิทธิพลในทางปฏิบัติ
  • ขอบเขตของวิศวกรรมซอฟต์แวร์นั้นกว้างมาก แต่หากโฟกัสที่ หลักการพื้นฐาน พื้นที่ที่เราจัดการได้ก็จะกว้างขึ้น
  • ท่าทีที่ผลักดันขีดจำกัดทางการรับรู้ของตนเองอยู่เสมอ จะนำไปสู่ความสุขอย่างสม่ำเสมอและการขยายอิทธิพลของตนเอง

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 4 시간 전
ความคิดเห็นจาก Lobste.rs

  • ชอบบรรยากาศโดยรวมของบทความบล็อกนี้มาก
    ช่วงนี้เห็นโพสต์แนว "สร้างเครื่องมือขึ้นมาแล้วทั้งที่ยังไม่รู้ด้วยซ้ำว่าข้างในเกิดอะไรขึ้น" บ่อยเกินไปจนเริ่มเหนื่อยกับบรรยากาศที่เหมือนมองว่านั่นเป็นเรื่องน่าภูมิใจ

    • เห็นด้วย ความเข้าใจอย่างลึกซึ้ง ต่างหากที่สร้างความได้เปรียบจริง ๆ และนำไปสู่ไอเดียกับอินไซต์ใหม่ ๆ
      แถมตัวกระบวนการนั้นเองก็สนุกมากด้วย

  • เป็นบทความที่น่าสนใจ และคิดว่ากระแสที่ผลักดันให้ผู้คนสร้าง ผลลัพธ์ที่ตัวเองไม่เข้าใจ นั้นมีความจงใจอยู่พอสมควร
    จากมุมของ AI lab ก็มีเหตุผลทางเศรษฐกิจชัดเจน ผู้คนต้องพึ่งพาผลิตภัณฑ์ของพวกเขา จึงจะเริ่มทำให้ valuation ดูสมเหตุสมผลได้ และการลดทอนความสามารถของผู้ใช้ก็เป็นวิธีหนึ่ง
    บังเอิญวันนี้ผมก็เขียนเรื่องคล้าย ๆ กัน โดยมีสมมติฐานแกนกลางเดียวกันเรื่องความสุขของการได้เรียนรู้และเชี่ยวชาญอะไรบางอย่างจริง ๆ: https://hgrsd.nl/blog/simplicity-agency-and-mastery/

    • ขอบคุณที่แชร์บทความ ประเด็นเรื่อง ความเป็นเจ้าของการตัดสินใจ และ snowball effect ดีมากเป็นพิเศษ
      เราไม่ควรยอมทิ้งความเป็นเจ้าของการตัดสินใจเด็ดขาด และยิ่งรู้มากขึ้น ทำได้มากขึ้น ก็ยิ่งทำให้รู้และทำได้มากขึ้นไปอีก เกิดเป็นวงจรเชิงบวกที่สวยงามจริง ๆ

  • ดีใจที่บทความนี้ไม่ได้ติดแท็ก vibecoding แบบน่าหวาดเสียว จริง ๆ แล้วประเด็นแบบนี้ถูกพูดกันมาหลายสิบปีแล้ว เพียงแค่ในเวอร์ชันที่สั้นกว่าและมักบ่นมากกว่า
    ซอฟต์แวร์มีความซับซ้อนอย่างน่ากลัวจนมี ทางลัดทางความคิด มากมาย และในบางจุดมันก็จำเป็นต่อการเอาตัวรอด แต่คนเรามีแนวโน้มจะขี้เกียจมากเกินไปในเวลาที่ควรระวังให้มากขึ้น คอมพิวเตอร์เข้ากับการแบ่งโมดูลอย่างเข้มงวดได้ดี แต่คนไม่เป็นแบบนั้น
    ชอบที่บทความนี้เน้นว่าความเข้าใจไม่ใช่แค่ “หน้าที่” แต่เป็นเรื่องของการเข้าใจว่าอะไรทำงานอย่างไรนั้น สนุก แค่ไหน อาจมีคนที่ไม่ได้สนุกกับการทำความเข้าใจโลก แต่สำหรับนิสัยของผมมันเป็นแกนสำคัญเกินกว่าจะรู้สึกได้แบบอื่น ถ้าไม่มีความสุขแบบนั้น ก็ควรคิดใหม่ก่อนเริ่มอาชีพด้านซอฟต์แวร์

    • ผมเห็นแท็ก vibecoding อยู่ในบทความนี้นะ
      ช่วงนี้แทบจะเป็นระดับที่เกือบทุกบทความติดแท็ก vibecoding กันหมดแล้ว บางทีน่าจะกลับแนวคิดแล้วทำแท็ก non-vibecoding แทนจะดีกว่า ใช้แท็กนั้นเฉพาะกับบทความที่ไม่ใช่ vibe coding หรือบทความว่าด้วยข้อดีของ vibe coding แล้วปล่อยที่เหลือไว้ตามเดิม น่าเสียดายแต่มันดูเหมือนจะกลายเป็นมาตรฐานใหม่ไปแล้ว
      เป็นบทความที่ "เข้ากับ vibe" ทางอารมณ์ของผมเหมือนกัน

  • ผมชอบการเรียนรู้มากจริง ๆ และบทความพูดถึงสถานการณ์ที่ "เราสร้างบางอย่างขึ้นมาทั้งที่เข้าใจเพียงบางส่วน แล้วต้องใช้เวลาเพิ่มเพื่อทำความเข้าใจมัน" ซึ่งโดยส่วนตัวแล้วผมไม่ได้เกลียด หนี้ทางความคิด แบบนั้น
    ถ้าเป็นโดเมนปัญหาที่ผมสนใจ ผมก็ยินดีใช้เวลาจ่ายหนี้นั้นเพื่อแลกกับความเข้าใจ สุดท้ายมันให้ความรู้สึกเหมือนเป็นอีกเส้นทางหนึ่งไปสู่ความเข้าใจแบบเดียวกัน
    มันทำให้นึกถึงแนวคิด Lean Startup ด้วย ถ้ามีอะไรบางอย่างที่มองเห็นได้ เราก็เริ่มจากการชำแหละสิ่งที่เป็นรูปธรรมได้ แทนที่จะเดาเอาจากหน้าจอว่าง ๆ ว่าอะไรสำคัญ การไม่รู้ด้วยซ้ำว่าควรเริ่มตรงไหนแย่กว่า และ AI ก็ช่วยให้ติดเครื่องได้เร็ว
    ส่วนที่ผมยังจัดความคิดไม่ค่อยลงตัวคือ รุ่นน้องที่ประสบการณ์น้อยจะพัฒนาสัญชาตญาณในการจับกลิ่นไม่ดีและโต้แย้งมันได้อย่างไร วิธีใช้ AI ของผมเป็นแบบวนซ้ำมาก และผมปฏิบัติกับมันเหมือน การถามตอบแบบโสเครตีส เพื่อให้ดีขึ้น ซึ่งต่างจากโลกของ one-shot vibe coding ที่เป็นไปได้ด้วยเครื่องมือปัจจุบันมาก

    • เรื่อง "รุ่นน้องที่ประสบการณ์น้อยจะพัฒนาสัญชาตญาณในการจับกลิ่นไม่ดีและโต้แย้งมันได้อย่างไร" ผมมีเพื่อนสนิทและคนในครอบครัวที่เพิ่งเข้าวงการเมื่อปลายปีที่แล้ว
      ตามความเป็นจริง ผมว่ามันไม่ได้ต่างจากเมื่อก่อนมากนัก คนที่อาวุโสกว่าจะให้คำแนะนำและช่วยโต้แย้งให้ และบริษัทเทคส่วนใหญ่ก็มี peer review อยู่แล้ว ดังนั้นรุ่นน้องไม่ได้ถูกทิ้งให้อยู่คนเดียวทั้งหมด ตรงกันข้าม พวกเขายังมีเวลาพอจะทำผิดพลาดและปรับตัวได้

  • ชอบที่บทความไล่เรียง หัวข้อพื้นฐาน มาค่อนข้างมาก
    ผู้อ่านอาจนึกว่านี่เป็นกลวิธีเชิงวาทศิลป์อย่าง Gish gallop หรือ parading of horribles แต่ที่จริงแล้วผมคิดว่าในทุกช่วงขณะของชีวิตเรา มีทฤษฎีพื้นฐานหลายสิบชุดที่ตัดกันอยู่เสมอ
    คอมพิวเตอร์เองก็ไม่ได้ถูกโปรแกรมขึ้นจากทฤษฎีเอกภาพเพียงหนึ่งเดียว แต่ใกล้เคียงกับ overlapping set-inclusion diagram ที่เอาทฤษฎีเล็ก ๆ จำนวนมากมาต่อกันมากกว่า

  • ผมอ่านบทความนี้อย่างเพลิดเพลินและตั้งใจมาก และยังแชร์ให้เพื่อนบางคนด้วย
    ยิ่งทุกวันนี้การชะลอความเร็วทำได้ยากขึ้นเรื่อย ๆ ผมเลยเขียน https://writing.tidefield.dev/hello-world-again/#honing-my-focus ด้วย โดยตั้งใจจะอุทิศตัวต่อ การเรียนรู้พื้นฐาน อย่างเปิดเผยในปีใหม่
    ดีใจที่มีทิศทางเดียวกันกับประโยคที่ว่า "หลังปี 2026 ไปแล้ว ผมจะศึกษาสิ่งพื้นฐานที่ไม่ใช่กระแสมาเร็วไปเร็ว..."