อย่ายัดเยียดความคิดตัวเองลงไปในงานลูกค้า

เวลาเราเก็บ requirement จากลูกค้ามา โปรแกรมเมอร์โบราณมักจะทำสิ่งที่เรียกว่า คิดเองเออเองเสมอว่าลูกค้าอยากได้อะไร พอทำบ่อย ๆ มันก็กลายเป็นมาตรฐานระหว่างลูกค้า กับโปรแกรมเมอร์ไป พอเป็นมาตรฐานกันบ่อย ๆ ก็จะตั้งชื่อเล่นเท่ ๆ ให้กับมาตรฐานที่ทึกทักกันขึ้นมาเองว่า common sense โดยตอนที่ทำงานกันหลาย ๆ คนเนี่ย ไอ้ common sense แต่ละคนมันไม่เคยจะเหมือนกัน

อย่าดูถูกตัวเองด้วยการลดคุณภาพของสิ่งที่ทำ

หลังจากที่ได้อ่านเรื่องของพี่โอเกี่ยวกับเบอร์เกอร์กระรอก ก็ทำให้นึกถึงเรื่องที่เคยคิดว่าจะจดไว้ในนี้ แต่ไม่ได้ทำสักที เริ่มเลยละกัน หลาย ๆ องค์กรมีทีม IT ที่คอยพัฒนาซอฟต์แวร์ให้ทั้งผู้ใช้ที่เป็นลูกค้าภายนอก รวมถึงผู้ใช้ที่เป็นพนักงานภายในบริษัทเอง โดยตั้งโจทย์แบบเดียวกันกับเรื่องของเบอร์เกอร์กระรอก คือ “จะเอาทั้งหมด” ภายใต้ resource ที่มีอยู่อย่าง “จำกัด” (คำว่า resource ในที่นี้ หมายถึง resource ทุกอย่าง ยกเว้น คน เพราะคนไม่ใช่ resource) ปัญหาที่ตามมาคือ การใช้ secret toolbox ไม่ว่าจะเป็นการสร้าง smell ลงไปในของที่ตัวเองทำ การไปก๊อปปี้โค้ดมาจากอินเตอร์เน็ตโดยไม่ได้สนใจว่ามันคืออะไร ทำงานยังไง การไม่ทำความเข้าใจโค้ดที่ทีมเขียนหรือไม่ทำให้โค้ดที่ตัวเองเขียนอ่านง่ายขึ้น และที่สำคัญคือ การไม่เขียนเทสต์

สร้าง LEMP stack ด้วย docker

อยากทำ dev environment สำหรับทำเว็บที่ไม่กระทบกับ environment ของเครื่องที่ใช้อยู่ โดยมีของที่อยากได้คือ linux, nginx, mariadb และ php (LEMP) จริง ๆ จะเป็น linux, apache, mysql และ php (LAMP) ก็ได้ แต่เอา nginx มาใช้แทนเพราะอยากหัดด้วย ส่วน mariadb เห็นว่า performance ดีกว่า mysql เลยเลือก mariadb ตั้งโจทย์ไว้แบบนี้เลยมอง ๆ เรื่องเอา docker มาใช้

เข้าใจเหตุและผลด้วย Causal Loop Diagram (CLD)

ในปัญหาที่มัน scale เล็ก ๆ เรื่องบางเรื่องอาจจะถูกอธิบายได้ง่าย ๆ ด้วยข้อความสั้น ๆ เช่น ถ้าเรามองแค่เรื่องผลกระทบระหว่างการทดสอบ software กับจำนวน defect ของ software มันก็จะเป็นอะไรที่ดูง่าย และตรงไปตรงมา คือ ถ้าการทดสอบ software มีมาก จำนวน defect ก็จะน้อย ถ้าเราทดสอบ software น้อย จำนวน defect ก็จะมาก แต่ในปัญหาเดียวกัน หากเรามองปัญหาใน scale ระดับใหญ่ขึ้นมาอีกหน่อย เราเริ่มเพิ่มตัวแปรที่เกี่ยวข้องลงไปในปัญหาให้มากขึ้น เช่น จำนวน feature, เวลา, จำนวน developer เราจะเริ่มเห็นผลกระทบที่ซับซ้อนมากขึ้น จนลำบากที่จะอธิบายด้วยคำพูดสั้น ๆ ให้เข้าใจได้ ทำให้การนำไปสื่อสารเพื่อให้คนอื่นเข้าใจเป็นไปได้ยากมากขึ้น หรืออาจจะเข้าใจผิด หรือตีความผิดได้ง่ายขึ้น

Brooks’s Law

ในบริบทการพัฒนาซอฟต์แวร์ที่ feature ถูกกำหนดไว้แล้ว (fixed scope) และเวลาที่จะต้องส่งมอบก็ถูกกำหนดไว้แล้ว (fixed time) หลาย ๆ องค์กรยังคิดว่า การเพิ่มคนลงใน software project จะช่วยให้ project เสร็จเร็วขึ้น หรือเสร็จทันเวลาได้ Fred Brooks กล่าวไว้ในหนังสือ The Mythical Man-Month เกี่ยวกับ Software Project Management ว่า “adding human resources to a late software project makes it later”

Retrospective ด้วย ORID

ORID เป็นกิจกรรมแบบหนึ่งที่คนที่ทำหน้าที่เป็น facilitator ใช้วิธีการพูดคุยในการดำเนินกิจกรรม ในกิจกรรมจะเป็นการตั้งคำถามให้ผู้เข้าร่วมกิจกรรมตอบผ่านคำถาม 4 คำถาม โดยทั้ง 4 คำถามจะเป็นคำถามที่นำไปสู่การตัดสินใจ (Decision Making) ของผู้เข้าร่วมกิจกรรม

Migrate jasmine ไปใช้ jest ใน Angular 6

อะกิมาบอกว่า jest น่าสนใจดีนะ จำได้ว่ามีคนเคยชวนไปใช้ jest แต่ตอนนั้นก็ยังไม่ได้สนใจอะไร ตอนนี้พอมีเวลาก็เลยมาลองซะหน่อย มี project ทดสอบอยู่ตัวนึงที่เอาไว้ใช้สอน robot คือ ng-calculator ซึ่งเดิมใช้ jasmine อยู่ เดี๋ยวจะมาลองเปลี่ยนเป็น jest ดู