อินไซต์สำคัญจากหนังสือเทคนิค 45 เล่ม

baeba · 2026-07-23T10:43:23+09:00

สารบัญ ฉลองครบรอบ 2 ปี Book Overflow: อินไซต์สำคัญจากหนังสือเทคนิค 45 เล่ม แนะนำพอดแคสต์และย้อนมองครบรอบ 2 ปี อินไซต์สำคัญจากหนังสือเทคนิคแต่ละเล่ม บทความนี้แบ่งปันอินไซต์สำคัญที่ได้จากการอ่านหนังสือเทคนิค 45 เล่มตลอด 2 ปีที่ผ่านมา และทบทวนผลกระทบที่มีต่อการก่อร่างวิธีคิดในฐานะวิศวกรซอฟต์แวร์ โดยเฉพาะความเข้าใจเชิงลึกเกี่ยวกับยุค AI และกระบวนการพัฒนาที่มีประสิทธิภาพ แนะนำพอดแคสต์และย้อนมองครบรอบ 2 ปี แนะนำ Book Overflow เป็นพอดแคสต์หนังสือเทคนิคสำหรับวิศวกรซอฟต์แวร์ โดยมีเป้าหมายเพื่อพัฒนาทักษะผ่านการอ่านหนังสือเทคนิคชั้นยอดทุกสัปดาห์ การวางแผนตอนพิเศษฉลองครบรอบ 2 ปี เนื่องในโอกาสครบรอบ 2 ปีของพอดแคสต์ ผู้จัดได้ย้อนดูหนังสือทุกเล่มที่อ่านมาตลอด 2 ปีที่ผ่านมา และแบ่งปันเพียงหนึ่งอินไซต์จากแต่ละเล่มที่น่าจดจำที่สุดและยังคงมีอิทธิพลมาจนถึงปัจจุบัน ไม่ได้มุ่งแค่การจดจำเนื้อหาในหนังสือเท่านั้น แต่เน้นว่าหนังสือเหล่านั้นส่งผลต่อการก่อร่างวิธีคิดในฐานะวิศวกรซอฟต์แวร์อย่างไร การเปลี่ยนแปลงตลอด 2 ปีที่ผ่านมา คาร์เตอร์และเนธาน ผู้ดำเนินพอดแคสต์ ได้พบกับความเปลี่ยนแปลงครั้งใหญ่ในชีวิตส่วนตัวตลอด 2 ปีที่ผ่านมา เนธานย้ายไปอยู่ต่างประเทศ ทั้งคู่เรียนจบระดับบัณฑิตศึกษา และเนธานก็กำลังรอลูกที่จะเกิดในเร็ว ๆ นี้ ในด้านอาชีพก็มีความเปลี่ยนแปลงเช่นกัน เนธานเปลี่ยนไปทำคอนซัลติ้งแบบเต็มเวลา ส่วนคาร์เตอร์ย้ายงานจากบิ๊กเทคไปสตาร์ตอัป แม้จะมีความเปลี่ยนแปลงส่วนตัวเหล่านี้ แต่การที่พอดแคสต์ยังดำเนินต่อมาได้ก็เป็นเพราะแรงสนับสนุนและความสนใจจากผู้ฟัง และพวกเขาได้แสดงความขอบคุณต่อสิ่งนั้น อินไซต์สำคัญจากหนังสือเทคนิคแต่ละเล่ม The Practice of Programming (Brian Kernighan, Rob Pike) อินไซต์สำคัญ: หนังสือเล่มนี้บรรจุปรัชญาการเขียนโปรแกรมที่เป็นรากฐานของภาษา Go แม้บางส่วนจะล้าสมัยไปแล้ว แต่แนวคิดแกนกลางยังคงใช้ได้อยู่เสมอ ในฐานะโปรแกรมเมอร์ Go ผู้พูดยังคงจดจำหนังสือเล่มนี้เพราะเป็นแฟนของ Rob Pike และมองว่าแนวคิดหลักของการเขียนโปรแกรมที่ดีมาจากหนังสือเล่มนี้ มีการกล่าวด้วยว่าเนื้อหาบางส่วน เช่น CSV parser นั้นล้าสมัยแล้ว A Philosophy of Software Design (John Ousterhout) อินไซต์สำคัญ: แนวคิด "Design It Twice" เน้นว่าการออกแบบที่ดีกว่าเกิดขึ้นได้จากการเรียนรู้และปรับปรุงระหว่างลงมือสร้างระบบ แทนที่จะพยายามออกแบบให้สมบูรณ์แบบตั้งแต่แรก ในยุค AI การใช้ LLM ช่วยลดความพยายามที่ต้องใช้ในการออกแบบสองรอบ ทำให้การออกแบบมีประสิทธิภาพมากขึ้น แม้หนังสือเล่มนี้จะตีพิมพ์ในปี 2018 แต่ก็ยังคงมีอิทธิพลสูงและถูกอ้างอิงในหนังสือหลายเล่ม ข้อสังเกตเพิ่มเติม หนังสือเสนอแนวคิดที่ทรงพลังเกี่ยวกับการ encapsulate ความซับซ้อน การออกแบบอินเทอร์เฟซ และการจัดการข้อผิดพลาด จากการสัมภาษณ์กับ John Osterhout ยังทำให้ได้รับฟังมุมมองและคำวิจารณ์ของเขาต่อ TDD Refactoring: Improving the Design of Existing Code (Martin Fowler) อินไซต์สำคัญ: การรีแฟกเตอร์สามารถหยุดเมื่อไรก็ได้ เพราะเป็นงานปรับปรุงการออกแบบโดยไม่เปลี่ยนผลลัพธ์ของโค้ด จึงสามารถทำอย่างต่อเนื่องทีละเล็กทีละน้อยได้ หลายคนมักเข้าใจผิดว่าการรีแฟกเตอร์คือการเขียนโค้ดใหม่ทั้งชุด แต่คำจำกัดความของ Fowler จำกัดขอบเขตไว้แคบมาก กรณีการนำไปใช้จริง ไม่นานมานี้ มีการนำรีแฟกเตอร์ที่แท้จริงมาใช้ระหว่างปรับปรุงการใช้ Next.js และ React เพื่อเพิ่มประสิทธิภาพของ roborobato.com มีการปรับโครงสร้างโค้ดใหม่โดยไม่เปลี่ยนฟีเจอร์หรือ UI และแบ่งออกเป็น 5 คอมมิตเพื่อให้ตรวจทานและนำไปใช้ได้ง่าย What Is ChatGPT Doing and Why Does It Work? (Stephen Wolfram) อินไซต์สำคัญ: หนังสือช่วยให้เข้าใจวิธีการทำงานของ LLM โดยเฉพาะกลไกการทำนายโทเค็นถัดไป และแนวคิดเรื่อง temperature อธิบายว่าความสุ่มที่มีอยู่ภายใน LLM นั้นเองคือสิ่งที่ทำให้มันทรงพลัง คุณค่าของหนังสือ ให้บทวิเคราะห์ที่เรียบเรียงอย่างดีซึ่งอธิบายหัวข้อซับซ้อนให้เข้าใจได้ง่าย มอบคำศัพท์พื้นฐานและกรอบความคิดสำหรับทำความเข้าใจ LLM ซึ่งยังคงเป็นความรู้สำคัญอยู่เสมอ Fundamentals of Software Architecture (Mark Richards, Neal Ford) อินไซต์สำคัญ: หนังสือเน้นความสำคัญของความสามารถในการขายวิสัยทัศน์ด้านสถาปัตยกรรมให้กับผู้มีส่วนได้ส่วนเสียทั้งสายเทคนิคและไม่ใช่เทคนิค และถือว่านี่คือองค์ประกอบพื้นฐานของสถาปัตยกรรม ต้องสื่อสารอย่างต่อเนื่องและพิสูจน์คุณค่าของตัวเองอยู่เสมอ ท่าทีแบบ "ต้องเป็นไปตามที่ฉันพูด" ไม่ใช่สิ่งที่พึงปรารถนา หลักการเพิ่มเติม ไม่ควรอยู่บนหอคอยงาช้าง แต่ต้องทำงานร่วมกับโค้ดและทีม สัมผัสการออกแบบด้วยตัวเอง และก้าวนำไปสองสามขั้นเพื่อคาดการณ์ปัญหาที่อาจเกิดขึ้น หนังสือเน้นบทบาทของ ADR (Architectural Design Document) และกล่าวว่าการบันทึกและพัฒนากระบวนการตัดสินใจเป็นสิ่งสำคัญ การบันทึกและแบ่งปันการตัดสินใจเป็นสิ่งจำเป็นเพื่อหลีกเลี่ยง "ปรากฏการณ์ Groundhog Day" The Clean Coder (Robert C. Martin, "Uncle Bob") อินไซต์สำคัญ: หนังสือสำรวจว่าความเป็นมืออาชีพที่แท้จริงคืออะไร โดยเฉพาะมุมมองอันสุดโต่งของ Uncle Bob ต่อเดดไลน์และการประเมินเวลา ในวัฒนธรรมวิศวกรรม มักมีความสับสนระหว่างการประเมินกับเดดไลน์ แต่หากต้องการความเป็นมืออาชีพ ก็จำเป็นต้องแยกสองสิ่งนี้ออกจากกันอย่างชัดเจน ลักษณะเด่นของหนังสือ เต็มไปด้วยเรื่องเล่า และช่วยให้รู้จักตัวตนของ Uncle Bob ได้ลึกขึ้น หนังสือเขียนได้ดี อ่านง่าย และเหมาะกับการอ่านตั้งแต่ต้นจนจบ Working Effectively with Legacy Code (Michael Feathers) อินไซต์สำคัญ: โค้ดที่แก้ไขยากหรือทำให้รู้สึกกลัวนั้นเป็นโค้ดที่ออกแบบไม่ดี และเราสามารถทำให้ใครก็ตามแก้ไขโค้ดได้ง่ายขึ้น หนังสือให้นิยาม legacy code ว่าเป็นโค้ดที่ไม่มี test coverage หรือเป็นโค้ดที่เราไม่เข้าใจวิธีการทำงาน ให้แนวทางว่าจะเริ่มต้นอย่างไรเมื่อไม่ได้อยู่ในโปรเจกต์ greenfield หรือมีอำนาจควบคุม codebase ไม่มากพอ คุณค่าของหนังสือ แต่ละส่วนเป็นอิสระต่อกัน จึงเหมาะสำหรับใช้อ้างอิง และมีประสิทธิภาพกว่าหากเปิดอ่านเฉพาะส่วนที่ต้องการ แทนการอ่านรวดเดียวตั้งแต่ต้นจนจบ Web Scalability for Startup Engineers (Artur Ejsmont) อินไซต์สำคัญ: ในช่วงเริ่มต้นของสตาร์ตอัป สิ่งสำคัญคือการเดินหน้าให้เร็ว มากกว่าการทำ optimization มากเกินไปหรือไล่ตามความพร้อมใช้งานระดับสูง และควรลงทุนในจังหวะที่เหมาะสม สตาร์ตอัประยะแรกไม่ควรพยายามสร้าง fault tolerance หรือ high availability ที่สมบูรณ์แบบตั้งแต่ตอนที่ยังมีลูกค้าไม่มาก ข้อจำกัดตามยุคสมัยและข้อเสนอแนะ สิ่งที่หนังสือกล่าวถึงคือประเด็นสำคัญของยุค 2010s ซึ่งปัจจุบันบริษัท SaaS และ PaaS จำนวนมากเข้ามาช่วยแก้ปัญหาส่วนนี้แล้ว เวอร์ชันใหม่ควรถูกอัปเดตให้เป็นแฮนด์บุ๊กสำหรับผู้ก่อตั้งครั้งแรกหรือผู้นำทางเทคนิค Recoding America (Jennifer Pahlka) อินไซต์สำคัญ: หนังสือแสดงให้เห็นถึงความไร้ประสิทธิภาพของซอฟต์แวร์ภาครัฐและความเป็นไปได้ในการปรับปรุง พร้อมชี้ว่าซอฟต์แวร์ภาครัฐก็สามารถสร้างให้มีคุณภาพดีได้มากพอ ซอฟต์แวร์ภาครัฐมักถูกประเมินจากการทำเช็กลิสต์ให้ครบ มากกว่าการพิจารณาว่ามันทำงานได้จริงหรือไม่ หนังสือเน้นความสำคัญของการนำหลักการแกนกลางของ Agile อย่าง "การทำงานร่วมกับลูกค้าอย่างใกล้ชิด" และ "การส่งมอบซอฟต์แวร์ที่ใช้งานได้อย่างต่อเนื่อง" ไปใช้กับการพัฒนาซอฟต์แวร์ภาครัฐ Building Evolutionary Architectures (Neal Ford, Rebecca Parsons, Patrick K. Kua, Pramod Sadalage) อินไซต์สำคัญ: หนังสือเสนอแนวคิด "Fitness Functions" เพื่อประเมินอย่างเป็นกลางว่าระบบทำงานได้ตามที่คาดหวังหรือไม่ และแสดงวิธีสร้างสถาปัตยกรรมที่พัฒนาเปลี่ยนแปลงได้ Fitness Functions เป็นสิ่งจำเป็นต่อการติดตามวิวัฒนาการของระบบ และตรวจสอบว่าการตัดสินใจด้านการออกแบบทำงานตามเจตนาหรือไม่ ต้องคำนึงถึงผลกระทบของโครงสร้างองค์กรที่มีต่อสถาปัตยกรรมซอฟต์แวร์ เช่น กฎของ Conway เมื่อจัดทีมและออกแบบระบบ Looks Good to Me (Adrian Bergeron) อินไซต์สำคัญ: แม้จะจำคำแนะนำเฉพาะเจาะจงในหนังสือไม่ได้ แต่หนังสือก็ช่วยย้ำเตือนอีกครั้งถึงความสำคัญของ pull request (PR) จากกระบวนการย้ายระบบที่เพิ่งทำในบริษัทเมื่อไม่นานมานี้ ทำให้ได้ทบทวนว่าการรีวิว PR ไม่รัดกุมพอ และรู้สึกว่าจำเป็นต้องกลับมาอ่านหนังสือเล่มนี้อีกครั้ง คุณค่าของหนังสือ ให้แนวทางที่ดีเกี่ยวกับการกำหนดข้อตกลงทางสังคมและมาตรฐานภายในทีม หนังสือเทคนิคมีประโยชน์สำหรับการกลับมาเปิดอ่านอีกครั้งเมื่อจำเป็น และช่วยต่อยอดไอเดียได้ Slow Productivity (Cal Newport) อินไซต์สำคัญ: ข้อความที่ว่า "ทำงานให้น้อยลงและโฟกัสกับงานที่มีความหมาย" เน้นให้ระวัง pseudo-productivity และควรมุ่งไปที่กิจกรรมที่มีมูลค่าสูง เป็นหนังสือที่แสดงให้เห็นวิธีคิดอันลุ่มลึกของ Cal Newport และช่วยลดกิจกรรมที่ไม่จำเป็นเพื่อไปโฟกัสกับงานสำคัญ เช่น การทำพอดแคสต์ ยิ่งอาชีพก้าวหน้ามากขึ้น ก็ยิ่งต้องโฟกัสกับงานที่มี leverage และมูลค่าสูงที่สุด และ pseudo-productivity คือสิ่งที่ขัดขวางเรื่องนั้น The Unicorn Project (Gene Kim) อินไซต์สำคัญ: อธิบายความสำคัญของกระบวนการ DevOps จากมุมมองของวิศวกรรมซอฟต์แวร์ และเน้นว่าต้องแก้ปัญหาที่รากเพื่อเร่งความเร็วในการพัฒนา ระบบที่ต้องพึ่งพา release manager นั้นไม่มีประสิทธิภาพ และควรมีโปรเซสอัตโนมัติที่ทำให้ใครก็จัดการ release ได้ โครงสร้างและอิทธิพลของหนังสือ ต่างจากงานก่อนหน้าอย่าง 'The Phoenix Project' ตรงที่อธิบาย DevOps จากมุมมองวิศวกรรมซอฟต์แวร์ จึงนำไปใช้กับนักพัฒนาได้กว้างกว่า ใช้รูปแบบอุปมาเพื่อถ่ายทอดเนื้อหาเชิงเทคนิคให้เข้าใจง่าย และเป็นผู้นำเทรนด์การผสานเรื่องเล่าเข้ากับหนังสือเทคนิค Tidy First (Kent Beck) อินไซต์สำคัญ: เน้นคุณค่าของ "optionality" ในโครงสร้างโค้ด หรือก็คือความยืดหยุ่นและความสามารถในการขยาย ซึ่งสร้างผลประโยชน์ที่เป็นไปได้ในอนาคตคล้ายกับมูลค่าของเวลา เพราะตอนเขียนโค้ดครั้งแรกยากจะคาดเดาได้ว่าฟีเจอร์ใดจะจำเป็นในอนาคต จึงสำคัญที่จะเขียนให้เปลี่ยนแปลงได้อย่างยืดหยุ่น ลักษณะเด่นและคุณค่าของหนังสือ แม้จะเป็นหนังสือสั้นและกระชับ แต่ให้มุมมองที่ลึกซึ้ง และทำให้รู้สึกถึงความสนุกของการพัฒนาซอฟต์แวร์ การนำไอเดียจากอุตสาหกรรมอื่น เช่น การเทรดออปชัน มาประยุกต์ใช้กับซอฟต์แวร์ เป็นสัญญาณของการพัฒนาที่เป็นผู้ใหญ่ Unix: A History and a Memoir อินไซต์สำคัญ: ทำให้เข้าใจวิธีการทำงานและความสำคัญของ "pipes" ซึ่งเป็นหนึ่งใน building block หลักของ Unix ด้วยปรัชญาแบบ Unix ที่ให้แต่ละโปรแกรมรับอินพุตแล้วส่งคืนเอาต์พุต จึงสามารถเชื่อมเอาต์พุตระหว่างโปรแกรมได้ง่ายผ่านตัวดำเนินการ pipe บทบาทของ Doug McIlroy Doug McIlroy มีบทบาทสำคัญในการหลอมรวมแนวคิดของ Unix ผ่าน pipe และมีส่วนช่วยกำหนดปรัชญาแบบ Unix The Twelve-Factor App อินไซต์สำคัญ: นำเสนอหลักการ 12 ข้อสำหรับการสร้างแอปพลิเคชันแบบ cloud-native แต่หากนำหลักการเหล่านี้ไปใช้อย่างผิดวิธีก็อาจเพิ่มความซับซ้อนได้แทน เป็นหลักการที่ถูกสร้างขึ้นในยุค Heroku และเมื่อดูหลักพื้นฐานแล้วก็เป็นสิ่งที่ชวนพยักหน้าเห็นด้วย เช่นเดียวกับกรณีที่นำเทคโนโลยีบางอย่างอย่าง Kubernetes ไปใช้โดยไม่เข้าใจ หลักการเหล่านี้ก็สามารถถูกใช้อย่างผิดทางได้เช่นกัน The Agile Manifesto อินไซต์สำคัญ: Agile เป็นปฏิกิริยาตอบโต้ต่อโมเดล waterfall โดยมีเป้าหมายเพื่อส่งมอบซอฟต์แวร์ที่ใช้งานได้อย่างรวดเร็ว และสะท้อน feedback จากลูกค้าให้ไว แก่นของ Agile คือการทำงานร่วมกับลูกค้าและผู้มีส่วนได้ส่วนเสียอย่างใกล้ชิด เพื่อปรับปรุงซอฟต์แวร์แบบ iterative การประยุกต์ใช้สมัยใหม่และคำวิจารณ์ แม้สาระสำคัญของ Agile จะคุ้นเคยสำหรับนักพัฒนาจำนวนมาก แต่หากไม่มีความพยายามอย่างตั้งใจ ก็อาจสูญเสียความหมายไปได้ง่าย เพราะมันฝังรากลึกในงานพัฒนาซอฟต์แวร์ยุคใหม่ จึงทำให้เป็นการหันกลับมาทบทวนวิธีเดิมมากกว่าการเรียนรู้สิ่งใหม่ มันมีประสิทธิภาพมากในฐานะแรงต้านต่อโมเดล waterfall และย้ำว่าด้วยความซับซ้อนของซอฟต์แวร์ การส่งมอบสิ่งที่มีคุณค่าเป็นหน่วยเล็ก ๆ สำคัญกว่าการวางแผนระยะยาว The Software Engineer's Guidebook (Jorge Orozco) อินไซต์สำคัญ: เมื่ออาชีพเติบโตขึ้น ควรโฟกัสกับงานที่มี leverage สูง และต้องบริหารเส้นทางอาชีพของตนเองอย่างเชิงรุก เน้นความสำคัญของผู้จัดการและสปอนเซอร์ โดยผู้จัดการจะสนับสนุนคุณเพื่อการเลื่อนตำแหน่ง และคุณเองก็ต้องพยายามตอบให้ได้ตามความคาดหวังนั้น ลักษณะเด่นของหนังสือ คล้ายกับจดหมายข่าว 'The Pragmatic Engineer' ตรงที่ให้คำแนะนำเชิงปฏิบัติเกี่ยวกับการจัดการอาชีพ ให้เฟรมเวิร์กที่จำเป็นต่อการทำความเข้าใจเส้นทางอาชีพที่ซับซ้อน และการทำให้ผู้อื่นเห็นคุณค่าในตัวเองอย่างเชิงรุก Hypermedia Systems (Carson Gross, et al.) อินไซต์สำคัญ: ด้วยเทคโนโลยีอย่าง HTMX ก็สามารถสร้างเว็บแอปพลิเคชันที่ไดนามิกเพียงพอด้วย server-side rendering ได้ และลดความจำเป็นของ JavaScript client ที่ซับซ้อนลงได้ โดยอาศัยข้อดีของระบบ hypermedia ซึ่งเป็นแนวคิดดั้งเดิมของเว็บ หากมีสเปกที่ดี ก็สามารถทำฟังก์ชันจำนวนมากฝั่งเซิร์ฟเวอร์ได้โดยไม่ขึ้นกับเทคโนโลยี backend ข้อดีและข้อจำกัดของ HTMX โค้ดที่เขียนด้วย HTMX เรียบง่ายและดูแลรักษาง่าย อีกทั้งมีโอกาสอยู่ได้นานกว่าเฟรมเวิร์กสมัยใหม่ HTMX อาจไม่ใช่อนาคตของการพัฒนาเว็บ แต่ความเห็นที่คัดค้านเช่นนี้ก็ช่วยให้ตัดสินใจได้ดีขึ้นในฐานะวิศวกร Team Topologies (Matthew Skelton, Manuel Pais) อินไซต์สำคัญ: ทีมควรถูกจัดให้ลดการพึ่งพากันที่ต้องคอยประสานงานให้เหลือน้อยที่สุด และโครงสร้างของทีมมีผลโดยตรงต่อสถาปัตยกรรมซอฟต์แวร์ Team Topologies มุ่งเน้นการลดการประสานงานระหว่างทีมเพื่อเพิ่มประสิทธิภาพของ flow เนื่องจากโครงสร้างของทีมเป็นตัวกำหนดโครงสร้างของซอฟต์แวร์ จึงต้องระมัดระวังในการออกแบบทีม Ace the System Design Interview (Alex Xu) อินไซต์สำคัญ: ในการสัมภาษณ์ system design การใช้ "back-of-the-napkin math" เพื่อประเมินขนาดและความต้องการด้านประสิทธิภาพเป็นสิ่งสำคัญ หากจำค่าทั่วไปอย่างเวลา ขนาดข้อมูล ฯลฯ และนำมาใช้เพื่อทำให้ข้อกำหนดของระบบเป็นรูปธรรม ก็จะออกแบบบนพื้นฐานของเหตุผล ไม่ใช่การเดา ตัวอย่างเช่น หากต้องรองรับจำนวนทวีตต่อชั่วโมง เมื่อรู้จำนวนไบต์ต่อทวีตและความยาวของทวีต ก็สามารถคำนวณพื้นที่จัดเก็บและ throughput ที่ต้องใช้ได้ วิธีใช้ในการสัมภาษณ์ หากคิดออกเสียงและแชร์กระบวนการคำนวณกับผู้สัมภาษณ์ ก็จะได้รับ feedback และนำไปสู่การออกแบบที่ดีขึ้นได้ สิ่งสำคัญไม่ใช่แค่การไล่รายชื่อเทคโนโลยีล่าสุด แต่ต้องอธิบายเหตุผลที่เลือกเทคโนโลยีนั้นด้วย The Good News Factory (Kent Beck) อินไซต์สำคัญ: หากทีมซอฟต์แวร์จะเป็น "โรงงานข่าวดี" ที่ส่งมอบ "ข่าวดี" ได้อย่างต่อเนื่อง การมี clean code และการสร้างระบบที่ขยายได้จึงเป็นสิ่งจำเป็น หากทีมไม่สามารถแสดงผลลัพธ์เชิงบวกได้อย่างสม่ำเสมอ ก็อาจเกิดเรื่องเล่าเชิงลบจากภายนอกขึ้นมาแทน ลักษณะเด่นของหนังสือ เป็นหนังสือรูปแบบรายงานที่สั้นและกระชับ ซึ่งถ่ายทอดสารหลักได้อย่างมีประสิทธิภาพ Thinking in Systems (Donella Meadows) อินไซต์สำคัญ: แนวคิดเรื่อง "stocks and flows" ช่วยให้เข้าใจคุณลักษณะเชิงพลวัตของระบบ และมอบเฟรมเวิร์กที่มีประโยชน์ต่อการวิเคราะห์ระบบที่ซับซ้อน เช่นเดียวกับการเข้าใจความแตกต่างระหว่าง GDP (flow) กับมูลค่าตลาด (stock) การแยกแยะสถานะปัจจุบันของระบบกับอัตราการเปลี่ยนแปลงเป็นสิ่งสำคัญ คุณค่าของหนังสือ แม้จะเป็นนามธรรม แต่ก็มอบมุมมองระดับสูงที่ทรงคุณค่าต่อการคิดเชิงกลยุทธ์และการคิดเชิงระบบ Grokking Concurrency (Karol Bobrov) อินไซต์สำคัญ: การ "ปรับขนาดให้เหมาะสม" ของโมเดล concurrency เป็นเรื่องสำคัญ เพราะทั้งการแบ่งละเอียดเกินไปและการทำกว้างเกินไปต่างก็มีข้อเสีย หนังสืออธิบายวิธีทำความเข้าใจหน่วยงานที่สามารถทำแบบขนานหรือแยกเป็นงานพร้อมกันได้ และวิธีจูนระบบตามนั้น Rework (Jason Fried, David Heinemeier Hansson) อินไซต์สำคัญ: เราสามารถใช้ข้อได้เปรียบจากการเป็นผู้เล่นรายเล็กและยังไม่เป็นที่รู้จัก เพื่อเดินหน้าทำซ้ำ สร้างใหม่ และสร้างความสำเร็จได้ ข้อเสียของการยังไม่โด่งดังอาจกลายเป็นโอกาสของนวัตกรรมได้ และควรใช้ประโยชน์จากมันเพื่อไม่ให้พลาดข้อดีของความสำเร็จ ลักษณะเด่นและอิทธิพลของหนังสือ เป็นหนังสือที่เขียนดีและมีเหตุผล ช่วยสร้างแรงบันดาลใจให้กับคนที่ต้องการสร้างสิ่งใหม่ผ่านการ bootstrap หรือสร้างสิ่งที่ไม่สอดคล้องกับนิยามความสำเร็จกระแสหลัก กรณีความสำเร็จของ Basecamp และ 37signals พิสูจน์ว่าปรัชญาของพวกเขายังคงใช้ได้แม้เวลาจะผ่านไป In the Plex (Steven Levy) อินไซต์สำคัญ ความสามารถของวิศวกร Google ในการคิดค้นแนวคิดซับซ้อนอย่างทฤษฎีการประมูลขึ้นมาใหม่อย่างสร้างสรรค์ คือผลลัพธ์ที่ได้เมื่อจ้างคนเก่งและไว้วางใจพวกเขา ความสำเร็จของสตาร์ทอัพไม่ได้การันตีไว้ จึงต้องพยายามอย่างต่อเนื่องและมีส่วนร่วมเพื่ออนาคตของบริษัท ความเชื่อมโยงกับผู้เขียน Steven Levy ผู้เขียนเป็นนักเขียนชั้นยอด และหนังสืออีกเล่มของเขาอย่าง 'Crypto' ก็น่าแนะนำเช่นกัน ประสบการณ์ที่ได้ไปสัมภาษณ์กับบริษัทซึ่งมีบุคคลในหนังสือเป็น CEO อยู่ในปัจจุบันนั้นน่าสนใจมาก Thinking Like a Large Language Model (Mukund Sundararajan) อินไซต์สำคัญ: แม้ความทรงจำเฉพาะเกี่ยวกับหนังสือเล่มนี้จะเลือนราง แต่ก็ช่วยให้เข้าใจวิธีคิดของ LLM ได้ The DevOps Handbook อินไซต์สำคัญ ให้แนวทางด้านการทำ DevOps ในทางปฏิบัติ เช่น CI/CD pipeline, automatic rollback และ observability ที่ดีขึ้น ซึ่งช่วยยกระดับความสามารถด้านซอฟต์แวร์เอ็นจิเนียริงของทีมอย่างมาก เมื่อต้องปล่อยฟีเจอร์ใหม่อย่าง "ฟังก์ชันค้นหาใหม่" หนังสือแนะนำเทคนิค "shadow traffic" ที่ส่งทราฟฟิกจริงบางส่วนไปยัง API ใหม่เพื่อสังเกตผลลัพธ์ เน้นความสำคัญของการแยก deployment ออกจาก release และสามารถใช้ feature flag เพื่อรับมือ regression ที่อาจเกิดขึ้นระหว่างการย้ายระบบได้อย่างรวดเร็ว ผู้เขียนและคุณค่าของหนังสือ มีผู้เขียนชื่อดังอย่าง Gene Kim, Jess Humble, Patrick Dubois, Nicole Forsgren และ John Willis ร่วมเขียน และมีเนื้อหาที่เสริมกับ 'Unicorn Project' และ 'The Phoenix Project' Just for Fun: How Linus Torvalds Started an Accidental Revolution อินไซต์สำคัญ: Linus Torvalds สร้าง Linux ขึ้นมาด้วยการโฟกัสกับสิ่งที่เขาสนุก และสิ่งนั้นก็นำไปสู่ผลลัพธ์ที่เปลี่ยนโลก การโฟกัสกับสิ่งที่สนุกคือแรงจูงใจที่ทำให้เราทำงานหนักที่สุด และอาจนำไปสู่ความสำเร็จครั้งใหญ่แบบไม่คาดคิด นวัตกรรมของซอฟต์แวร์โอเพนซอร์ส Linus Torvalds บุกเบิกแนวทางที่ไม่ดั้งเดิมในการสร้างรายได้จากซอฟต์แวร์โอเพนซอร์สพร้อมยึดมั่นในหลักการของตน ซึ่งส่งผลอย่างมากต่อการดูแลเซิร์ฟเวอร์และวิธีการ commit โค้ด Made to Stick อินไซต์สำคัญ: ไอเดียที่น่าจดจำมีรูปแบบบางอย่างร่วมกัน และแม้จะไม่ใช่อัจฉริยะด้านความคิดสร้างสรรค์ ก็สามารถใช้รูปแบบเหล่านี้เพื่อสื่อสารไอเดียได้อย่างมีประสิทธิภาพ ข้อความที่ว่า "จงโฟกัสกับสิ่งที่สนุก และเชื่อว่าคุณจะทุ่มเทที่สุดกับสิ่งที่สนุกที่สุด" ส่งผลอย่างมากต่อการตัดสินใจด้านอาชีพส่วนตัว Staff Engineer (Will Larson) อินไซต์สำคัญ: ในระดับ Staff Engineer ควรโฟกัสกับงานที่มีลำดับความสำคัญสูงและมีอิมแพกต์มาก ซึ่งเป็นตัวชี้วัดสำคัญที่ใช้ได้ตลอดเส้นทางอาชีพ ไม่มีเส้นทางตายตัวในการเป็น Staff Engineer และผู้คนจากหลากหลายพื้นเพต่างก็แก้ปัญหาที่ซับซ้อนได้ Finite and Infinite Games (James P. Carse) อินไซต์สำคัญ: "เกมจำกัด" มีผลแพ้ชนะชัดเจน แต่ "เกมไม่สิ้นสุด" มีเป้าหมายเพื่อสนุกกับการเล่นเกมนั้นเอง และการมุ่งสู่เกมไม่สิ้นสุดในชีวิตเป็นสิ่งสำคัญ ตอนที่ Linus Torvalds สร้าง Linux เขาไม่ได้เล่นเกมจำกัดแบบการสร้างระบบปฏิบัติการที่ดังที่สุด แต่เล่นเกมไม่สิ้นสุดอย่างการสร้างระบบปฏิบัติการที่ดีที่สุดและสร้างชุมชนขึ้นมา Radical Candor (Kim Scott) อินไซต์สำคัญ: ฟีดแบ็กที่ตรงไปตรงมาและซื่อสัตย์กลับเป็นหนทางที่ใส่ใจอีกฝ่ายจริง ๆ และควรหลีกเลี่ยง "ruinous empathy" การให้ฟีดแบ็กอย่างตรงไปตรงมาเกิดจากความห่วงใยต่อความเป็นอยู่ของอีกฝ่ายอย่างจริงใจ และต่างจากการเสียมารยาท เวลาจะให้ฟีดแบ็กควรคำนึงถึงความรู้สึกของอีกฝ่าย แต่ก็ต้องสื่อสารประเด็นสำคัญให้ชัดเจน Mastering OpenTelemetry and Observability (Steve Flanders) อินไซต์สำคัญ: ควรหลีกเลี่ยง vendor lock-in และใช้ OpenTelemetry แต่ในยุค AI ก็ทำให้กลับมาทบทวนว่าความสำคัญของ vendor lock-in อาจเปลี่ยนไป ความสะดวกของเครื่องมืออย่าง DataDog อาจทำให้ vendor lock-in ดูน่าสนใจ แต่ก็ควรคำนึงถึงความเสี่ยงอย่างการเปลี่ยนราคา หรือการควบรวมกิจการ Beyond Vibe Coding (Addy Osmani) & Advanced React (Nadia Makarevich) อินไซต์สำคัญ 'Beyond Vibe Coding' นำเสนอแนวคิดของ "augmented AI" ที่วิศวกรผู้มีประสิทธิภาพทำงานร่วมกับ coding agent เพื่อเขียนโค้ด 'Advanced React' เหมาะสำหรับใช้เป็นเอกสารอ้างอิง The Tao of Programming (Jeffrey James) อินไซต์สำคัญ: การสร้างระบบปฏิบัติการสำคัญแค่ความถูกต้องทางเทคนิค แต่การจำลองโลกจริงอย่างระบบเงินเดือนนั้นยากกว่า เพราะมีปัญหาซับซ้อนรวมถึงผู้มีส่วนได้ส่วนเสียเข้ามาเกี่ยวข้อง เรื่องนี้อาจไม่ใช่สิ่งที่เป็นธรรมชาติสำหรับโปรแกรมเมอร์ และชี้ให้เห็นว่าการจำลองโลกจริงเป็นซอฟต์แวร์นั้นมีความซับซ้อนโดยเนื้อแท้ ความเชื่อมโยงกับบทความ "Worse Is Better" 'The Tao of Programming' และ "Worse Is Better" เป็นงานเขียนประเภทคล้ายกันที่สั้นแต่ชวนให้คิดลึก Mastering the Behavioral Interview (Austin McDonald) อินไซต์สำคัญ: สามารถเรียนรู้วิธีเล่าประสบการณ์ของตัวเองให้เข้ากับ archetype แบบ "แฮ็กเกอร์ผู้เดียวดาย" ในการสัมภาษณ์สายเทคสไตล์ซิลิคอนแวลลีย์ ทักษะการเล่าเรื่องอย่างมีประสิทธิภาพในการสัมภาษณ์สำคัญมาก และหนังสือเล่มนี้ก็อธิบายวิธีทำไว้อย่างชัดเจน Designing Data-Intensive Applications (Martin Kleppmann) อินไซต์สำคัญ: เจาะลึกแนวคิดพื้นฐานของ distributed systems เช่น reliability, latency เทียบกับ throughput และ resilience เทียบกับการฟื้นตัวอย่างรวดเร็ว ยังครอบคลุมหัวข้ออย่าง data privacy และการฉกฉวยความสนใจ ทำให้ต้องคิดทบทวนมากขึ้นเมื่อต้องสร้างระบบที่มีความต้องการสูง Reflections on Trusting Trust (Ken Thompson) & Coding Machines (Lawrence Kesteloot) อินไซต์สำคัญ: ในยุคที่ AI สร้างโค้ดได้ ประเด็นเรื่องความไว้วางใจต่อโค้ดที่ถูกสร้างขึ้น และเจตนาร้ายที่อาจแฝงอยู่ (เช่น steganography) เป็นสิ่งที่ชวนให้ขบคิดอย่างลึกซึ้ง Frictionless (Nicole Forsgren, Abby Noda) อินไซต์สำคัญ: หนังสือเล่มนี้โฟกัสการทำ initiative ด้าน DevEx โดยมุ่งไปที่ผู้นำในองค์กรขนาดใหญ่เป็นหลัก จึงยังไม่ส่งผลมากนักในช่วงอาชีพปัจจุบัน แม้จะมีเนื้อหาด้าน DevEx ที่ยอดเยี่ยม แต่ก็อาจสำคัญกว่ากับบริษัทที่อยู่หลัง Series C ไปแล้ว Project Hail Mary (Andy Weir) อินไซต์สำคัญ: อนาคตไม่ใช่สิ่งที่ต้องหวาดกลัว แต่เป็นปัญหาที่ต้องแก้ และหนังสือแสดงมุมมองเชิงบวกต่อบทบาทของมนุษยชาติและเทคโนโลยี ถ่ายทอดข้อความที่ให้ความหวังว่า แม้อยู่ในสถานการณ์ยากลำบาก ก็ยังสามารถสร้างสิ่งน่าทึ่งได้ด้วยสมาธิและนวัตกรรม

สารบัญ

ฉลองครบรอบ 2 ปี Book Overflow: อินไซต์สำคัญจากหนังสือเทคนิค 45 เล่ม
- แนะนำพอดแคสต์และย้อนมองครบรอบ 2 ปี
- อินไซต์สำคัญจากหนังสือเทคนิคแต่ละเล่ม

บทความนี้แบ่งปันอินไซต์สำคัญที่ได้จากการอ่านหนังสือเทคนิค 45 เล่มตลอด 2 ปีที่ผ่านมา และทบทวนผลกระทบที่มีต่อการก่อร่างวิธีคิดในฐานะวิศวกรซอฟต์แวร์ โดยเฉพาะความเข้าใจเชิงลึกเกี่ยวกับยุค AI และกระบวนการพัฒนาที่มีประสิทธิภาพ

แนะนำพอดแคสต์และย้อนมองครบรอบ 2 ปี

แนะนำ Book Overflow

เป็นพอดแคสต์หนังสือเทคนิคสำหรับวิศวกรซอฟต์แวร์ โดยมีเป้าหมายเพื่อพัฒนาทักษะผ่านการอ่านหนังสือเทคนิคชั้นยอดทุกสัปดาห์

การวางแผนตอนพิเศษฉลองครบรอบ 2 ปี

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

การเปลี่ยนแปลงตลอด 2 ปีที่ผ่านมา

คาร์เตอร์และเนธาน ผู้ดำเนินพอดแคสต์ ได้พบกับความเปลี่ยนแปลงครั้งใหญ่ในชีวิตส่วนตัวตลอด 2 ปีที่ผ่านมา
- เนธานย้ายไปอยู่ต่างประเทศ ทั้งคู่เรียนจบระดับบัณฑิตศึกษา และเนธานก็กำลังรอลูกที่จะเกิดในเร็ว ๆ นี้
- ในด้านอาชีพก็มีความเปลี่ยนแปลงเช่นกัน เนธานเปลี่ยนไปทำคอนซัลติ้งแบบเต็มเวลา ส่วนคาร์เตอร์ย้ายงานจากบิ๊กเทคไปสตาร์ตอัป
แม้จะมีความเปลี่ยนแปลงส่วนตัวเหล่านี้ แต่การที่พอดแคสต์ยังดำเนินต่อมาได้ก็เป็นเพราะแรงสนับสนุนและความสนใจจากผู้ฟัง และพวกเขาได้แสดงความขอบคุณต่อสิ่งนั้น

อินไซต์สำคัญจากหนังสือเทคนิคแต่ละเล่ม

The Practice of Programming (Brian Kernighan, Rob Pike)

อินไซต์สำคัญ: หนังสือเล่มนี้บรรจุปรัชญาการเขียนโปรแกรมที่เป็นรากฐานของภาษา Go แม้บางส่วนจะล้าสมัยไปแล้ว แต่แนวคิดแกนกลางยังคงใช้ได้อยู่เสมอ
- ในฐานะโปรแกรมเมอร์ Go ผู้พูดยังคงจดจำหนังสือเล่มนี้เพราะเป็นแฟนของ Rob Pike และมองว่าแนวคิดหลักของการเขียนโปรแกรมที่ดีมาจากหนังสือเล่มนี้
- มีการกล่าวด้วยว่าเนื้อหาบางส่วน เช่น CSV parser นั้นล้าสมัยแล้ว

A Philosophy of Software Design (John Ousterhout)

อินไซต์สำคัญ: แนวคิด "Design It Twice" เน้นว่าการออกแบบที่ดีกว่าเกิดขึ้นได้จากการเรียนรู้และปรับปรุงระหว่างลงมือสร้างระบบ แทนที่จะพยายามออกแบบให้สมบูรณ์แบบตั้งแต่แรก
- ในยุค AI การใช้ LLM ช่วยลดความพยายามที่ต้องใช้ในการออกแบบสองรอบ ทำให้การออกแบบมีประสิทธิภาพมากขึ้น
- แม้หนังสือเล่มนี้จะตีพิมพ์ในปี 2018 แต่ก็ยังคงมีอิทธิพลสูงและถูกอ้างอิงในหนังสือหลายเล่ม
ข้อสังเกตเพิ่มเติม
- หนังสือเสนอแนวคิดที่ทรงพลังเกี่ยวกับการ encapsulate ความซับซ้อน การออกแบบอินเทอร์เฟซ และการจัดการข้อผิดพลาด
- จากการสัมภาษณ์กับ John Osterhout ยังทำให้ได้รับฟังมุมมองและคำวิจารณ์ของเขาต่อ TDD

Refactoring: Improving the Design of Existing Code (Martin Fowler)

อินไซต์สำคัญ: การรีแฟกเตอร์สามารถหยุดเมื่อไรก็ได้ เพราะเป็นงานปรับปรุงการออกแบบโดยไม่เปลี่ยนผลลัพธ์ของโค้ด จึงสามารถทำอย่างต่อเนื่องทีละเล็กทีละน้อยได้
- หลายคนมักเข้าใจผิดว่าการรีแฟกเตอร์คือการเขียนโค้ดใหม่ทั้งชุด แต่คำจำกัดความของ Fowler จำกัดขอบเขตไว้แคบมาก
กรณีการนำไปใช้จริง
- ไม่นานมานี้ มีการนำรีแฟกเตอร์ที่แท้จริงมาใช้ระหว่างปรับปรุงการใช้ Next.js และ React เพื่อเพิ่มประสิทธิภาพของ roborobato.com
- มีการปรับโครงสร้างโค้ดใหม่โดยไม่เปลี่ยนฟีเจอร์หรือ UI และแบ่งออกเป็น 5 คอมมิตเพื่อให้ตรวจทานและนำไปใช้ได้ง่าย

What Is ChatGPT Doing and Why Does It Work? (Stephen Wolfram)

อินไซต์สำคัญ: หนังสือช่วยให้เข้าใจวิธีการทำงานของ LLM โดยเฉพาะกลไกการทำนายโทเค็นถัดไป และแนวคิดเรื่อง temperature
- อธิบายว่าความสุ่มที่มีอยู่ภายใน LLM นั้นเองคือสิ่งที่ทำให้มันทรงพลัง
คุณค่าของหนังสือ
- ให้บทวิเคราะห์ที่เรียบเรียงอย่างดีซึ่งอธิบายหัวข้อซับซ้อนให้เข้าใจได้ง่าย
- มอบคำศัพท์พื้นฐานและกรอบความคิดสำหรับทำความเข้าใจ LLM ซึ่งยังคงเป็นความรู้สำคัญอยู่เสมอ

Fundamentals of Software Architecture (Mark Richards, Neal Ford)

อินไซต์สำคัญ: หนังสือเน้นความสำคัญของความสามารถในการขายวิสัยทัศน์ด้านสถาปัตยกรรมให้กับผู้มีส่วนได้ส่วนเสียทั้งสายเทคนิคและไม่ใช่เทคนิค และถือว่านี่คือองค์ประกอบพื้นฐานของสถาปัตยกรรม
- ต้องสื่อสารอย่างต่อเนื่องและพิสูจน์คุณค่าของตัวเองอยู่เสมอ ท่าทีแบบ "ต้องเป็นไปตามที่ฉันพูด" ไม่ใช่สิ่งที่พึงปรารถนา
หลักการเพิ่มเติม
- ไม่ควรอยู่บนหอคอยงาช้าง แต่ต้องทำงานร่วมกับโค้ดและทีม สัมผัสการออกแบบด้วยตัวเอง และก้าวนำไปสองสามขั้นเพื่อคาดการณ์ปัญหาที่อาจเกิดขึ้น
- หนังสือเน้นบทบาทของ ADR (Architectural Design Document) และกล่าวว่าการบันทึกและพัฒนากระบวนการตัดสินใจเป็นสิ่งสำคัญ
- การบันทึกและแบ่งปันการตัดสินใจเป็นสิ่งจำเป็นเพื่อหลีกเลี่ยง "ปรากฏการณ์ Groundhog Day"

The Clean Coder (Robert C. Martin, "Uncle Bob")

อินไซต์สำคัญ: หนังสือสำรวจว่าความเป็นมืออาชีพที่แท้จริงคืออะไร โดยเฉพาะมุมมองอันสุดโต่งของ Uncle Bob ต่อเดดไลน์และการประเมินเวลา
- ในวัฒนธรรมวิศวกรรม มักมีความสับสนระหว่างการประเมินกับเดดไลน์ แต่หากต้องการความเป็นมืออาชีพ ก็จำเป็นต้องแยกสองสิ่งนี้ออกจากกันอย่างชัดเจน
ลักษณะเด่นของหนังสือ
- เต็มไปด้วยเรื่องเล่า และช่วยให้รู้จักตัวตนของ Uncle Bob ได้ลึกขึ้น
- หนังสือเขียนได้ดี อ่านง่าย และเหมาะกับการอ่านตั้งแต่ต้นจนจบ

Working Effectively with Legacy Code (Michael Feathers)

อินไซต์สำคัญ: โค้ดที่แก้ไขยากหรือทำให้รู้สึกกลัวนั้นเป็นโค้ดที่ออกแบบไม่ดี และเราสามารถทำให้ใครก็ตามแก้ไขโค้ดได้ง่ายขึ้น
- หนังสือให้นิยาม legacy code ว่าเป็นโค้ดที่ไม่มี test coverage หรือเป็นโค้ดที่เราไม่เข้าใจวิธีการทำงาน
- ให้แนวทางว่าจะเริ่มต้นอย่างไรเมื่อไม่ได้อยู่ในโปรเจกต์ greenfield หรือมีอำนาจควบคุม codebase ไม่มากพอ
คุณค่าของหนังสือ
- แต่ละส่วนเป็นอิสระต่อกัน จึงเหมาะสำหรับใช้อ้างอิง และมีประสิทธิภาพกว่าหากเปิดอ่านเฉพาะส่วนที่ต้องการ แทนการอ่านรวดเดียวตั้งแต่ต้นจนจบ

Web Scalability for Startup Engineers (Artur Ejsmont)

อินไซต์สำคัญ: ในช่วงเริ่มต้นของสตาร์ตอัป สิ่งสำคัญคือการเดินหน้าให้เร็ว มากกว่าการทำ optimization มากเกินไปหรือไล่ตามความพร้อมใช้งานระดับสูง และควรลงทุนในจังหวะที่เหมาะสม
- สตาร์ตอัประยะแรกไม่ควรพยายามสร้าง fault tolerance หรือ high availability ที่สมบูรณ์แบบตั้งแต่ตอนที่ยังมีลูกค้าไม่มาก
ข้อจำกัดตามยุคสมัยและข้อเสนอแนะ
- สิ่งที่หนังสือกล่าวถึงคือประเด็นสำคัญของยุค 2010s ซึ่งปัจจุบันบริษัท SaaS และ PaaS จำนวนมากเข้ามาช่วยแก้ปัญหาส่วนนี้แล้ว
- เวอร์ชันใหม่ควรถูกอัปเดตให้เป็นแฮนด์บุ๊กสำหรับผู้ก่อตั้งครั้งแรกหรือผู้นำทางเทคนิค

Recoding America (Jennifer Pahlka)

อินไซต์สำคัญ: หนังสือแสดงให้เห็นถึงความไร้ประสิทธิภาพของซอฟต์แวร์ภาครัฐและความเป็นไปได้ในการปรับปรุง พร้อมชี้ว่าซอฟต์แวร์ภาครัฐก็สามารถสร้างให้มีคุณภาพดีได้มากพอ
- ซอฟต์แวร์ภาครัฐมักถูกประเมินจากการทำเช็กลิสต์ให้ครบ มากกว่าการพิจารณาว่ามันทำงานได้จริงหรือไม่
- หนังสือเน้นความสำคัญของการนำหลักการแกนกลางของ Agile อย่าง "การทำงานร่วมกับลูกค้าอย่างใกล้ชิด" และ "การส่งมอบซอฟต์แวร์ที่ใช้งานได้อย่างต่อเนื่อง" ไปใช้กับการพัฒนาซอฟต์แวร์ภาครัฐ

Building Evolutionary Architectures (Neal Ford, Rebecca Parsons, Patrick K. Kua, Pramod Sadalage)

อินไซต์สำคัญ: หนังสือเสนอแนวคิด "Fitness Functions" เพื่อประเมินอย่างเป็นกลางว่าระบบทำงานได้ตามที่คาดหวังหรือไม่ และแสดงวิธีสร้างสถาปัตยกรรมที่พัฒนาเปลี่ยนแปลงได้
- Fitness Functions เป็นสิ่งจำเป็นต่อการติดตามวิวัฒนาการของระบบ และตรวจสอบว่าการตัดสินใจด้านการออกแบบทำงานตามเจตนาหรือไม่
- ต้องคำนึงถึงผลกระทบของโครงสร้างองค์กรที่มีต่อสถาปัตยกรรมซอฟต์แวร์ เช่น กฎของ Conway เมื่อจัดทีมและออกแบบระบบ

Looks Good to Me (Adrian Bergeron)

อินไซต์สำคัญ: แม้จะจำคำแนะนำเฉพาะเจาะจงในหนังสือไม่ได้ แต่หนังสือก็ช่วยย้ำเตือนอีกครั้งถึงความสำคัญของ pull request (PR)
จากกระบวนการย้ายระบบที่เพิ่งทำในบริษัทเมื่อไม่นานมานี้ ทำให้ได้ทบทวนว่าการรีวิว PR ไม่รัดกุมพอ และรู้สึกว่าจำเป็นต้องกลับมาอ่านหนังสือเล่มนี้อีกครั้ง
คุณค่าของหนังสือ
- ให้แนวทางที่ดีเกี่ยวกับการกำหนดข้อตกลงทางสังคมและมาตรฐานภายในทีม
- หนังสือเทคนิคมีประโยชน์สำหรับการกลับมาเปิดอ่านอีกครั้งเมื่อจำเป็น และช่วยต่อยอดไอเดียได้

Slow Productivity (Cal Newport)

อินไซต์สำคัญ: ข้อความที่ว่า "ทำงานให้น้อยลงและโฟกัสกับงานที่มีความหมาย" เน้นให้ระวัง pseudo-productivity และควรมุ่งไปที่กิจกรรมที่มีมูลค่าสูง
- เป็นหนังสือที่แสดงให้เห็นวิธีคิดอันลุ่มลึกของ Cal Newport และช่วยลดกิจกรรมที่ไม่จำเป็นเพื่อไปโฟกัสกับงานสำคัญ เช่น การทำพอดแคสต์
- ยิ่งอาชีพก้าวหน้ามากขึ้น ก็ยิ่งต้องโฟกัสกับงานที่มี leverage และมูลค่าสูงที่สุด และ pseudo-productivity คือสิ่งที่ขัดขวางเรื่องนั้น

The Unicorn Project (Gene Kim)

อินไซต์สำคัญ: อธิบายความสำคัญของกระบวนการ DevOps จากมุมมองของวิศวกรรมซอฟต์แวร์ และเน้นว่าต้องแก้ปัญหาที่รากเพื่อเร่งความเร็วในการพัฒนา
- ระบบที่ต้องพึ่งพา release manager นั้นไม่มีประสิทธิภาพ และควรมีโปรเซสอัตโนมัติที่ทำให้ใครก็จัดการ release ได้
โครงสร้างและอิทธิพลของหนังสือ
- ต่างจากงานก่อนหน้าอย่าง 'The Phoenix Project' ตรงที่อธิบาย DevOps จากมุมมองวิศวกรรมซอฟต์แวร์ จึงนำไปใช้กับนักพัฒนาได้กว้างกว่า
- ใช้รูปแบบอุปมาเพื่อถ่ายทอดเนื้อหาเชิงเทคนิคให้เข้าใจง่าย และเป็นผู้นำเทรนด์การผสานเรื่องเล่าเข้ากับหนังสือเทคนิค

Tidy First (Kent Beck)

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

Unix: A History and a Memoir

อินไซต์สำคัญ: ทำให้เข้าใจวิธีการทำงานและความสำคัญของ "pipes" ซึ่งเป็นหนึ่งใน building block หลักของ Unix
- ด้วยปรัชญาแบบ Unix ที่ให้แต่ละโปรแกรมรับอินพุตแล้วส่งคืนเอาต์พุต จึงสามารถเชื่อมเอาต์พุตระหว่างโปรแกรมได้ง่ายผ่านตัวดำเนินการ pipe
บทบาทของ Doug McIlroy
- Doug McIlroy มีบทบาทสำคัญในการหลอมรวมแนวคิดของ Unix ผ่าน pipe และมีส่วนช่วยกำหนดปรัชญาแบบ Unix

The Twelve-Factor App

อินไซต์สำคัญ: นำเสนอหลักการ 12 ข้อสำหรับการสร้างแอปพลิเคชันแบบ cloud-native แต่หากนำหลักการเหล่านี้ไปใช้อย่างผิดวิธีก็อาจเพิ่มความซับซ้อนได้แทน
- เป็นหลักการที่ถูกสร้างขึ้นในยุค Heroku และเมื่อดูหลักพื้นฐานแล้วก็เป็นสิ่งที่ชวนพยักหน้าเห็นด้วย
- เช่นเดียวกับกรณีที่นำเทคโนโลยีบางอย่างอย่าง Kubernetes ไปใช้โดยไม่เข้าใจ หลักการเหล่านี้ก็สามารถถูกใช้อย่างผิดทางได้เช่นกัน

The Agile Manifesto

อินไซต์สำคัญ: Agile เป็นปฏิกิริยาตอบโต้ต่อโมเดล waterfall โดยมีเป้าหมายเพื่อส่งมอบซอฟต์แวร์ที่ใช้งานได้อย่างรวดเร็ว และสะท้อน feedback จากลูกค้าให้ไว
- แก่นของ Agile คือการทำงานร่วมกับลูกค้าและผู้มีส่วนได้ส่วนเสียอย่างใกล้ชิด เพื่อปรับปรุงซอฟต์แวร์แบบ iterative
การประยุกต์ใช้สมัยใหม่และคำวิจารณ์
- แม้สาระสำคัญของ Agile จะคุ้นเคยสำหรับนักพัฒนาจำนวนมาก แต่หากไม่มีความพยายามอย่างตั้งใจ ก็อาจสูญเสียความหมายไปได้ง่าย
- เพราะมันฝังรากลึกในงานพัฒนาซอฟต์แวร์ยุคใหม่ จึงทำให้เป็นการหันกลับมาทบทวนวิธีเดิมมากกว่าการเรียนรู้สิ่งใหม่
- มันมีประสิทธิภาพมากในฐานะแรงต้านต่อโมเดล waterfall และย้ำว่าด้วยความซับซ้อนของซอฟต์แวร์ การส่งมอบสิ่งที่มีคุณค่าเป็นหน่วยเล็ก ๆ สำคัญกว่าการวางแผนระยะยาว

The Software Engineer's Guidebook (Jorge Orozco)

อินไซต์สำคัญ: เมื่ออาชีพเติบโตขึ้น ควรโฟกัสกับงานที่มี leverage สูง และต้องบริหารเส้นทางอาชีพของตนเองอย่างเชิงรุก
- เน้นความสำคัญของผู้จัดการและสปอนเซอร์ โดยผู้จัดการจะสนับสนุนคุณเพื่อการเลื่อนตำแหน่ง และคุณเองก็ต้องพยายามตอบให้ได้ตามความคาดหวังนั้น
ลักษณะเด่นของหนังสือ
- คล้ายกับจดหมายข่าว 'The Pragmatic Engineer' ตรงที่ให้คำแนะนำเชิงปฏิบัติเกี่ยวกับการจัดการอาชีพ
- ให้เฟรมเวิร์กที่จำเป็นต่อการทำความเข้าใจเส้นทางอาชีพที่ซับซ้อน และการทำให้ผู้อื่นเห็นคุณค่าในตัวเองอย่างเชิงรุก

Hypermedia Systems (Carson Gross, et al.)

อินไซต์สำคัญ: ด้วยเทคโนโลยีอย่าง HTMX ก็สามารถสร้างเว็บแอปพลิเคชันที่ไดนามิกเพียงพอด้วย server-side rendering ได้ และลดความจำเป็นของ JavaScript client ที่ซับซ้อนลงได้
- โดยอาศัยข้อดีของระบบ hypermedia ซึ่งเป็นแนวคิดดั้งเดิมของเว็บ หากมีสเปกที่ดี ก็สามารถทำฟังก์ชันจำนวนมากฝั่งเซิร์ฟเวอร์ได้โดยไม่ขึ้นกับเทคโนโลยี backend
ข้อดีและข้อจำกัดของ HTMX
- โค้ดที่เขียนด้วย HTMX เรียบง่ายและดูแลรักษาง่าย อีกทั้งมีโอกาสอยู่ได้นานกว่าเฟรมเวิร์กสมัยใหม่
- HTMX อาจไม่ใช่อนาคตของการพัฒนาเว็บ แต่ความเห็นที่คัดค้านเช่นนี้ก็ช่วยให้ตัดสินใจได้ดีขึ้นในฐานะวิศวกร

Team Topologies (Matthew Skelton, Manuel Pais)

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

Ace the System Design Interview (Alex Xu)

อินไซต์สำคัญ: ในการสัมภาษณ์ system design การใช้ "back-of-the-napkin math" เพื่อประเมินขนาดและความต้องการด้านประสิทธิภาพเป็นสิ่งสำคัญ
- หากจำค่าทั่วไปอย่างเวลา ขนาดข้อมูล ฯลฯ และนำมาใช้เพื่อทำให้ข้อกำหนดของระบบเป็นรูปธรรม ก็จะออกแบบบนพื้นฐานของเหตุผล ไม่ใช่การเดา
- ตัวอย่างเช่น หากต้องรองรับจำนวนทวีตต่อชั่วโมง เมื่อรู้จำนวนไบต์ต่อทวีตและความยาวของทวีต ก็สามารถคำนวณพื้นที่จัดเก็บและ throughput ที่ต้องใช้ได้
วิธีใช้ในการสัมภาษณ์
- หากคิดออกเสียงและแชร์กระบวนการคำนวณกับผู้สัมภาษณ์ ก็จะได้รับ feedback และนำไปสู่การออกแบบที่ดีขึ้นได้
- สิ่งสำคัญไม่ใช่แค่การไล่รายชื่อเทคโนโลยีล่าสุด แต่ต้องอธิบายเหตุผลที่เลือกเทคโนโลยีนั้นด้วย

The Good News Factory (Kent Beck)

อินไซต์สำคัญ: หากทีมซอฟต์แวร์จะเป็น "โรงงานข่าวดี" ที่ส่งมอบ "ข่าวดี" ได้อย่างต่อเนื่อง การมี clean code และการสร้างระบบที่ขยายได้จึงเป็นสิ่งจำเป็น
- หากทีมไม่สามารถแสดงผลลัพธ์เชิงบวกได้อย่างสม่ำเสมอ ก็อาจเกิดเรื่องเล่าเชิงลบจากภายนอกขึ้นมาแทน
ลักษณะเด่นของหนังสือ
- เป็นหนังสือรูปแบบรายงานที่สั้นและกระชับ ซึ่งถ่ายทอดสารหลักได้อย่างมีประสิทธิภาพ

Thinking in Systems (Donella Meadows)

อินไซต์สำคัญ: แนวคิดเรื่อง "stocks and flows" ช่วยให้เข้าใจคุณลักษณะเชิงพลวัตของระบบ และมอบเฟรมเวิร์กที่มีประโยชน์ต่อการวิเคราะห์ระบบที่ซับซ้อน
- เช่นเดียวกับการเข้าใจความแตกต่างระหว่าง GDP (flow) กับมูลค่าตลาด (stock) การแยกแยะสถานะปัจจุบันของระบบกับอัตราการเปลี่ยนแปลงเป็นสิ่งสำคัญ
คุณค่าของหนังสือ
- แม้จะเป็นนามธรรม แต่ก็มอบมุมมองระดับสูงที่ทรงคุณค่าต่อการคิดเชิงกลยุทธ์และการคิดเชิงระบบ

Grokking Concurrency (Karol Bobrov)

อินไซต์สำคัญ: การ "ปรับขนาดให้เหมาะสม" ของโมเดล concurrency เป็นเรื่องสำคัญ เพราะทั้งการแบ่งละเอียดเกินไปและการทำกว้างเกินไปต่างก็มีข้อเสีย
- หนังสืออธิบายวิธีทำความเข้าใจหน่วยงานที่สามารถทำแบบขนานหรือแยกเป็นงานพร้อมกันได้ และวิธีจูนระบบตามนั้น

Rework (Jason Fried, David Heinemeier Hansson)

อินไซต์สำคัญ: เราสามารถใช้ข้อได้เปรียบจากการเป็นผู้เล่นรายเล็กและยังไม่เป็นที่รู้จัก เพื่อเดินหน้าทำซ้ำ สร้างใหม่ และสร้างความสำเร็จได้
- ข้อเสียของการยังไม่โด่งดังอาจกลายเป็นโอกาสของนวัตกรรมได้ และควรใช้ประโยชน์จากมันเพื่อไม่ให้พลาดข้อดีของความสำเร็จ
ลักษณะเด่นและอิทธิพลของหนังสือ
- เป็นหนังสือที่เขียนดีและมีเหตุผล ช่วยสร้างแรงบันดาลใจให้กับคนที่ต้องการสร้างสิ่งใหม่ผ่านการ bootstrap หรือสร้างสิ่งที่ไม่สอดคล้องกับนิยามความสำเร็จกระแสหลัก
กรณีความสำเร็จของ Basecamp และ 37signals พิสูจน์ว่าปรัชญาของพวกเขายังคงใช้ได้แม้เวลาจะผ่านไป

In the Plex (Steven Levy)

อินไซต์สำคัญ
- ความสามารถของวิศวกร Google ในการคิดค้นแนวคิดซับซ้อนอย่างทฤษฎีการประมูลขึ้นมาใหม่อย่างสร้างสรรค์ คือผลลัพธ์ที่ได้เมื่อจ้างคนเก่งและไว้วางใจพวกเขา
- ความสำเร็จของสตาร์ทอัพไม่ได้การันตีไว้ จึงต้องพยายามอย่างต่อเนื่องและมีส่วนร่วมเพื่ออนาคตของบริษัท
ความเชื่อมโยงกับผู้เขียน
- Steven Levy ผู้เขียนเป็นนักเขียนชั้นยอด และหนังสืออีกเล่มของเขาอย่าง 'Crypto' ก็น่าแนะนำเช่นกัน
- ประสบการณ์ที่ได้ไปสัมภาษณ์กับบริษัทซึ่งมีบุคคลในหนังสือเป็น CEO อยู่ในปัจจุบันนั้นน่าสนใจมาก

Thinking Like a Large Language Model (Mukund Sundararajan)

อินไซต์สำคัญ: แม้ความทรงจำเฉพาะเกี่ยวกับหนังสือเล่มนี้จะเลือนราง แต่ก็ช่วยให้เข้าใจวิธีคิดของ LLM ได้

The DevOps Handbook

อินไซต์สำคัญ
- ให้แนวทางด้านการทำ DevOps ในทางปฏิบัติ เช่น CI/CD pipeline, automatic rollback และ observability ที่ดีขึ้น ซึ่งช่วยยกระดับความสามารถด้านซอฟต์แวร์เอ็นจิเนียริงของทีมอย่างมาก
- เมื่อต้องปล่อยฟีเจอร์ใหม่อย่าง "ฟังก์ชันค้นหาใหม่" หนังสือแนะนำเทคนิค "shadow traffic" ที่ส่งทราฟฟิกจริงบางส่วนไปยัง API ใหม่เพื่อสังเกตผลลัพธ์
- เน้นความสำคัญของการแยก deployment ออกจาก release และสามารถใช้ feature flag เพื่อรับมือ regression ที่อาจเกิดขึ้นระหว่างการย้ายระบบได้อย่างรวดเร็ว
ผู้เขียนและคุณค่าของหนังสือ
- มีผู้เขียนชื่อดังอย่าง Gene Kim, Jess Humble, Patrick Dubois, Nicole Forsgren และ John Willis ร่วมเขียน และมีเนื้อหาที่เสริมกับ 'Unicorn Project' และ 'The Phoenix Project'

Just for Fun: How Linus Torvalds Started an Accidental Revolution

อินไซต์สำคัญ: Linus Torvalds สร้าง Linux ขึ้นมาด้วยการโฟกัสกับสิ่งที่เขาสนุก และสิ่งนั้นก็นำไปสู่ผลลัพธ์ที่เปลี่ยนโลก
- การโฟกัสกับสิ่งที่สนุกคือแรงจูงใจที่ทำให้เราทำงานหนักที่สุด และอาจนำไปสู่ความสำเร็จครั้งใหญ่แบบไม่คาดคิด
นวัตกรรมของซอฟต์แวร์โอเพนซอร์ส
- Linus Torvalds บุกเบิกแนวทางที่ไม่ดั้งเดิมในการสร้างรายได้จากซอฟต์แวร์โอเพนซอร์สพร้อมยึดมั่นในหลักการของตน ซึ่งส่งผลอย่างมากต่อการดูแลเซิร์ฟเวอร์และวิธีการ commit โค้ด

Made to Stick

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

Staff Engineer (Will Larson)

อินไซต์สำคัญ: ในระดับ Staff Engineer ควรโฟกัสกับงานที่มีลำดับความสำคัญสูงและมีอิมแพกต์มาก ซึ่งเป็นตัวชี้วัดสำคัญที่ใช้ได้ตลอดเส้นทางอาชีพ
- ไม่มีเส้นทางตายตัวในการเป็น Staff Engineer และผู้คนจากหลากหลายพื้นเพต่างก็แก้ปัญหาที่ซับซ้อนได้

Finite and Infinite Games (James P. Carse)

อินไซต์สำคัญ: "เกมจำกัด" มีผลแพ้ชนะชัดเจน แต่ "เกมไม่สิ้นสุด" มีเป้าหมายเพื่อสนุกกับการเล่นเกมนั้นเอง และการมุ่งสู่เกมไม่สิ้นสุดในชีวิตเป็นสิ่งสำคัญ
- ตอนที่ Linus Torvalds สร้าง Linux เขาไม่ได้เล่นเกมจำกัดแบบการสร้างระบบปฏิบัติการที่ดังที่สุด แต่เล่นเกมไม่สิ้นสุดอย่างการสร้างระบบปฏิบัติการที่ดีที่สุดและสร้างชุมชนขึ้นมา

Radical Candor (Kim Scott)

อินไซต์สำคัญ: ฟีดแบ็กที่ตรงไปตรงมาและซื่อสัตย์กลับเป็นหนทางที่ใส่ใจอีกฝ่ายจริง ๆ และควรหลีกเลี่ยง "ruinous empathy"
- การให้ฟีดแบ็กอย่างตรงไปตรงมาเกิดจากความห่วงใยต่อความเป็นอยู่ของอีกฝ่ายอย่างจริงใจ และต่างจากการเสียมารยาท
- เวลาจะให้ฟีดแบ็กควรคำนึงถึงความรู้สึกของอีกฝ่าย แต่ก็ต้องสื่อสารประเด็นสำคัญให้ชัดเจน

Mastering OpenTelemetry and Observability (Steve Flanders)

อินไซต์สำคัญ: ควรหลีกเลี่ยง vendor lock-in และใช้ OpenTelemetry แต่ในยุค AI ก็ทำให้กลับมาทบทวนว่าความสำคัญของ vendor lock-in อาจเปลี่ยนไป
- ความสะดวกของเครื่องมืออย่าง DataDog อาจทำให้ vendor lock-in ดูน่าสนใจ แต่ก็ควรคำนึงถึงความเสี่ยงอย่างการเปลี่ยนราคา หรือการควบรวมกิจการ

Beyond Vibe Coding (Addy Osmani) & Advanced React (Nadia Makarevich)

อินไซต์สำคัญ
- 'Beyond Vibe Coding' นำเสนอแนวคิดของ "augmented AI" ที่วิศวกรผู้มีประสิทธิภาพทำงานร่วมกับ coding agent เพื่อเขียนโค้ด
- 'Advanced React' เหมาะสำหรับใช้เป็นเอกสารอ้างอิง

The Tao of Programming (Jeffrey James)

อินไซต์สำคัญ: การสร้างระบบปฏิบัติการสำคัญแค่ความถูกต้องทางเทคนิค แต่การจำลองโลกจริงอย่างระบบเงินเดือนนั้นยากกว่า เพราะมีปัญหาซับซ้อนรวมถึงผู้มีส่วนได้ส่วนเสียเข้ามาเกี่ยวข้อง
- เรื่องนี้อาจไม่ใช่สิ่งที่เป็นธรรมชาติสำหรับโปรแกรมเมอร์ และชี้ให้เห็นว่าการจำลองโลกจริงเป็นซอฟต์แวร์นั้นมีความซับซ้อนโดยเนื้อแท้
ความเชื่อมโยงกับบทความ "Worse Is Better"
- 'The Tao of Programming' และ "Worse Is Better" เป็นงานเขียนประเภทคล้ายกันที่สั้นแต่ชวนให้คิดลึก

Mastering the Behavioral Interview (Austin McDonald)

อินไซต์สำคัญ: สามารถเรียนรู้วิธีเล่าประสบการณ์ของตัวเองให้เข้ากับ archetype แบบ "แฮ็กเกอร์ผู้เดียวดาย" ในการสัมภาษณ์สายเทคสไตล์ซิลิคอนแวลลีย์
- ทักษะการเล่าเรื่องอย่างมีประสิทธิภาพในการสัมภาษณ์สำคัญมาก และหนังสือเล่มนี้ก็อธิบายวิธีทำไว้อย่างชัดเจน

Designing Data-Intensive Applications (Martin Kleppmann)

อินไซต์สำคัญ: เจาะลึกแนวคิดพื้นฐานของ distributed systems เช่น reliability, latency เทียบกับ throughput และ resilience เทียบกับการฟื้นตัวอย่างรวดเร็ว
- ยังครอบคลุมหัวข้ออย่าง data privacy และการฉกฉวยความสนใจ ทำให้ต้องคิดทบทวนมากขึ้นเมื่อต้องสร้างระบบที่มีความต้องการสูง

Reflections on Trusting Trust (Ken Thompson) & Coding Machines (Lawrence Kesteloot)

อินไซต์สำคัญ: ในยุคที่ AI สร้างโค้ดได้ ประเด็นเรื่องความไว้วางใจต่อโค้ดที่ถูกสร้างขึ้น และเจตนาร้ายที่อาจแฝงอยู่ (เช่น steganography) เป็นสิ่งที่ชวนให้ขบคิดอย่างลึกซึ้ง

Frictionless (Nicole Forsgren, Abby Noda)

อินไซต์สำคัญ: หนังสือเล่มนี้โฟกัสการทำ initiative ด้าน DevEx โดยมุ่งไปที่ผู้นำในองค์กรขนาดใหญ่เป็นหลัก จึงยังไม่ส่งผลมากนักในช่วงอาชีพปัจจุบัน
- แม้จะมีเนื้อหาด้าน DevEx ที่ยอดเยี่ยม แต่ก็อาจสำคัญกว่ากับบริษัทที่อยู่หลัง Series C ไปแล้ว

Project Hail Mary (Andy Weir)

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