PlusMagi's Blog By Pitt Phunsanit Database Specificity & Sincerity (ความเฉพาะเจาะจงและเจตนาที่จริงใจ ไม่ชมแบบเหมาเข่ง)

Specificity & Sincerity (ความเฉพาะเจาะจงและเจตนาที่จริงใจ ไม่ชมแบบเหมาเข่ง)

ในโลกของการพัฒนาซอฟต์แวร์และการทำงานร่วมกัน (Collaboration) การให้คำแนะนำหรือการให้ Feedback ที่มีคุณภาพเป็นทักษะที่สำคัญอย่างยิ่ง แต่บ่อยครั้งที่เราติดอยู่ในกับดักของการสื่อสารที่กว้างเกินไป หรือการวิจารณ์แบบ ‘เหมาเข่ง’ ว่า ‘โค้ดส่วนนี้มันไม่ดี’ ซึ่งคำพูดเหล่านี้ขาดน้ำหนักและไม่สามารถนำไปพัฒนาต่อได้

การสื่อสารที่มีประสิทธิภาพจึงไม่ใช่แค่การพูดให้ไพเราะ แต่คือการถ่ายทอดสิ่งที่สังเกตเห็นอย่างลึกซึ้งและเจาะจง เหมือนกับการเขียนคำสั่ง SQL ที่แม่นยำและมีประสิทธิภาพ การเรียนรู้หลักการ ‘ความเฉพาะเจาะจง’ (Specificity) และ ‘เจตนาที่จริงใจ’ (Sincerity) จะช่วยให้ Feedback ของคุณทรงพลังและสร้างสรรค์ขึ้นได้

💡 Specificity & Sincerity: หลักการสื่อสารที่เทียบเท่ากับ SQL ที่แม่นยำ

ในบริบทของ PostgreSQL หรือการทำงานด้าน Data Engineering, เราสามารถเปรียบเทียบหลักการนี้ได้ดังนี้:

🎯 1. Specificity (ความเฉพาะเจาะจง): ชี้เป้าให้ถูกจุด

การให้ Feedback ที่เฉพาะเจาะจงคือการชี้ให้เห็นถึงองค์ประกอบใดองค์ประกอบหนึ่งที่โดดเด่นอย่างชัดเจน ไม่ใช่การกล่าวลอย ๆ ว่า ‘ระบบนี้ช้า’ แต่ต้องเจาะจงไปที่สาเหตุ เช่น ‘การ Join ระหว่างตาราง A และ B โดยที่ไม่มี Index บนคอลัมน์ `user_id` ทำให้เกิด Bottleneck ในการ Query นี้’

ตัวอย่างการเปรียบเทียบใน PostgreSQL:

❌ Feedback แบบกว้าง (Vague): “Query นี้มันช้ามากเลย”

✅ Feedback แบบเฉพาะเจาะจง (Specific): “Query นี้ใช้ `JOIN` บนคอลัมน์ `product_id` ซึ่งควรมีการสร้าง Index เพื่อเพิ่มประสิทธิภาพในการค้นหาข้อมูล”

❤️ 2. Sincerity (เจตนาที่จริงใจ): มุ่งเน้นการพัฒนา ไม่ใช่การตำหนิ

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

🛠️ กรณีศึกษา: การปรับปรุง Query ด้วย Specificity

สมมติว่าเรากำลังตรวจสอบ Query ที่ดึงข้อมูลผู้ใช้งานที่เข้าสู่ระบบในช่วง 30 วันที่ผ่านมา:

โค้ดตัวอย่าง: Query ที่กว้างเกินไป (Vague Query)

SQL

SELECT * FROM user_activity WHERE user_id = 1;

(ปัญหา: Query นี้ดึงข้อมูลทั้งหมดของ User ID 1 ซึ่งอาจรวมถึงข้อมูลที่ไม่จำเป็นและทำให้ Query ทำงานหนักเกินไป)

โค้ดตัวอย่าง: Query ที่เฉพาะเจาะจงและมีประสิทธิภาพ (Specific Query)

SQL

SELECT user_id, activity_type, activity_date FROM user_activity WHERE user_id = 1 AND activity_date >= current_date - interval '30 days' AND activity_type IN ('login', 'view');

(การปรับปรุง: เราจำกัดคอลัมน์ (SELECT user_id, activity_type…) และจำกัดช่วงเวลา (activity_date >= …) ทำให้ Query มีประสิทธิภาพและตรงประเด็นมากขึ้น)

✅ สรุป: การเป็น Architect ที่ยอดเยี่ยม

การให้ Feedback ที่ดีจึงเปรียบเสมือนการเป็น Senior Architect ที่ไม่ได้แค่ชี้ว่าโค้ดผิด แต่ต้องชี้ให้เห็นว่า ‘ตรงส่วนไหน’ (Specificity) ผิด ‘เพราะอะไร’ (Technical Reasoning) และ ‘ควรแก้ไขอย่างไร’ (Solution-Oriented) เสมอ

จงจำไว้ว่า การสื่อสารที่ทรงพลังที่สุดคือการผสมผสานระหว่างการสังเกตรายละเอียดอย่างแม่นยำ (Specificity) และความปรารถนาดีที่จะเห็นผู้อื่นพัฒนา (Sincerity) ซึ่งจะทำให้คำแนะนำของคุณมีน้ำหนักและเป็นเครื่องมือในการเรียนรู้ที่แท้จริง