บทที่ 1: A Pragmatic Philosophy — ปรัชญาของนักปฏิบัติ

ภาพรวม

บทนี้วางรากฐานปรัชญาของการเป็นนักปฏิบัติ (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) — การบริหารพอร์ตความรู้ใช้หลักการเดียวกับการบริหารพอร์ตการเงิน:

เป้าหมายที่เป็นรูปธรรม:

• เรียนรู้ภาษา 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 อยู่แล้ว