The 12 Foundations

ตอนไป Odd-e Gathering ที่ผ่านมา ทุกวันก็จะเป็น Open Space ที่พวกเราได้แบ่งปันความรู้กัน ทั้งเรื่องการโค้ชและการทำ Software หลังจากทานข้าวเย็นเสร็จ เราก็ไปดื่มกันต่อที่บาร์ใต้โรงแรม แล้ว Terry Yin ก็ได้แบ่งปันเรื่อง The 12

Distributed Decision Making

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

Risk Management: The Hard Test

ท้ายหนังสือ Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency ของ Tom DeMarco ได้ให้เทคนิคใหม่ในการจัดการความเสี่ยงกับผม ทอมสอนว่าในการทำงานยุคปัจจุบัน งานมีความเสี่ยงกระจายอยู่เต็มไปหมด ซึ่งในความเสี่ยงนั้น เรามีโอกาสโชคดีและมีโอกาสโชคร้าย การจัดการความเสี่ยงเป็นสิ

วิธีปรับเวลาการนอน

ผมเดินทางกลับมาจาก Conference ของ Berkeley ที่ซานฟรานซิสโก เครื่องลงที่สนามบินสุวรรณภูมิประมาณ 22:30 น. กว่าจะถึงบ้านก็เกือบเที่ยงคืน ยังดีที่ขากลับไม่เหนื่อยเท่าขาไป เพราะลองซื้อหมอนรองคอจาก Duty Free ที่ซานฟรานซิสโกมาใช้ดู หมอนเป็นลายการ์ตูน มีรูปสะพาน

เร็วแค่ไหนก็ไร้ค่า ถ้าไปผิดทาง

อีกบทเรียนที่ผมได้จากหนังสือ Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency ของ Tom DeMarco คือ ทำไมองค์กรใหญ่ ๆ ถึงยึดมั่นกับ Efficiency กันนัก Efficiency คืออะไร? Efficiency แปลว่า "ประสิทธิภาพ" ยกตัวอย่างเช่น

กฎของจั๊วะ

ปีนี้ที่อายุ 44 ผม Reflect ตัวเอง และพบว่าหลักการใช้ชีวิตของผมได้มาจากหนังสือ The Seven Habits of Highly Effective People เยอะมาก ใน Habit ทั้ง 7 นี้จะมีเกร็ดเล็กเกร็ดน้อยที่ผมไปศึกษามา แล้วค่อย ๆ เติมเข้าไปเพื่อทำให้ Habit นั

วงจรชีวิตในมุมมอง Existentialism และศิลปะแห่งการล้มเหลวในราคาถูก

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

วนเวียนแต่ไม่วนลูป: เมื่อชีวิตคือฟังก์ชัน Recursion และการเดินทางสู่พื้นที่ปลอดภัย

ในโลกที่หมุนไปด้วยอัตราเร่งอย่างทุกวันนี้ หลายครั้งเรามักพบว่าตัวเองติดอยู่ท่ามกลางความสับสนยุ่งเหยิง ปัญหาบางอย่างในชีวิตไม่ได้มาในรูปแบบที่เรียบง่าย แต่กลับซ้อนทับกันเป็นชั้น ๆ เหมือนกล่องของขวัญใบยักษ์ที่พอเปิดเข้าไป ก็

ขยายกิจการองค์กร

อีกบทเรียนที่ผมได้จากหนังสือ Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency ของ Tom DeMarco คือมุมมองใหม่สำหรับการเติบโตของบริษัท ตลอดมา ผมมักจะต่อต้านการแก้ปัญหางานไม่ทันด้วยการเพิ่มคน เพราะการเพิ่มคนเป็นกลยุทธ์ระดับองค์กร แต่งานไม่ทั

เมื่อ “Rewrite” เอาไม่อยู่: ถึงเวลาที่ซอฟต์แวร์สถาปนิกต้อง “Rework”

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

Fundamental of Software Architecture: Architecture คือศิลปะของการตัดสินใจที่ทำให้ระบบอยู่ต่อได้

ขอจดโน๊ตที่ไปเรียนวิชา Fundamental of Software Architecture กับพี่รูฟมาค่ะ นี่แค่ day1 555555+ คำว่า Architecture ไม่ได้เริ่มต้นจากโลกของซอฟต์แวร์ แต่มีรากมาจากโลกของการก่อสร้าง เมือง อาคาร และ civil engineering มายาวนานมาก ก่อนที่เราจะเอาคำนี้มาใช้กับ software architecture ในภายหลัง สิ

จากห้องทำงานของนักปรัชญา สู่หน้าจอของ Developer: เมื่อแนวคิด Kierkegaard ปลดล็อกการพัฒนา Software

ลองจินตนาการถึงสถานการณ์ที่คุณกำลังเผชิญในโปรเจกต์ซอฟต์แวร์ปัจจุบัน: ทีมของคุณต้องการความเร็วเพื่อปล่อยฟีเจอร์ใหม่ให้ทันตลาด (Living Forward) แต่ในขณะเดียวกัน โค้ดเก่าที่เต็มไปด้วยหนี้ทางเทคนิค (Technical Debt) ก็กำลังฉุดรั้งให้ทุกอย่างช้

Software Engineering กับ Harness Engineering: 10x หรือ Technical Debt

ลองนึกภาพร้านก๋วยเตี๋ยวเจ้าเก่าที่ขายดีมา 20 ปี วันดีคืนดีพี่มาวินมารีวิวลง TikTok แล้วลูกค้าทะลักเข้ามา 10 เท่า เตาเดิม หม้อเดิม พนักงานเท่าเดิม แต่ Order เพิ่มเป็น 10 เท่า หัวข้อ

The Software Factory: เมื่อแคลคูลัสและสมการ s=vt ตัดสินความอยู่รอดของโปรเจกต์ซอฟต์แวร์

ในโลกของการบริหารโปรเจกต์ซอฟต์แวร์ เรามักจะหลงรักแผนงานที่สวยงามบนหน้าจอ เราตื่นตาตื่นใจกับ Gantt Chart ที่ลากเส้นต่อกันอย่างเป็นระเบียบ และเรามักจะทึกทักเอาเองว่า ถ้าเรามีจุดเริ่มต้นที่ดี มีทีมงานที่มีความเร็ว (Velocity) และมีระยะเวลาที่กำหนดไว้ ทุกอย่างจะเดินไปถึงเป้

Imperative กับ Declarative

ในโลกของการเขียนโปรแกรม มันจะมีคำว่า imperative กับ declarative มันคืออะไรแล้วมันทำให้การเขียนโปรแกรมของเราเปลี่ยนไปยังไง มาลองถอดบทเรียนกัน เริ่มจากแปลตรงๆ * Imperative (How): ต้องสั่งทีละขั้นตอนว่าต้องทำอย่างไร (เหมือนการบอกทางแบบละเอียด: เลี้ยวซ้าย 100 เมตร, เลี้ยวขวา...) * Declarative (What): บอกแค่ว่าผลลัพธ์

human resource

คนไม่ใช่สิ่งทดแทนกันได้ (People are not Fungible)

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

เมื่อ Rust’s Default Trait พบกับปรัชญา Essentialism

ในฐานะโปรแกรมเมอร์ เรามักหมกมุ่นอยู่กับการเปลี่ยนแปลง (Mutation) เราสนใจว่า State จะไหลจาก A ไป B อย่างไร แต่เรามักลืมตั้งคำถามที่สำคัญที่สุดคำถามหนึ่ง: “ก่อนที่สิ่งนี้จะกลายเป็นสิ่งนั้น… มัน ‘เป็น’ อะไรมาก่อน?” นี่ไม่ใช่แค่คำถามเชิงตรรกะ แต่มันคื

Specification

ทำไม System Analyst ถึงไม่เชื่อ Design จากทีม

บ่อยครั้งที่ผมได้ยินน้อง ๆ ออดส์ทีม (ODT) เล่าว่า งานที่ทำอยู่ไม่ท้าทายเลย เพราะเพียงได้รับ Specification มาจาก System Analyst (SA) หรือ Tech Lead ที่เป็นพนักงาน แล้วน้องก็มีหน้าที่เขียนโค้ดตามนั้นไปอย่างเดียว บ่อยครั้งที่น้องเห็นวิธีการที่ดีกว่าในการแก้ปัญหานี้ แต่พอเสนอไอเดียไปก็ไม่ได้รับการรับฟัง

อัตลักษณ์ที่ถูกพันธนาการ: เมื่อ Rust Closures สะท้อนตรรกะแห่งการครอบครอง

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

Test Scenario vs Test Case แยกไม่ออกสักที? มาดูตัวอย่างง่ายๆ กัน

QA Knowledge Series 5 นาทีกับบทความนี้ จะเปลี่ยนวิธีเขียน test document ของคุณไปตลอดกาล — เพราะ QA หลายคนเขียน Test Case ได้คล่อง แต่พอถามว่า Test Scenario คืออะไร ก็ตอบว่า "เหมือนกันนั่นแหละ" ถ้าคุณเคยถูกถามว่า "Test Scenario กั

You Are What You Implement: เมื่อ Traits นิยามตัวตนของ Object ผ่านปรัชญา Existentialism

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

The Stoic Programmer: เขียนโค้ดอย่างไรให้ใจไม่พัง

ในมหานครที่ฉาบด้วยแสงนีออนและความโกลาหลของข้อมูล เหล่าโปรแกรมเมอร์มักจะติดอยู่ในวงจรของการพยายามควบคุมสิ่งที่ควบคุมไม่ได้ เราภาวนาให้ Network ไม่ล่ม เราอ้อนวอนให้ User ใส่ Input ที่ถูกต้อง และเราเจ็บปวดเมื่อระบบ panic! พังทลายลงต่อหน้า แต่นักคิดสโตอิก (Stoic) เมื่อสองพันปีก่อนไม่

เมื่อ Rust อ่าน Foucault: การสถาปนา “ระบอบแห่งความจริง” ผ่าน Exclusive Reference

ในโลกของการเขียนโปรแกรม เรามักมองว่าภาษาเป็นเพียงเครื่องมือ (Tooling) แต่สำหรับผู้ที่คลุกคลีกับภาษา Rust จะรู้ดีว่าภาษานี้มี “ปรัชญา” บางอย่างที่ฝังรากลึกอยู่ภายใต้ไวยากรณ์ที่เคร่งครัด โดยเฉพาะเรื่องการจัดการหน่วยความจำที่ไม่ได้มองว่าเป็นแค่เรื่องทางเทคนิค แต่

The Borrowed Window: มายาแห่งการครอบครองในกรงขังของหน่วยความจำ

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