บทที่ 1: A Pragmatic Philosophy (ปรัชญาของนักปฏิบัติ)
3 min readภาพรวม
บทนี้วางรากฐานปรัชญาของการเป็นนักปฏิบัติ (Pragmatic Programmer) มันเริ่มต้นที่ตัวคุณเองและทัศนคติของคุณต่องาน ครอบคลุม 7 หัวข้อ ตั้งแต่การรับผิดชอบชีวิตการทำงานของตัวเอง ไปจนถึงการสื่อสารกับผู้อื่น
Topic 1: It's Your Life (มันคือชีวิตของคุณ)
Tip 3: You Have Agency: คุณมีอำนาจในการเปลี่ยนแปลง
นักพัฒนาหลายคนรู้สึกหงุดหงิดกับงาน (รู้สึกชะงักงัน เทคโนโลยีทิ้งห่าง รู้สึกไม่ได้รับการยอมรับ หรือทีมเป็นพิษ) คำตอบของ Dave และ Andy เหมือนกันทุกครั้ง: "แล้วทำไมคุณไม่เปลี่ยนมันล่ะ?" อาชีพซอฟต์แวร์เป็นหนึ่งในอาชีพที่คุณควบคุมได้มากที่สุด (ทักษะเป็นที่ต้องการ ข้ามพรมแดนได้ ทำงาน remote ได้) หรือดังที่ Martin Fowler กล่าวว่า "you can change your organization or change your organization"
Topic 2: The Cat Ate My Source Code (ความรับผิดชอบ)
Tip 4: Provide Options, Don't Make Lame Excuses: เสนอทางเลือก อย่าแก้ตัว
หัวใจของปรัชญานักปฏิบัติคือการรับผิดชอบต่อตนเองและการกระทำ (ยอมรับความไม่รู้และความผิดพลาด) ความเชื่อใจในทีม (team trust) เป็นสิ่งจำเป็นสำหรับความคิดสร้างสรรค์และการทำงานร่วมกัน เมื่อคุณทำผิด จงยอมรับอย่างตรงไปตรงมาและเสนอทางออก (อย่าโทษ vendor ภาษา programming ผู้บริหาร หรือเพื่อนร่วมงาน) จงเสนอทางเลือกแทนการแก้ตัว
Topic 3: Software Entropy (เอนโทรปีของซอฟต์แวร์)
Tip 5: Don't Live with Broken Windows: อย่าอยู่กับหน้าต่างที่แตก
ปรากฏการณ์ Broken Window Theory: หน้าต่างที่แตกแล้วไม่ได้รับการซ่อมทำให้คนรู้สึกว่าถูกทอดทิ้ง และนำไปสู่ความเสื่อมโทรมมากขึ้นเรื่อย ๆ ในซอฟต์แวร์ "หน้าต่างแตก" คือ bad design, wrong decision, หรือ poor code (ถ้าไม่มีเวลาซ่อมอย่างถูกวิธี อย่างน้อยก็ "ปิดทับ" ไว้ก่อน เช่น comment out, แสดง "Not Implemented", ใช้ dummy data) อย่าปล่อยให้เอนโทรปีชนะ
หลักการสำคัญ: First, Do No Harm (อย่าสร้างความเสียหายเพิ่มแม้ในยามวิกฤต)
Topic 4: Stone Soup and Boiled Frogs (ซุปหินและกบต้ม)
Tip 6: Be a Catalyst for Change: เป็นตัวเร่งปฏิกิริยาการเปลี่ยนแปลง
Tip 7: Remember the Big Picture: จำภาพรวมไว้เสมอ
นิทานเรื่องซุปหินสอนว่า บางครั้งแทนที่จะขอ permission ทำโครงการใหญ่ทั้งหมด (ให้เริ่มจากสิ่งเล็ก ๆ ที่ขอได้) พัฒนามันให้ดี แล้วให้คนเห็นผลลัพธ์ พวกเขาจะเริ่มขอให้คุณเพิ่มฟีเจอร์ที่คุณอยากทำตั้งแต่แรกเอง ("It's easier to ask forgiveness than it is to get permission")
ในทางกลับกัน เรื่องกบต้มสอนว่า การเปลี่ยนแปลงแบบค่อยเป็นค่อยไป (gradual change) อาจทำให้เราไม่ทันสังเกตว่าสิ่งต่าง ๆ กำลังแย่ลง (อย่าเป็นเหมือนกบที่ถูกต้มโดยไม่รู้ตัว) คอยมองภาพรวมเสมอ
Topic 5: Good-Enough Software (ซอฟต์แวร์ที่ดีพอ)
Tip 8: Make Quality a Requirements Issue: ทำให้คุณภาพเป็นส่วนหนึ่งของ requirements
"Good enough" ไม่ได้หมายถึง sloppy หรือ poor code (แต่หมายถึงการให้ผู้ใช้มีส่วนร่วมในการตัดสินใจว่าซอฟต์แวร์ "ดีพอ" สำหรับความต้องการของพวกเขาหรือยัง) บางครั้งซอฟต์แวร์ที่มี rough edges วันนี้ก็ดีกว่าซอฟต์แวร์สมบูรณ์แบบในอีกหนึ่งปี (และรู้ว่าเมื่อไหร่ควรหยุด) เช่นเดียวกับการวาดภาพ ถ้าเพิ่มสีไปเรื่อย ๆ ภาพจะจมอยู่ในสี
Topic 6: Your Knowledge Portfolio (พอร์ตความรู้ของคุณ)
Tip 9: Invest Regularly in Your Knowledge Portfolio: ลงทุนในพอร์ตความรู้อย่างสม่ำเสมอ
Tip 10: Critically Analyze What You Read and Hear: วิเคราะห์สิ่งที่คุณอ่านและได้ยินอย่างมีวิจารณญาณ
ความรู้เป็นสินทรัพย์ที่เสื่อมค่าได้ (expiring asset) การบริหารพอร์ตความรู้ใช้หลักการเดียวกับการบริหารพอร์ตการเงิน:
| หลักการ | การนำไปใช้ |
|---|---|
| ลงทุนสม่ำเสมอ | เรียนอย่างน้อยหนึ่งภาษาใหม่ต่อปี, อ่านหนังสือเทคนิคอย่างน้อยเดือนละเล่ม |
| กระจายความเสี่ยง | อย่าติดอยู่กับเทคโนโลยีเดียว (เรียนรู้ทั้ง frontend, backend, database, DevOps) |
| สมดุล conservative/high-risk | เรียนรู้ทั้งเทคโนโลยีที่ stable และ emerging tech |
| ซื้อถูกขายแพง | เรียนรู้เทคโนโลยีใหม่ก่อนมันจะเป็นที่นิยม |
| ทบทวนและปรับสมดุล | ทบทวนพอร์ตความรู้เป็นระยะ (อะไรที่เคย hot อาจเย็นแล้ว) |
เป้าหมายที่เป็นรูปธรรม:
- เรียนรู้ภาษา programming ใหม่อย่างน้อย 1 ภาษาต่อปี
- อ่านหนังสือเทคนิคเดือนละ 1 เล่ม
- อ่านหนังสือที่ไม่ใช่เทคนิคด้วย (คนเขียนโค้ดให้คนใช้)
- เข้าคอร์สเรียน หรือ participate ใน user groups และ meetups
- ทดลอง environment ที่แตกต่าง
- ติดตามข่าวสารเทคโนโลยีอยู่เสมอ
Critical Thinking: ตั้งคำถามกับทุกสิ่งที่คุณอ่าน (ใช้เทคนิค "Five Whys") ถาม "ใครได้ประโยชน์?" "บริบทคืออะไร?" "มันจะใช้ได้เมื่อไหร่/ที่ไหน?" "ทำไมมันถึงเป็นปัญหา?"
Topic 7: Communicate! (สื่อสาร!)
Tip 11: English is Just Another Programming Language
Tip 12: It's Both What You Say and the Way You Say It
Tip 13: Build Documentation In, Don't Bolt It On
ความคิดที่ดีที่สุด โค้ดที่ดีที่สุด ไร้ค่าถ้าคุณสื่อสารไม่เป็น (ใช้เวลาส่วนใหญ่ในแต่ละวันไปกับการสื่อสาร) ดังนั้นต้องทำมันให้ดี
หลักการสื่อสาร:
- Know Your Audience: ปรับเนื้อหาให้เหมาะกับผู้ฟัง (สิ่งที่ developer สนใจอาจไม่ใช่สิ่งที่ VP การตลาดสนใจ)
- Know What You Want to Say: วางแผนก่อนเขียน (ร่าง outline ก่อนเริ่ม)
- Choose Your Moment: เลือกจังหวะเวลาที่เหมาะสม
- Choose a Style: ปรับสไตล์ให้เหมาะกับผู้ฟัง (บางคนชอบ "just the facts" บางคนชอบสนทนายาว ๆ)
- Make It Look Good: เอกสารที่ดีต้องดูดีด้วย (ใช้ style sheets, ตรวจคำผิด)
- Involve Your Audience: ให้ผู้อ่านมีส่วนร่วมกับร่างแรก (รับ feedback)
- Be a Listener: ถ้าอยากให้คนอื่นฟังคุณ คุณต้องฟังเขาก่อน
- Get Back to People: ตอบกลับอีเมลและข้อความเสมอ (แม้จะเป็นแค่ "เดี๋ยวตอบกลับนะ")
Documentation: อย่าทำ documentation แยกจากโค้ด (build เข้าไปในโค้ดเลย) ความคิดเห็นในโค้ดควรอธิบาย why ไม่ใช่ how (เพราะโค้ดบอก how อยู่แล้ว)