ในโลกของการเขียนโปรแกรม เรามักถูกสอนให้เป็น “นักจัดระเบียบ” เราสร้างคลาส สร้าง Struct ตั้งชื่อตัวแปรให้สื่อความหมาย (Clean Code) แต่บางครั้ง ความเคร่งครัดที่มากเกินไปอาจกลายเป็นพันธนาการที่ทำให้ Code ของเราอุ้ยอ้ายโดยไม่จำเป็น 1. Naming Fatigue: ภาระของการมีตัวตน ลองนึกภาพคุณได้
ในโลกของการพัฒนาซอฟต์แวร์ เรามักจะถูกสอนให้เป็นคนรอบคอบ ให้คิดถึงความเป็นไปได้ให้ครบทุกด้าน แต่บ่อยครั้งที่ “ความรอบคอบ” นั้นกลับกลายเป็นกับดักที่สร้างความซับซ้อนจนเราเองก็รับมือไม่ไหว วันนี้ผมอยากจะหยิบยกปรัชญาหนึ่งที่ผมพบจากการเขียนโปรแกรม โดยเฉพาะในภาษาอย่าง Rust ซึ่งมันไม่
ในโลกของการพัฒนาซอฟต์แวร์ เราถูกสอนให้เทิดทูน Logic เป็นพระเจ้า เราใช้เหตุผลในการคัดเลือก Stack, ใช้ความถูกต้องในการทำ Code Review และใช้ตัวเลขในการวาง Roadmap แต่เคยสงสัยไหมครับ? ทั้งที่เราพูดเรื่องที่ “ถูกต้อง” และเป็น “ความจริง” ทุกประการ ทำไมผลลัพธ์ในห้องประชุ
เนื่องจากช่วงนี้ได้ทำงานกับลูกค้าที่มีการเปลี่ยนแปลงทาง scope ของงานเยอะมาก อารมณ์แบบตอน baseline เป็นแบบนึง พอจะเลือกงานมาทำจริงๆ เรียกว่าเปลี่ยนไปตาม strategy ขององค์กรเลยก็ว่าได้ ในฐานะที่เราเป็นกลุ่มนักพัฒนา ที่ยังจำเป็นต้องควบคุมงบประมาณ กำหนด scope และต้องตอบให้ได้ว่า
ผมกำลังอ่านหนังสือ Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency ของ Tom DeMarco ซึ่งได้ให้มุมมองใหม่เกี่ยวกับ Slack time หรือเวลาอู้งานกับผม แต่ก่อนจะเล่าว่าผมเห็นอะไร ผมของแบ่งปันมุมมองเวลาผมดูองค์กรก่อนนะ สายการผลิต คนในองค์กรมารวมตัวกันเพราะเราต้องการบรรลุเป้าหมายที
ในโลกของฟิสิกส์ มีกฎเหล็กข้อหนึ่งที่ไม่มีใครหนีพ้น ไม่ว่าจะเป็นดวงดาวที่ดับสูญ หรือกาแฟที่เย็นชืดลงในทุกเช้า กฎข้อนั้นคือ “กฎข้อที่สองของอุณหพลศาสตร์” (The Second Law of Thermodynamics) แต่รู้หรือไม่ว่า กฎข้อนี้ไม่ได้
บทสะท้อนวงการ Software Development ในฐานะ “เครื่องจักรผลิตของ” ในโรงงานอุตสาหกรรม เครื่องจักรถูกออกแบบมาเพื่อ “ผลิต” มันมีสายพาน มีฟันเฟือง มีชิ้นส่วน มีเซ็นเซอร์ ทุกอย่างมีหน้าที่ชัดเจน ถ้าชิ้นส่วนตัวหนึ่งพัง — ก็แค่ถอดออก แล้
สัญลักษณ์ที่เป็นที่นิยมสำหรับเต๋าคือสัญลักษณ์หยินหยาง เพราะในความมืดมีความสว่าง และในความสว่างก็มีความมืด ทำให้นึกถึงช่วงต้นของเต๋าบทที่สอง Under heaven all can see beauty as beauty only because there is ugliness. All can know good as good only because there is evil. Therefore having and not havi
พวกเราได้รับภาพนี้มาจากผู้มีพระคุณท่านหนึ่ง เธอแบ่งปันแรงบันดาลใจของภาพนี้ให้ผมทราบว่า ขวดแก้ว จากมุมของผู้ปกครองเป็นเหมือนกรอบที่วางเอาไว้เพื่อปกป้องหมีน้อยจากภยันตรายต่าง ๆ ภายนอก ขณะที่จากมุมของหมีน้อยมันเป็นเหมือนกรงขังไม่ให้เค้าออกไปโลดเล่นเก็บเกี่ยวประสบการณ์ ผมมองอิสรภาพและระเบียบวินัยเป็นแส
polarity คืออะไร? สิ่งหนึ่งที่ผมในฐานะสกรัมมาสเตอร์จะ observe คือ polarity polarity คือขั้วตรงข้าม ดุจ แสงและเงา, centralized และ decentralized, creative และ control, competitive และ collaborative ทุกขั้วมีโอกาสจะเป็นทั้งข้อดีและเสีย อะไรที่มากเกินไปจะไม่ยั่งยืน การ observe polarity เหมือนมองลูกต
ครั้งที่แล้วผมแบ่งปันไปว่าสิ่งหนึ่งที่ผมตอนเป็นสกรัมมาสเตอร์มองหาคือ polarity หรือขั้วตรงข้าม ซึ่งคู่แรกที่ผมแบ่งปันไปคือ ระเบียบ (control) และความสร้างสรรค์ (creative) วันนี้ผมตะมาแบ่งปันอีกรูปแบบหนึ่งของ 2 ขั้วนี้ที่เรียกว่า survive (อยู่รอดปลอดภัย) กับ thrive (เติบโต) ธรรมชาติของสมองมนุษย์จะสังเ
ท้ายหนังสือ Teamwork is an Individual Skill ของ Christopher Avery ได้กล่าวถึงสมการของสุดยอดทีมไว้ดังนี้ครับ Extraordinary Collaboration = Exchange + Expansion + Integrity ผมใช้เวลาอ่านตรงนี้ และอีก 3 บทที่ขยายความเรื่อง Exchange, Expansion และ Integrity อยู่เกือบ 2 สัปดาห์กว่าจะพอเข้าใจมันอย่างถ่อ
AI ไม่ได้ทำให้ Software ง่ายขึ้น มันแค่ทำให้เราเข้าสู่ช่วงที่ยากของ S-Curve เร็วขึ้น ในช่วงหลายปีที่ผ่านมา ตั้งแต่การเปิดตัวของ ChatGPT และเครื่องมืออย่าง GitHub Copilot หลายคนเริ่มพูดเหมือนกันว่า “ตอนนี้เขียน software ง่ายขึ้นมาก”
ความเป็นผู้นำในยุคนี้ไม่ใช่เรื่องของ "ตำแหน่ง" แต่เป็นเรื่องของ "การตอบสนองต่อการเปลี่ยนแปลง" Leadership is not about 'Change'—It’s about 'Adaptive' ในโลกที่ความผันผวนกลายเป็นเรื่องปกติ เรามักได้ยินคำแนะนำว่าผู้นำต้อง "Change" หรื
"Project นี้เราจะใช้ Spring Boot framework สำหรับ backend นะ..." บทสนทนาทั่วไปที่เราคงจะเคยได้ยินมาอยู่เป็นประจำ ไม่ว่าคุณจะเป็น frontend หรือ backend คำว่า framework ก็เป็นสิ่งที่ทุกคนนั้นพูดถึงอยู่เป็นประจำ Framework...Framework...Framework... – เป็นคำที่คนที่อยู่ในวงการ
ในภาษา Go การเขียน Higher-Order Functions (HOF) เริ่มมีความน่าสนใจและใช้งานได้กว้างขวางขึ้นมากหลังจากที่มี Generics (Go 1.18+) เข้ามา เพราะเราไม่ต้องเขียนฟังก์ชันแยกสำหรับทุก Type อีกต่อไป Higher-Order Functions ใน Go: ยกระดับโค้ดให้ยืดหยุ่นด้วย Generics ในภาษา Go
Polarity
ไล่ตามความฝัน กับ ดูแลตัวเอง ก่อนหน้านี้ผมเคยเล่าถึงขั้วตรงข้าม (Polarity) ระหว่างความคล่องตัวกับความสร้างสรรค์ไปแล้ว ครั้งนี้ผมมองว่า "การไล่ตามความฝัน" และ "การดูแลตัวเอง" (เปรียบเสมือน นักรบ กับ นักรัก)
Go เป็นภาษาที่ไม่สามารถทำ partial apply ได้โดยธรรมชาติ ... ทำให้ การลดรูป function ต่างๆให้มาเป็น unary function เป็นของแปลกสำหรับคนเขียน Go ฟังก์ชั่นของพวกเขาก็จะรับของเยอะและ compose ยาก ส่งผลให้ การทำ function composition เป็นเรื่องนอกกรอบมากสำหรับชาว Go - ส่วนผมนั้นสาย Mo Lang เป็นพวกทนไม่
เคยไหมครับ อ่านชื่อฟังก์ชันในโค้ด เห็น Input และ Output ดูปกติมาก แต่พอรันจริงกลับเจอ Runtime Error พ่นใส่หน้า หรือเจอ Null โผล่มาแบบไม่ได้รับเชิญ ทั้งที่ Type ไม่ได้บอกไว้... ในโลกของ Functional Programming (FP) เรามีเป้าหมายอย่
ผมได้รู้จัก Principle นี้ตอนศึกษาเรื่อง Type System และเร็วๆ นี้เพิ่งเห็นน้องในทีมนำ Library ที่ใช้แนวคิดนี้มาใช้ แต่พอเราไม่เข้าใจหลักการเบื้องหลัง (Core Principle) การนำไปใช้งานเลยติดขัดและเกิดปัญหาตามมา เลยคิดว่าน่าจะหยิบเรื่องนี้มาเล่าให้ฟังกั
Automation ไม่ได้เริ่มจาก budget แต่มันเริ่มจาก ‘ความเจ็บ’ ที่ทีมทนไม่ไหวอีกต่อไป” ลองถามทีมคุณตรงๆ: * regression ใช้กี่วัน? * ก่อน release ต้องใช้คนกี่คน? * bug หลุด production กี่ครั้ง? แล้วลองมองภาพนี้: ทีมใช้เวลา 3 วันเพื่อ regression
เมื่อก่อนผมเขียน Go เยอะมาก มันเป็นภาษาที่ดีและเรียบง่าย เริ่มง่าย ศึกษาง่าย ผมมักพูดเสมอว่า Go มันเหมือนมีดทำกับข้าวของจีนที่เรียบง่ายและทรงพลัง อย่างไรก็ตามหลังจากเขียนไปนานก็พบว่า ทำไมมันน่าเบื่อจัง ยิ่งเขียนยิ
scrum
กระบวนการแก้ปัญหาในโลกแบ่งเป็น 2 แบบ แบบแรกคือ Defined process ซึ่งเป็นกระบวนการที่มีขั้นมีตอนชัดเจน เช่น Waterfall เป็นต้น ส่วนแบบที่สองคือ Empirical process หรือ "กระบวนการเชิงประจักษ์" ซึ่งเป็นการทำไปแล้วก็ปรับไปเรื่อย ๆ สกรัมเป็นแบบหลัง
น้อง ๆ ที่ทำงานถามกับผมว่า “ทำไมพี่นิ่งจัง” “พี่ดูใจเย็น” ทั้ง ๆ ที่สถานการณ์เหมือนไฟกำลังจะครอกจนขาดอากาศหายใจกันอยู่แล้ว การสื่อสาร และการเชื่อมต่อส่วนประกอบต่าง ๆ บิดเบี้ยว การจัดการระบบที่ยุ่งเหยิง ทำให้ทุกสิ่งทุกอย่างวุ่นวายจนเกินจะควบคุ