วิศวกรรมที่เปี่ยมด้วยน้ำใจ

ความมีน้ำใจคืออะไร?

Kind is about being invested in other people, figuring out how to help them, meeting them where they are.

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

— Tanya Reilly, Continuous

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

ความเอาใจใส่

• ให้โฟกัสกับงานของตัวเองมากกว่าการเป็นแค่ "มืออาชีพ"
• เปิดกว้างและแสดงความเป็นมนุษย์ เพื่อสร้างความไว้วางใจ
• ปฏิบัติต่อผู้คนโดยตรง แต่ด้วยความรอบคอบและเอาใจใส่
• คำโกหกสีขาวอาจไม่ใช่เรื่องเลวร้าย แต่ไม่ช่วยให้คนเติบโต
• อย่าสูญเสียความเอาใจใส่ ชื่นชมพฤติกรรมที่ดี และบอกจุดที่ควรปรับปรุง

การสื่อสารแบบอะซิงโครนัส (async)

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

ความปลอดภัยทางจิตใจ

• เป็นฝ่ายขอฟีดแบ็กจากทีมหรือเพื่อนร่วมงานก่อนเสมอ
• โครงสร้างของฟีดแบ็กนั้นเรียบง่ายดังนี้:
  • สิ่งที่ทำได้ดี
  • สิ่งที่ผิดพลาด
  • สิ่งที่จะทำต่อไปภายหลัง
• เปิดรับภูมิหลัง ประวัติ และความชอบส่วนตัวของผู้คนอย่างจริงใจ
• ใส่ใจคนที่ยังมีส่วนร่วมในประชุมหรือเอกสารได้ไม่มาก และหาวิธีช่วยให้พวกเขาได้ส่งเสียง
• สนับสนุนให้ผู้คนสามารถแสดงออกในแบบที่พวกเขารู้สึกว่าใช่สำหรับตัวเอง
• หลายครั้ง ความล้มเหลวของปัจเจกอาจเป็นผลมาจากความล้มเหลวของกระบวนการ สภาพแวดล้อม หรือเวิร์กโฟลว์
• เราประสบความสำเร็จและล้มเหลวไปด้วยกัน
• "ความล้มเหลว" หรือเหตุการณ์ทุกอย่าง ควรถูกมองเป็นโอกาสในการเติบโตและการเรียนรู้
• เพื่อส่งเสริมนวัตกรรม เราควรสนับสนุนให้ผู้คนกล้าเสี่ยง กล้าท้าทาย และรู้สึกว่าการกระทำเหล่านี้ปลอดภัย

ฟีดแบ็ก/คำวิจารณ์

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

---

• ปัญหาโทนคำพูดเป็นพิษในวงการเทค มาช่วยกันแก้กันเถอะ!

[arfwene]

เป็นเรื่องที่ชัดเจนอยู่แล้ว แต่ก็ยากที่จะลงมือทำจริง ๆ..

[aster]

จากข้อมูลข้างต้น เราจะนำวิศวกรรมที่เปี่ยมด้วยความใส่ใจมาปรับใช้กับงานพัฒนาได้อย่างไร
ผมได้ลองสร้างสิ่งที่เรียกว่า KDD (Kindness Driven Development) โดยอาศัยความช่วยเหลือจาก AI

การเขียนโค้ด

• เขียนคอมเมนต์และเอกสารโดยเน้นที่คำถามว่า "ทำไม?" สิ่งสำคัญคือการอธิบายเหตุผลที่โค้ดนี้มีอยู่และบริบทเบื้องหลัง
• สำหรับตรรกะที่ซับซ้อน ให้ใช้ชื่อตัวแปรและชื่อฟังก์ชันที่อิงคำศัพท์ของโดเมน เพื่อให้นักพัฒนาคนอื่นเข้าใจได้ง่าย
• เมื่อนำเทคโนโลยีหรือแพตเทิร์นใหม่มาใช้ ให้คำนึงถึงเส้นโค้งการเรียนรู้ของสมาชิกในทีม
• อย่าตำหนิโค้ดเลกาซี เพราะในเวลานั้นอาจมีข้อจำกัดและบริบทของมันอยู่
• เพื่อผู้ที่จะมาดูแลรักษาในอนาคต ให้จัดทำเอกสารเกี่ยวกับการจัดการ edge case และกรณีล้มเหลวไว้ด้วย
  การออกแบบสถาปัตยกรรม
• ระหว่างออกแบบระบบ ให้คำนึงถึงมุมมองของทีมปฏิบัติการและทีม QA ด้วย
• การทำให้ระบบมอนิเตอร์และดีบักได้ง่าย ก็เป็นส่วนหนึ่งของการออกแบบที่ใส่ใจเช่นกัน
• การออกแบบที่ขยายต่อได้คือความใส่ใจที่มีต่อเพื่อนร่วมทีมในอนาคต
• เมื่อต้องจัดการ technical debt อย่าตั้งเป้าที่จะกำจัดให้หมดอย่างสมบูรณ์ แต่ให้มุ่งไปที่ "ระดับที่จัดการได้"
• สิ่งสำคัญคือการสร้างโครงสร้างที่ทำให้เพิ่มฟีเจอร์ใหม่ได้ง่าย
  การรีวิวโค้ด
• เมื่อต้องขอรีวิว ให้อธิบายบริบทของสิ่งที่เปลี่ยนแปลงอย่างเพียงพอ
• ใช้ฟีดแบ็กเชิงเสนอแนะ เช่น "ถ้าทำแบบนี้จะเป็นอย่างไร?"
• อย่าลืมกล่าวถึงส่วนที่ดีด้วย เช่น "ส่วนนี้เขียนได้เรียบร้อยมากจริง ๆ"
• เมื่อนำเสนอทางเลือกอื่น ให้บอกเหตุผลประกอบไปด้วย
• สำหรับสิ่งที่ควรปรับปรุงแต่ยังไม่เร่งด่วน ให้แยกไปลงเป็น issue ต่างหากเพื่อเคารพขอบเขตของ PR ปัจจุบัน
  โค้ดทดสอบ
• เมื่อการทดสอบล้มเหลว ควรมีข้อความ error ที่ชัดเจน
• test case ทำหน้าที่เป็นเอกสารได้ด้วย จงเขียนการทดสอบที่อธิบายกฎทางธุรกิจได้ดี
• สร้างโครงสร้างที่ช่วยให้นักพัฒนาคนอื่นเพิ่มการทดสอบได้ง่าย
• ใช้ข้อมูลทดสอบที่เป็นกรณีจริงและเข้าใจง่าย
• ทำให้การตั้งค่าสภาพแวดล้อมทดสอบเป็นอัตโนมัติ เพื่อลดอุปสรรคในการเริ่มต้น
  การดีพลอยและการปฏิบัติการ
• ใส่คำอธิบายและคู่มือให้เพียงพอในสคริปต์ดีพลอย
• เตรียม log ที่ช่วยในการดีบักไว้ล่วงหน้าเมื่อเกิดปัญหา
• หากจำเป็นต้องมีการเปลี่ยนแปลงการตั้งค่า ให้จัดทำเอกสารผลกระทบไว้ด้วย
• เมื่อปล่อยฟีเจอร์ใหม่ ให้เตรียมแผน rollback ไว้พร้อมกัน
• เขียนคู่มือปฏิบัติการจากมุมมองของนักพัฒนามือใหม่
  การแบ่งปันความรู้
• จัดทำเอกสารและแบ่งปันประสบการณ์ในการแก้ปัญหา
• เมื่อนำเทคโนโลยีใหม่มาใช้ ให้สร้างและแบ่งปันสื่อการเรียนรู้
• คู่มือการเขียนโค้ดควรรวมถึง "เหตุผลที่เราตัดสินใจทำแบบนี้"
• ส่งเสริมการเติบโตของทีมผ่านช่วงเวลาแบ่งปันความรู้ด้านเทคนิคอย่างสม่ำเสมอ
• การสร้างสภาพแวดล้อมที่เอื้อต่อการตั้งคำถาม จะช่วยสนับสนุนการเติบโตของนักพัฒนารุ่นจูเนียร์

[bbulbum]

เป็นเนื้อหาที่ดีจนสามารถแยกไปเขียนเป็นบทความต่างหากได้เลยครับ 555

[laeyoung]

ดีมากเลย!

[aer0700]

เป็นความคิดเห็นที่ดีมากเลยนะ