The Pragmatic programmer: Philosophy

อะไรทำให้ pragmatic programmer โดดเด่นจากโปรแกรมเมอร์ทั่ว ๆ ไป???

1. วิธีการรับมือกับปัญหาและการทางออก

เหล่า pragmatic programmer จะมองปัญหาในภาพกว้างและปรับเปลี่ยนวิธีการรับมือเพื่อผลลัพธ์ในภาพใหญ่

2. ความรับผิดชอบต่องานทุกสิ่งที่เขาทำ

ไม่ว่าจะเป็นความรับผิดชอบต่อตัวงานเอง ความรับผิดชอบต่อความก้าวหน้าทางสายอาชีพหรือความรับผิดชอบต่อความผิดพลาดของตัวเอง และเมื่อถึงเวลาที่ต้องตัดสินใจว่าจะรับผิดชอบเรื่องใด

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

Provide Options, Don't make lame excuses

ก่อนที่จะบอกใครในทีมหรือหัวหน้าว่าอะไรทำไม่ได้ ให้ใตร่ตรองดูก่อนว่าเราพอจะทำอะไรได้ไหมหรือลองหาทางเลือกที่ 1,2,3 เผื่อไว้แล้วหรือยัง

รับผิดชอบต่อ code ตัวเอง

ตามกฎของจักรวาลแล้ว entropy ของระบบปิดมักจะเพิ่มขึ้นเองตามธรรมชาติ — ซึ่ง software ที่เราผลิตกันก็ไม่อาจจะหลีกหนีกฎจักรวาลข้อนี้ไปได้ entropy เป็น term ในฟิสิกส์ที่ใช้อธิบายความผิดปรกติในระบบใดระบบนึง ซึ่งพอเอามาใช้อธิบายในแง่ของ software development แล้วก็น่าจะหมายถึงความพังพินาศของ code นั่นเอง จะพินาศเร็วหรือช้าก็มีหลาย factor ที่ทำให้เกิดขึ้น

หลายคนน่าจะคุ้นกับคำว่า technical debt ซึ่งเหล่า programmer เกลียด แต่ business ไม่เคยเข้าจายยย สิ่งที่ทำให้มันเกิดขึ้นจริง ๆ แล้วนอกจาก เวลาไม่เคยพอ มันคือจิตวิทยาในการทำงานของเรานั่นเอง ในหลาย ๆ โปรเจ็คแม้ว่าเหล่า programmer สุดเทพจะนั่งทำงานอยู่คนเดียวแต่เจ้า technical debt มันก็ยังเกิดขึ้นได้ นับประสาอะไรกับการทำงานเป็นทีมกันหลาย ๆ คน

หนังสืออธิบายว่าหลักใหญ่ที่ทำให้ technical debt บานปลายคือเราไม่ยอมที่จะจัดการกับมันตั้งแต่ที่มันเพิ่งเริ่มก่อตัว เมื่อเวลาผ่านไปก็ไม่มีใครอยากจะเข้าไปยุ่งกับมัน พอถึงจุดนึงมันก็จะพาเพื่อนมาด้วยและอีกไม่นานหลังจากนี้ความพินาศก็จะเกิดขึ้นอย่างรวดเร็ว จะแก้ทีก็ยากเย็นเหลือเกิน งั้นรื้อทำใหม่มันทั้งหมดเลยแล้วกัน

Don't leave with broken windows

ในทางตรงกันข้ามถ้า code ของเราคุณภาพดี การทำผิดให้ code เริ่มแย่แม้เพิ่งนิดหน่อยจะทำให้เรารู้สึกแย่และอยากแก้ให้ code ที่มีอยู่ดูดีอยู่เสมอนั่นเอง

3. เป็นตัวจุดประกายความเปลี่ยนแปลงในทีม

หลายครั้งที่การเปลี่ยนแปลงใหญ่ ๆ ไม่ได้เกิดจากการที่เปลี่ยนแบบพลิกหน้ามือเป็นหลังมือ แต่เกิดจากการเปลี่ยนแปลงสิ่งเล็ก ๆ หลาย ๆ อย่างรวมเข้าด้วยกัน ในการทำงานเป็นทีมก็เช่นเดียวกันเราอาจจะไม่สามารถโน้มน้าวคนทั้งทีมให้เห็นในแบบเดียวกันกับเราได้ แต่เราสามารที่จะเริ่มต้น การเปลี่ยนแปลงเล็ก ๆ น้อย ๆ ค่อย ๆ ปล่อยของ ถ้ามันดีจริงคนในทีมจะเริ่มเห็นดีเห็นงามกับสิ่งที่เราทำและค่อย ๆ เข้ามา contribute เพราะคนส่วนใหญ่ไม่ชอบที่จะเริ่มอะไรแต่ชอบที่จะชอบเข้ามามีส่วนร่วมเมื่อเห็นควมสำเร็จ

Be a Catalyst for change

4. เข้าใจภาพใหญ่ของงานที่ทำ

บางทีการที่เราสนใจแค่งานตรงหน้าที่ทำเพียงอย่างเดียวก็อาจจะออกทะเลได้ หลายครั้งที่เหล่าโปรแกรมเมอร์ทำงานตามใบสั่งโดยที่ไม่ได้สนใจ context รอบ ๆ เลย สุดท้าย requirement จาก requirement owner ต้นทางให้มาเขียนมาอย่างนึง PM/SA/BA/xxx พาไปออกอีกทางนึงแบบนี้ก็มี ถึงแม้จะไม่ใช่งานที่เหล่าโปรแกรมเมอร์ต้องรับผิดชอบโดยตรง แต่การเข้าใจงานที่ทำในภาพกว้างจะช่วยให้เราสามารถเข้าใจถึงปัญหาที่แท้จริงที่เราต้องการจะแก้ได้ นอกจากจะช่วยเรื่องการออกแบบระบบให้ครอบคลุม หากเห็นว่าเริ่มออกทะเลกันจะได้ เอ๊ะ แล้วถามคำถามเพิ่มได้

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

Your code will never be perfected, pragmaticsm over perfection

5. มีความรู้ที่หลากหลายเกี่ยวกับงานที่ทำ

Invest regularly in your knowledge portfolio

เราอยู่ในวงการที่ทุกอย่างหมุนเร็วมาก เราก็ต้องวิ่งกันหน่อยยยยย เรียนมันเข้าไปปปปป แต่จะเรียนยังไง ต้องมาดู

1. Invest Regularly — เรียนมันเข้าไป เรียนให้เป็นนิสัย
2. Diversify — เรียนให้หลากหลายเหมือลงทุนต้องถัวให้ครบทุก asset class
3. Manage Risk — technology ทุกตัวมีเวลาของมัน บางตัวมาไวไปไว เลือกให้ดี ๆ
4. Buylow, sell high — ยิ่งรู้ก่อนยิ่งได้เปรียบแต่ต้องดู trend อนาคตด้วยนะ
5. Review and rebalance — ของบางอย่างเรียนมาเพื่อลืม แต่บางอย่างลืมไม่ได้อันไหนต้องใช้แต่เริ่มเลือนลางก็ทวนบ้าง