UncleQuin

PlanktonSoft
  • 0.0 (0)
  • Technology
  • Monthly

Software & Developer Podcast

  1. 1 hr ago

    อย่ารักคำว่า "Developer": ถอดรหัส Nine Lies About Work และการค้นหาส่วนของงานที่คุณรักที่สุด EP.41

    กี่ครั้งแล้วที่เราคุยกับตัวเองด้วยคำว่า "เราเป็น Developer", "เราเป็น Software Architect", หรือ "เราเป็น Solo Founder" แล้วเราก็เผลอแบกรับความคาดหวังทั้งหมดของชื่อตำแหน่งนั้นไว้บนไหล่ จนกระทั่งเกิดภาวะ Burnout โดยไม่รู้ตัว? ในหนังสือ Nine Lies About Work  เล่าถึงเรื่องราวของ ไมลส์ ศัลยแพทย์ฝีมือดีที่ประสบความสำเร็จอย่างสูง เขาเกลียดความกดดันจากการช่วยให้ผู้ป่วยฟื้นตัวอย่างที่สุด แต่เขากลับ รักความเครียด ความตื่นเต้น และการตัดสินใจในนาทีใกล้ปากเหวในห้องผ่าตัด... เรื่องราวของหมอไมลส์ชี้ให้เราเห็นความจริงที่แหลมคมว่า คุณค่าของการทำงาน ไม่ได้อยู่ที่ชื่อตำแหน่ง แต่อยู่ที่ว่าส่วนไหนของงานที่คุณรักและลืมเวลาไปกับมันจริง ๆ EP.41 นี้ ลุงควิน และ คุณพลอย (Solo Tech Founder) จะพาคุณไปถอดรหัสความคิด ถอดเปลือกคำว่า "Developer" หรือ "คนทำเทคฯ" ออก แล้วสำรวจตัวเองอย่างตรงไปตรงมาผ่านเลนส์ปรัชญา สโตอิก (Stoicism) เพื่อค้นหานาทีในห้องผ่าตัดของคุณเอง และออกแบบชีวิตการทำงานให้มีพลังชีวิตในทุก ๆ วัน 📌 สิ่งที่คุณจะได้เรียนรู้จากตอนนี้: The Surgical Room Moment: ถอดบทเรียนจากหมอไมลส์ในหนังสือ Nine Lies About Work—ทำไมหมอผู้เกลียดการดูแลคนป่วยฟื้นตัว ถึงกลายเป็นศัลยแพทย์ที่ยอดเยี่ยมได้ Don't Love the Label, Love the Activity: ทำไมการหลงรักชื่อตำแหน่ง (Label) ถึงเป็นกับดักที่ทำให้โปรแกรมเมอร์และคนทำสตาร์ทอัพหมดไฟ Self-Awareness & Stoic Mindset: การยอมรับขีดจำกัดและความชอบของตัวเองอย่างสโตอิก โดยไม่หวั่นไหวต่อคำตัดสินหรือกรอบสังคม Design Around Your Core Joy: เทคนิคการบริหารพลังงานสมอง แบ่งส่วนงานที่ไม่ชอบให้เครื่องมือช่วยจัดการ แล้วเซฟพลังไว้ลงมือกับส่วนงานที่คุณทำได้ดีที่สุด "คุณไม่ได้ชอบทุกอย่างในการเป็น Developer หรอก... จงหาให้เจอว่าบรรทัดไหน หรือเนื้องานส่วนไหนที่คุณรักที่สุด แล้วปักหลักทำสิ่งนั้นให้เปล่งประกาย"

    อย่ารักคำว่า "Developer": ถอดรหัส Nine Lies About Work และการค้นหาส่วนของงานที่คุณรักที่สุด EP.41

  2. 27 Jul

    ราคาของความจริง: Event Sourcing, ความทรงจำมนุษย์ และตรรกะแห่งการไม่ลืม EP.40

    เมื่อไหร่ก็ตามที่ระบบเกิดปัญหา หรือข้อมูลเกิดความขัดแย้ง คำถามแรกที่ทุกคนถามตรงกันคือ "มันเกิดอะไรขึ้นกันแน่?" ในการพัฒนาระบบซอฟต์แวร์รูปแบบเดิม (CRUD) เรามักจะเลือกวิธีที่ง่ายที่สุด คือการสั่ง UPDATE เพื่อเขียนทับข้อมูลเก่า หรือสั่ง DELETE เพื่อลบมันทิ้งไป ราวกับว่าอดีตนั้นไม่เคยเกิดขึ้น... แต่ในโลกแห่งความเป็นจริง การทำแบบนั้นคือการทำลาย "ประวัติศาสตร์" และสร้างความทรงจำเท็จให้กับระบบ ฉลองครบรอบ EP.40 นี้ ลุงควิน และ คุณพลอย (Solo Tech Founder) จะพาคุณไปเจาะลึกสถาปัตยกรรมหลังบ้านระดับลุ่มลึกอย่าง Event Sourcing และ CQRS สถาปัตยกรรมที่ไม่ยินยอมให้มีการลบทิ้งหรือเขียนทับข้อมูล แต่เลือกระบุทุกความจริงที่เกิดขึ้นเป็นสายธารของเหตุการณ์ (Append-only Log) พร้อมเชื่อมโยงสู่จิตวิทยาการรับรู้ของมนุษย์ และปรัชญา สโตอิก (Stoicism) ถึงการเผชิญหน้ากับอดีตอย่างกล้าหาญ—เพราะอดีตคือสิ่งที่เกิดขึ้นแล้วและแก้ไขไม่ได้ หน้าที่ของเราไม่ใช่การโกหกตัวเองด้วยการเขียนทับอดีต แต่คือการสร้างเหตุการณ์ชดเชย (Compensating Event) ในปัจจุบันเพื่อนำทางระบบต่อไป 📌 สิ่งที่คุณจะได้เรียนรู้จากตอนนี้: The Flaw of CRUD: ทำไมการสั่ง UPDATE หรือ DELETE บน Database ถึงเป็นการทำลาย Audit Trail และบิดเบือนความจริงของระบบ Event Sourcing 101: เข้าใจกลไก Append-only Log และการคำนวณสถานะปัจจุบันผ่านการ "เล่นซ้ำเหตุการณ์ (Replay Data)" CQRS Pattern: การแยกฝั่งบันทึกเหตุการณ์ (Command) ออกจากฝั่งอ่านข้อมูล (Query) เพื่อประสิทธิภาพและความเที่ยงตรงสูงสุด Stoic Wisdom & Compensating Events: การประยุกต์ใช้แนวคิดสโตอิกเมื่อระบบเกิดข้อผิดพลาด ยอมรับอดีตที่แก้ไม่ได้ แล้วสร้างการกระทำใหม่เพื่อปรับปรุงสถานะปัจจุบัน The Cost of Truth: ชั่งน้ำหนักระหว่าง Storage ที่ต้องจ่ายเพิ่มขึ้น กับ "ความน่าเชื่อถือและความซื่อสัตย์ของข้อมูล (Data Integrity)" ที่ได้กลับคืนมา "อดีตคือเหตุการณ์ที่เกิดขึ้นแล้วและไม่มีใครเปลี่ยนมันได้... สิ่งที่เราเลือกได้ คือการสร้างเหตุการณ์ใหม่ในปัจจุบันเพื่อนำทางอนาคต"

    ราคาของความจริง: Event Sourcing, ความทรงจำมนุษย์ และตรรกะแห่งการไม่ลืม EP.40

  3. 20 Jul

    โค้ดคุณกำลังบังคับให้สมองจำอะไรอยู่? เจาะลึกจิตวิทยาการวางพารามิเตอร์ EP.39

    มีสถิติหนึ่งที่นักพัฒนาซอฟต์แวร์ทุกคนต้องเจอ แต่มักจะมองข้ามไป นั่นคือ "โค้ดถูกอ่านบ่อยกว่าถูกเขียนหลายเท่าตัว" เวลาที่เราสร้างฟังก์ชันหรือออกแบบ API ขึ้นมา เรามักจะโฟกัสแค่ว่าทำอย่างไรให้คอมพิวเตอร์รันผ่านลื่นไหลที่สุด แต่เรากลับลืมคิดไปว่า โค้ดที่เราเขียนในวันนี้ กำลังสร้างภาระให้หน่วยความจำระยะสั้น (Short-term Memory) ของคนที่ต้องกลับมาอ่านมันในอนาคต (ซึ่งส่วนใหญ่ก็คือตัวเราเอง) มากน้อยขนาดไหน? ทำไมการเขียนฟังก์ชันสั่งพิมพ์คำซ้ำอย่าง Repeat("Hello", 5) ถึงอ่านง่ายและเบาสมองกว่า Repeat(5, "Hello") ทั้ง ๆ ที่ในมุมของคอมพิวเตอร์มันได้ผลลัพธ์เท่ากันเป๊ะ? EP.39 นี้ ลุงควิน และ คุณพลอย (Solo Tech Founder) จะมาเจาะลึกจิตวิทยาการรับรู้ของมนุษย์ที่ซ่อนอยู่หลังพารามิเตอร์ของโค้ด พร้อมหยิบยกคำสอนดั้งเดิมของเหล่าปราชญ์สโตอิก (Stoicism) มาเตือนใจชวนให้เราหันมาใส่ใจรายละเอียดเล็ก ๆ บรรทัดต่อบรรทัด เพื่อปกป้องระบบและสมองของทีมงานในระยะยาว 📌 สิ่งที่คุณจะได้เรียนรู้จากตอนนี้: Match Natural Language: ศิลปะการออกแบบ API ให้แปลความหมายสอดคล้องกับภาษาธรรมชาติในหัวมนุษย์ เพื่อลด Cognitive Load Primary Data First: กฎเหล็ก Subject-First เอาโครงสร้างข้อมูลหลักที่จะถูกกระทำขึ้นก่อน แล้วโยน Modifiers หรือคำสั่งเสริมไว้ข้างหลัง Fluent API & Method Chaining: ข้อดีของการเรียงลำดับพารามิเตอร์ที่ช่วยให้การต่อฟังก์ชันในภาษายุคใหม่อย่าง Rust หรือ Scala ลื่นไหลเหมือนอ่านหนังสือพิมพ์ Stoic Wisdom on Micro-Details: ดำดิ่งสู่คำสอนดั้งเดิมของ มาร์คัส ออเรลิอุส, เซเนกา และเซโนแห่งซิเทียม ว่าด้วยการสะสมความยอดเยี่ยมผ่านการใส่ใจสิ่งเล็ก ๆ ตรงหน้า "ความยอดเยี่ยมหรือความสุขสมบูรณ์นั้นเกิดขึ้นทีละเล็กทีละน้อย แต่ตัวมันเองไม่ใช่เรื่องเล็กน้อยเลย" — Zeno of Citium

    โค้ดคุณกำลังบังคับให้สมองจำอะไรอยู่? เจาะลึกจิตวิทยาการวางพารามิเตอร์ EP.39

  4. 14 Jul

    Solo Tech Founder: จัดการ Cognitive Load เมื่อคุณคือคนเดียวที่สร้างทั้งระบบ EP.38

    ในโลกของธุรกิจเทคโนโลยีและการเป็นผู้พัฒนาอิสระ (Independent Professional) การทำโปรเจกต์คนเดียวมักถูกมองว่าเป็นเรื่องของความเร็วและความคล่องตัว แต่ความจริงอันโหดร้ายที่ไม่มีใครบอกคุณคือ... คอขวดที่ใหญ่ที่สุดของระบบ ไม่ใช่ความเร็วของ CPU หรือแบนด์วิดท์ของเซิร์ฟเวอร์ แต่คือ "สมองมนุษย์" เมื่อคุณต้องสวมหมวกหลายใบในวันเดียวกัน ตั้งแต่ตื่นเช้ามาจัดการภาษีและกลยุทธ์ธุรกิจ ตอนบ่ายต้องมาสถาปัตยกรรมระบบ และตอนเย็นต้องลงมือเขียนโค้ดหลังบ้าน ภาระทางปัญญา (Cognitive Load) จากการสลับบริบท (Context Switching) พร้อมที่จะทำให้สมองของคุณโอเวอร์โหลดและระเบิดได้ทุกเมื่อ EP.38 นี้ ลุงควิน และ คุณพลอย (Startup Co-founder) จะมาตีแผ่วิถีการเอาตัวรอดในฐานะ Solo Tech Founder ผสานแนวคิดปรัชญา สโตอิก (Stoicism) และจิตวิทยาการประกอบร่างเครื่องมือ เพื่อเปลี่ยนระบบรอบตัวให้กลายเป็น "ทีมเวิร์ก" ส่วนขยายของสมองที่ไว้ใจได้มากที่สุด 📌 สิ่งที่คุณจะได้เรียนรู้จากตอนนี้: The Brain Bottleneck: ทำความเข้าใจวิกฤต Cognitive Load ของคนลุยเดี่ยว และทำไมสมองชีวภาพของเราจึงไม่ควรใช้จำทุกอย่าง Rust Compiler as a Co-founder: ทำไมการเลือกภาษาที่ดุและเข้มงวดเรื่องสิทธิ์การเข้าถึงข้อมูล (Exclusive References) อย่าง ภาษา Rust ถึงไม่ได้ทำให้งานช้าลง แต่เป็นการโยนภาระความจำเรื่องการตรวจตรรกะไปให้ Compiler ทำแทน Obsidian & The Extended Mind: ประยุกต์ใช้ทฤษฎีสมองส่วนขยายและปรัชญา "Write First, Organize Later" เพื่อสลัดบริบทที่รกรุงรังออกจากหัว แล้วฝากไว้ในสมองดิจิทัลได้อย่างไร้กังวล Stoicism for Solo Builder: การยอมรับขีดจำกัดของตัวเอง โฟกัสเฉพาะสิ่งที่เราควบคุมได้ และตัดความซับซ้อน (Over-engineering) ที่ไม่จำเป็นทิ้งไป "คุณไม่ได้ทำงานคนเดียวหรอกครับ... ถ้าคุณรู้จักประกอบร่างเครื่องมือรอบตัวให้กลายเป็นส่วนต่อขยายของร่างกายและจิตใจอย่างทรงพลัง"

    Solo Tech Founder: จัดการ Cognitive Load เมื่อคุณคือคนเดียวที่สร้างทั้งระบบ EP.38

  5. 12 Jul

    สถาปัตยกรรมคนจน: สร้างระบบอย่างไรให้อยู่รอดในยุคต้นทุนแพง EP.37

    ในยุคที่กระแสเงินสดคือสายเลือดของธุรกิจ หลายสตาร์ทอัพไม่ได้ตายเพราะไอเดียไม่ดี แต่ตายเพราะถูก "บิลค่า Cloud Server" ทับตายตั้งแต่ยังไม่ทันได้สเกล! วงการเทคมักจะพร่ำสอนให้เราออกแบบระบบแบบ "Silicon Valley" ที่อลังการและพร้อมรองรับคนร้อยล้านคนตั้งแต่วันแรก แต่สำหรับธุรกิจอย่างโมเดล Sharing Economy ที่กำไรต่อธุรกรรมบางเฉียบ การแบกต้นทุนทางสถาปัตยกรรมที่ใหญ่เกินตัว (Over-engineering) คือการฆ่าตัวตายทางอ้อม EP.37 นี้ ลุงควิน และ คุณพลอย จะพาไปเจาะลึกปรัชญา "สถาปัตยกรรมคนจน" ว่าเราจะเอาตัวรอดในยุคต้นทุนแพงได้อย่างไร ผ่านเลนส์ของการเลือกใช้ภาษาโปรแกรมมิ่งระดับล่าง (Systems Programming) และปรัชญาการใช้ชีวิตแบบสโตอิก 📌 สิ่งที่คุณจะได้เรียนรู้จากตอนนี้: The Silicon Valley Trap: กับดักการออกแบบระบบที่ซับซ้อนเกินจริง (Over-engineering) และเหตุผลที่ Microservices อาจไม่เหมาะกับทุกคนในวันเริ่มต้น Rust for Business Survival: ทำไมการเลือกใช้ Systems Programming อย่าง ภาษา Rust ถึงเป็นกลยุทธ์ทางธุรกิจ? เจาะลึกการรีดประสิทธิภาพ (Low Memory footprint) ที่ช่วยหั่นค่าเซิร์ฟเวอร์จากหลักหมื่นเหลือหลักร้อย Stoic Architecture: การนำปรัชญา Stoicism (ลัทธิสโตอิก) มาใช้กับการออกแบบระบบ หักห้ามใจจากเทคโนโลยีที่เป็นแค่กระแส (Hype) และกล้าที่จะตัดสิ่งที่ไม่จำเป็นทิ้งไป "จงเป็นวิศวกรที่สมถะ ใช้ทรัพยากรให้น้อยที่สุด แต่สร้างอิมแพคให้มากที่สุด อย่าปล่อยให้ระบบซับซ้อนจนกลายเป็นสัตว์ประหลาดที่กลับมากินกระแสเงินสดของบริษัทตัวเอง"

    สถาปัตยกรรมคนจน: สร้างระบบอย่างไรให้อยู่รอดในยุคต้นทุนแพง EP.37

  6. 10 Jul

    สถาปัตยกรรมแบบเติบโตตามธรรมชาติ: ปรัชญา Write First, Organize Later ในโลกของโค้ด EP.36

    ในวงการพัฒนาซอฟต์แวร์ เรามักถูกสอนให้วางแผนทุกอย่างให้ "เป๊ะ" ตั้งแต่วันแรก ต้องวาด UML Diagram ให้สมบูรณ์แบบ และออกแบบ Database Schema ให้รองรับอนาคตไปอีก 5 ปี... แต่ความจริงที่หลีกเลี่ยงไม่ได้คือ ยิ่งเราพยายามสร้างโครงสร้างที่สมบูรณ์แบบมากเท่าไหร่ ระบบของเราก็ยิ่งเปราะบาง (Fragile) และพังทลายง่ายขึ้นเมื่อ Requirement ทางธุรกิจเปลี่ยนทิศทาง EP.36 นี้ ลุงควิน และ คุณเมย์ (Senior PM) จะพาคุณก้าวออกจากกรอบคิดแบบ Big Design Up Front ไปสำรวจปรัชญาการจัดการความรู้ (Knowledge Management) สไตล์ Utility-first ที่เน้นการ "จดไปก่อน ค่อยจัดระเบียบทีหลัง" (Write First, Organize Later) เราจะนำแนวคิดจากเครื่องมืออย่าง Obsidian มาสกัดเป็นสถาปัตยกรรมซอฟต์แวร์ระดับโลกอย่าง Event Sourcing และ CQRS เพื่อสร้างระบบที่ยืดหยุ่นและเติบโตได้ตามธรรมชาติของพฤติกรรมผู้ใช้งานจริง 📌 สิ่งที่คุณจะได้เรียนรู้จากตอนนี้: The Illusion of Perfect Design: ภาพลวงตาของการออกแบบที่สมบูรณ์แบบ ทำไมการพยายามควบคุมโครงสร้างล่วงหน้าถึงกลายเป็นกรงขังทีมพัฒนาเสียเอง Write First, Organize Later: การปรับ Mindset จากการยึดติดกับ "โฟลเดอร์" มาสู่การบันทึก "ความจริงระดับอะตอม" แล้วปล่อยให้โครงสร้างงอกเงยจากการใช้งานจริง (Self-Organization) Event Sourcing & CQRS: เมื่อซอฟต์แวร์จำลองพฤติกรรมสมุดบัญชีธนาคาร บันทึกแค่เหตุการณ์ดิบ (Raw Events) ที่เกิดขึ้น แล้วค่อยนำข้อมูลมาจัดระเบียบเป็นหน้าตาใหม่ (Projection) ในอนาคต Stoic Architecture: ปรัชญาการยอมรับความไม่รู้ (Embrace Ignorance) และการปล่อยวางจากการพยายามควบคุมอนาคตที่เราควบคุมไม่ได้ "สถาปัตยกรรมที่ยั่งยืน ต้องเป็นสถาปัตยกรรมที่ยอมรับในความไม่รู้... ปล่อยให้โครงสร้างเติบโตจากพฤติกรรม อย่าให้พฤติกรรมถูกจำกัดด้วยโครงสร้างที่ตายตัว"

    สถาปัตยกรรมแบบเติบโตตามธรรมชาติ: ปรัชญา Write First, Organize Later ในโลกของโค้ด EP.36

  7. 6 Jul

    โศกนาฏกรรมของพื้นที่ส่วนกลาง: จัดการ Shared State อย่างไรไม่ให้ระบบและคนตีกันตาย EP.35

    ในโลกอุดมคติของ Microservices เราใฝ่ฝันถึงสถาปัตยกรรมที่ทุกทีมและทุกเซอร์วิสมีฐานข้อมูลแยกขาดจากกัน (Stateless) แต่โลกความเป็นจริงไม่เคยง่ายดายเช่นนั้น... ธุรกิจล้วนมี "จุดตัด" ที่ต้องใช้ทรัพยากรร่วมกันเสมอ และจุดตัดนั้นคือบอสใหญ่ที่สร้างความปวดหัวให้กับทุกคน นั่นคือ “Shared State” จะเกิดอะไรขึ้นถ้าระบบ Sharing Grocery ในชุมชน มีคน 3 คนพุ่งเข้ามากดแย่ง "กะหล่ำปลีออร์แกนิก 1 หัวสุดท้าย" ในเสี้ยววินาทีเดียวกัน? หากระบบขาดกลไกควบคุมที่รัดกุม ความโกลาหลที่เรียกว่า Race Condition จะบังเกิด และระบบจะโกหกเราด้วยการเสกกะหล่ำปลีทิพย์ขึ้นมา! EP.35 นี้ ลุงควิน และ คุณเมย์ (Senior PM) จะพาไปสำรวจวิธีกำราบโศกนาฏกรรมของพื้นที่สาธารณะ (The Tragedy of the Commons) ในโลกของโค้ด ผ่านเลนส์ปรัชญาการจัดระเบียบอำนาจของ Michel Foucault ผสานกับเทคนิคขั้นสุดยอดจาก Systems Programming 📌 สิ่งที่คุณจะได้เรียนรู้จากตอนนี้: The Illusion of Stateless: ทำไมระบบซอฟต์แวร์ที่แท้จริงถึงหลีกเลี่ยง Shared State ไม่ได้ และเคสศึกษาความพังพินาศจาก Race Condition คุก Panopticon กับ Mutex: การประยุกต์ใช้แนวคิดหอคอยจัดระเบียบของ Foucault มาอธิบายกลไกการล็อกบัตรคิวในภาษา Rust เพื่อเปลี่ยนความโกลาหลให้เป็นระเบียบแถวเรียงเดี่ยว พิสูจน์ความจริงด้วย Type System: ก้าวไปอีกขั้นด้วยการฝัง "อุปนัยเชิงคณิตศาสตร์" (Mathematical Induction) ลงใน Scala เพื่อบังคับให้ Compiler พิสูจน์ความถูกต้องของการเปลี่ยนสถานะตั้งแต่ก่อนรันโปรแกรม Stoic Architecture: ปรัชญาการปล่อยวางสิ่งที่เราควบคุมไม่ได้ (Shared State ภายนอก) และหันกลับมาสร้างปราการที่แข็งแกร่งที่สุดให้กับสิ่งที่เราควบคุมได้ (Local State) "วาทกรรมคือตัวกำหนดความจริง... ในโลกของซอฟต์แวร์ Type System ที่ถูกออกแบบอย่างรัดกุมด้วยคณิตศาสตร์ คือวาทกรรมที่ทรงพลังที่สุดในการสร้างระบอบแห่งความจริงที่เชื่อถือได้"

    โศกนาฏกรรมของพื้นที่ส่วนกลาง: จัดการ Shared State อย่างไรไม่ให้ระบบและคนตีกันตาย EP.35

  8. 30 Jun

    ใครคือเจ้าของความจริง? ถอดรหัส Ownership และอำนาจของข้อมูลในระบบที่กระจัดกระจาย (Shared State in Squads) EP.34

    ต่อท่อ API กันเสร็จแล้ว... แต่ปัญหาใหม่ที่ชวนปวดหัวระดับมหากาพย์คือ "แล้วตกลงข้อมูลก้อนนี้ ใครเป็นเจ้าของ?" เมื่อระบบถูกจับแยกย่อยเป็น Squads แบบ Microservices แต่ดันมี Shared State (ข้อมูลส่วนกลาง เช่น โปรไฟล์ลูกค้า หรือ สถานะตะกร้าสินค้า) ที่ทุกทีมอยากรุมเข้ามาอ่านและเขียนพร้อม ๆ กัน จนเกิดปัญหาข้อมูลตีกัน (Race Condition) และลงเอยด้วย "โศกนาฏกรรมของพื้นที่สาธารณะ (The Tragedy of the Commons)" ที่พอระบบพังก็ไม่มีใครยอมรับเป็นเจ้าภาพ! EP.34 นี้ ลุงควิน และ คุณเมย์ (Senior PM) จะพาคุณไปถอดรหัสการจัดการ "ความจริง" ในองค์กร โดยผสานโลกของสถาปัตยกรรมซอฟต์แวร์ระดับลึก (Systems Programming) เข้ากับปรัชญาสังคมวิทยาอย่างคาดไม่ถึง 📌 สิ่งที่คุณจะได้เรียนรู้จากตอนนี้: The Tragedy of the Commons: ทำไมข้อมูลที่ "ทุกคน" เป็นเจ้าของ ถึงกลายเป็นข้อมูลที่ "ไม่มีใคร" ดูแล Rust Philosophy: การประยุกต์ใช้กฎ Ownership (ความเป็นเจ้าของ) และ Borrowing (การยืม) จากภาษา Rust มาใช้จัดการโครงสร้างทีม เพื่อฟันธงว่าใครคือ Source of Truth เพียงหนึ่งเดียว Power / Knowledge: เลนส์ปรัชญาของ Michel Foucault เมื่อ "ใครถือข้อมูล คนนั้นถืออำนาจ" ทำไมแต่ละทีมถึงชอบแอบก๊อปปี้ข้อมูลไปสร้างเอง และเราจะจัดการการแย่งชิงอำนาจนี้อย่างไร Bounded Context: วิธีใช้ Domain-Driven Design (DDD) ตีกรอบขอบเขตความรับผิดชอบ ไม่ให้ก้าวก่ายตรรกะของทีมอื่น "ควบคุมโค้ดในมือคุณ แต่อย่าพยายามครอบครองความจริงที่ไม่ได้อยู่ในขอบเขตของคุณ"

    ใครคือเจ้าของความจริง? ถอดรหัส Ownership และอำนาจของข้อมูลในระบบที่กระจัดกระจาย (Shared State in Squads) EP.34
See All (41)

About

Software & Developer Podcast

Information

  • Creator
    PlanktonSoft
  • Years Active
    2026
  • Episodes
    41
  • Rating
    Clean
  • Copyright
    © PlanktonSoft
  • Show Website
    UncleQuin