Specification
บ่อยครั้งที่ผมได้ยินน้อง ๆ ออดส์ทีม (ODT) เล่าว่า งานที่ทำอยู่ไม่ท้าทายเลย เพราะเพียงได้รับ Specification มาจาก System Analyst (SA) หรือ Tech Lead ที่เป็นพนักงาน แล้วน้องก็มีหน้าที่เขียนโค้ดตามนั้นไปอย่างเดียว บ่อยครั้งที่น้องเห็นวิธีการที่ดีกว่าในการแก้ปัญหานี้ แต่พอเสนอไอเดียไปก็ไม่ได้รับการรับฟัง
ในโลกของ Rust “ความอิสระ” เป็นเพียงภาพลวงตา เพราะทุกการขยับเขยื้อนของข้อมูลล้วนมีพันธนาการที่เรียกว่า Ownership กำกับอยู่เสมอ หากเราเปรียบฟังก์ชันทั่วไปเป็นเหมือนคนแปลกหน้าที่เดินผ่านมาแล้วจากไป Closures ก็คงเป็นเหมือน “เงา” ที่ไม่ได้อยู่โดดเดี่ยว แต่มั
QA Knowledge Series 5 นาทีกับบทความนี้ จะเปลี่ยนวิธีเขียน test document ของคุณไปตลอดกาล — เพราะ QA หลายคนเขียน Test Case ได้คล่อง แต่พอถามว่า Test Scenario คืออะไร ก็ตอบว่า "เหมือนกันนั่นแหละ" ถ้าคุณเคยถูกถามว่า "Test Scenario กั
ในโลกของการเขียนซอฟต์แวร์ เรามักจะติดอยู่กับคำถามที่ว่า “วัตถุนี้คืออะไร?” และคำตอบส่วนใหญ่มักจะหนีไม่พ้นการมองหา “สายเลือด” หรือ Hierarchy ของมัน แต่ถ้าเราลองเปลี่ยนมุมมองจากการถามว่ามัน คือใคร มาเป็นการถามว่ามัน ทำอะไรได้ เราอาจจะพบทางออกของระบบที่ยืดหยุ่นและเป็นอิสระมากกว่าเดิ
ในมหานครที่ฉาบด้วยแสงนีออนและความโกลาหลของข้อมูล เหล่าโปรแกรมเมอร์มักจะติดอยู่ในวงจรของการพยายามควบคุมสิ่งที่ควบคุมไม่ได้ เราภาวนาให้ Network ไม่ล่ม เราอ้อนวอนให้ User ใส่ Input ที่ถูกต้อง และเราเจ็บปวดเมื่อระบบ panic! พังทลายลงต่อหน้า แต่นักคิดสโตอิก (Stoic) เมื่อสองพันปีก่อนไม่
ในโลกของการเขียนโปรแกรม เรามักมองว่าภาษาเป็นเพียงเครื่องมือ (Tooling) แต่สำหรับผู้ที่คลุกคลีกับภาษา Rust จะรู้ดีว่าภาษานี้มี “ปรัชญา” บางอย่างที่ฝังรากลึกอยู่ภายใต้ไวยากรณ์ที่เคร่งครัด โดยเฉพาะเรื่องการจัดการหน่วยความจำที่ไม่ได้มองว่าเป็นแค่เรื่องทางเทคนิค แต่
ในระเบียบอันเคร่งครัดของ Rust… การเป็นเจ้าของ (Ownership) คือพันธนาการ ข้อมูลทุกชุดต้องมีนายทาสที่คอยควบคุม และเมื่อสิ้นสุดอำนาจ ทุกอย่างจะถูกทำลายทิ้งอย่างไร้ความเมตตา แต่นี่คือความจริงที่โปรแกรมเมอร์ส่วนใหญ่หวาดกลัว: การครอบครองคือภาระ และยิ่งคุณถือครองมากเท่าไหร่
ในโลกของการเขียนโปรแกรม เรามักถูกสอนให้เป็น “นักจัดระเบียบ” เราสร้างคลาส สร้าง Struct ตั้งชื่อตัวแปรให้สื่อความหมาย (Clean Code) แต่บางครั้ง ความเคร่งครัดที่มากเกินไปอาจกลายเป็นพันธนาการที่ทำให้ Code ของเราอุ้ยอ้ายโดยไม่จำเป็น 1. Naming Fatigue: ภาระของการมีตัวตน ลองนึกภาพคุณได้
ในโลกของการพัฒนาซอฟต์แวร์ เรามักจะถูกสอนให้เป็นคนรอบคอบ ให้คิดถึงความเป็นไปได้ให้ครบทุกด้าน แต่บ่อยครั้งที่ “ความรอบคอบ” นั้นกลับกลายเป็นกับดักที่สร้างความซับซ้อนจนเราเองก็รับมือไม่ไหว วันนี้ผมอยากจะหยิบยกปรัชญาหนึ่งที่ผมพบจากการเขียนโปรแกรม โดยเฉพาะในภาษาอย่าง Rust ซึ่งมันไม่
ในโลกของการพัฒนาซอฟต์แวร์ เราถูกสอนให้เทิดทูน Logic เป็นพระเจ้า เราใช้เหตุผลในการคัดเลือก Stack, ใช้ความถูกต้องในการทำ Code Review และใช้ตัวเลขในการวาง Roadmap แต่เคยสงสัยไหมครับ? ทั้งที่เราพูดเรื่องที่ “ถูกต้อง” และเป็น “ความจริง” ทุกประการ ทำไมผลลัพธ์ในห้องประชุ
เนื่องจากช่วงนี้ได้ทำงานกับลูกค้าที่มีการเปลี่ยนแปลงทาง scope ของงานเยอะมาก อารมณ์แบบตอน baseline เป็นแบบนึง พอจะเลือกงานมาทำจริงๆ เรียกว่าเปลี่ยนไปตาม strategy ขององค์กรเลยก็ว่าได้ ในฐานะที่เราเป็นกลุ่มนักพัฒนา ที่ยังจำเป็นต้องควบคุมงบประมาณ กำหนด scope และต้องตอบให้ได้ว่า
slack
ผมกำลังอ่านหนังสือ Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency ของ Tom DeMarco ซึ่งได้ให้มุมมองใหม่เกี่ยวกับ Slack time หรือเวลาอู้งานกับผม แต่ก่อนจะเล่าว่าผมเห็นอะไร ผมของแบ่งปันมุมมองเวลาผมดูองค์กรก่อนนะ สายการผลิต คนในองค์กรมารวมตัวกันเพราะเราต้องการบรรลุเป้าหมายที