Kỹ thuật tử tế

Sự tử tế là gì?

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

Sự tử tế là dành tâm sức cho người khác, tìm cách giúp họ và đáp ứng họ ở đúng hoàn cảnh của họ.

— Tanya Reilly, Continuous

Như Tanya Reilly đã nói ở trên, sự tử tế là đầu tư vào con người. Nó không chỉ là sự niềm nở, mà còn là đặt mình vào vị trí của người khác để hiểu cảm xúc và bối cảnh của họ. Dù không phải là lời giải vạn năng trong mọi tình huống, nó có thể giúp giải quyết nhiều vấn đề.

Sự ân cần

• Hãy tập trung vào công việc của mình vượt lên trên mức chỉ là “chuyên nghiệp”.
• Hãy cởi mở và cư xử như một con người để xây dựng lòng tin.
• Hãy đối diện trực tiếp với mọi người nhưng vẫn chăm sóc họ một cách chu đáo.
• Những lời nói dối vô hại không hẳn là xấu, nhưng chúng không giúp con người trưởng thành.
• Đừng đánh mất sự ân cần; hãy khen ngợi những hành động tốt và góp ý những điểm cần cải thiện.

Giao tiếp bất đồng bộ (async)

• Khi có thay đổi, hãy cố gắng hiểu nhiều hơn không chỉ “cái gì?” và “như thế nào?” mà cả “tại sao?”.
• Đừng mặc định có ác ý hay sự kém năng lực.
• Thay vì những phát biểu gay gắt hoặc dễ gây tranh cãi, hãy đặt những câu hỏi cởi mở.
• Trước khi phê bình, điều quan trọng là phải gắn nhãn thật rõ ràng.
• Phê bình quá nhiều có thể gây cản trở công việc nhiều hơn.
• Nếu có quá nhiều ý kiến, hãy chuyển cách giao tiếp sang tuần tự.

An toàn tâm lý

• Hãy là người đầu tiên xin phản hồi từ đội ngũ hoặc đồng nghiệp.
• Cấu trúc của phản hồi rất đơn giản như sau:
  • Điều đã làm tốt
  • Điều chưa tốt
  • Việc sẽ làm sau đó
• Hãy cởi mở đón nhận bối cảnh, lịch sử và sở thích cá nhân của mọi người.
• Hãy chú ý đến những người không thể đóng góp nhiều trong cuộc họp hoặc tài liệu, và tìm cách để họ có thể cất tiếng nói.
• Hãy lên tiếng để mọi người có thể thể hiện bản thân theo bất kỳ cách nào mà họ cảm thấy là đúng.
• Nhiều khi, thất bại của một cá nhân thực ra có thể bắt nguồn từ thất bại của quy trình, môi trường hoặc workflow.
• Chúng ta cùng thành công, và cũng cùng thất bại.
• Mọi “thất bại” hay sự cố đều nên được xem như cơ hội để trưởng thành và học hỏi.
• Để thúc đẩy đổi mới, cần khuyến khích mọi người chấp nhận rủi ro, thử thách và cảm thấy rằng những hành động đó là an toàn.

Phản hồi/phê bình

• Ngay từ đầu, hãy là người nhận đánh giá trước tiên chứ không phải người đi đánh giá.
• Đừng biến nó thành chuyện cá nhân.
• Khi đưa ra phản hồi hay lời khen, hãy cố gắng cụ thể và đầy đủ nhất có thể.
• Nếu bạn đưa ra phản hồi mang tính phê bình cho ai đó, hãy thử đề xuất cả giải pháp.
• Hãy hiểu sở thích tiếp nhận phản hồi của chính mình.
• Hãy lắng nghe, thấu hiểu, rồi cảm ơn người đã cho bạn phản hồi.
• Đừng phản ứng ngay lập tức; hãy dành thời gian sắp xếp suy nghĩ và xử lý phản hồi.
• Hãy yêu cầu giải thích hoặc ví dụ.
• Hãy ghi nhớ ba yếu tố của việc đưa phản hồi:
  • Cảm xúc
  • Độ tin cậy
  • Logic
• Hãy cân nhắc cảm xúc của người nghe, không chỉ của bản thân bạn.
• Hãy thể hiện sự chuyên nghiệp và khiêm tốn.
• Hãy cho thấy cách bạn làm việc và cách bạn đi đến kết luận.

---

• Ngành công nghệ có vấn đề về giọng điệu độc hại, hãy sửa nó!

[arfwene]

Đó là điều hiển nhiên, nhưng lại khó thực hiện..

[aster]

Dựa trên tài liệu trên, có thể áp dụng kỹ nghệ tử tế trong phát triển như thế nào
Tôi đã thử xây dựng cái gọi là KDD (Kindness Driven Development) với sự hỗ trợ của AI.

Viết mã

• Hãy viết chú thích và tài liệu hóa với trọng tâm là "Tại sao?". Điều quan trọng là giải thích lý do tồn tại của đoạn mã và bối cảnh của nó.
• Với logic phức tạp, hãy sử dụng tên biến và tên hàm có dùng thuật ngữ miền nghiệp vụ để các lập trình viên khác dễ hiểu hơn.
• Khi đưa vào công nghệ hoặc pattern mới, hãy cân nhắc đường cong học tập của các thành viên trong nhóm.
• Đừng chỉ trích mã legacy. Chắc hẳn đã có những ràng buộc và bối cảnh ở thời điểm đó.
• Hãy tài liệu hóa cách xử lý các edge case và failure case cho người sẽ bảo trì trong tương lai.
  Thiết kế kiến trúc
• Khi thiết kế hệ thống, hãy cân nhắc cả góc nhìn của đội vận hành và đội QA.
• Làm cho việc giám sát và gỡ lỗi dễ dàng cũng là một phần của thiết kế tử tế.
• Thiết kế có khả năng mở rộng là sự quan tâm dành cho các thành viên tương lai của nhóm.
• Khi quản lý technical debt, hãy đặt mục tiêu là "mức có thể quản lý được" thay vì loại bỏ hoàn toàn.
• Điều quan trọng là tạo ra một cấu trúc giúp việc bổ sung tính năng mới trở nên dễ dàng.
  Code review
• Khi yêu cầu review, hãy giải thích đầy đủ ngữ cảnh của các thay đổi.
• Hãy dùng kiểu phản hồi mang tính đề xuất như "Làm thế này thì sao?".
• Nhất định cũng hãy nhắc đến những điểm tích cực. "Phần này thật sự rất gọn gàng"
• Khi đưa ra phương án thay thế, hãy giải thích cả lý do.
• Với những cải tiến không quá gấp, hãy đăng ký thành issue riêng để tôn trọng phạm vi của PR hiện tại.
  Mã kiểm thử
• Khi kiểm thử thất bại, hãy cung cấp thông báo lỗi rõ ràng.
• Test case cũng đóng vai trò như tài liệu. Hãy viết các bài kiểm thử giải thích tốt các quy tắc nghiệp vụ.
• Hãy tạo cấu trúc để các lập trình viên khác có thể dễ dàng bổ sung kiểm thử.
• Với dữ liệu kiểm thử, hãy dùng các ví dụ thực tế dễ hiểu.
• Hãy tự động hóa việc thiết lập môi trường kiểm thử để hạ thấp rào cản tham gia.
  Triển khai và vận hành
• Hãy đưa đủ phần giải thích và hướng dẫn vào script triển khai.
• Hãy chuẩn bị trước các log giúp ích cho việc gỡ lỗi khi xảy ra sự cố.
• Nếu cần thay đổi cấu hình, hãy tài liệu hóa mức độ ảnh hưởng.
• Khi phát hành tính năng mới, hãy chuẩn bị cả kế hoạch rollback.
• Hãy viết hướng dẫn vận hành từ góc nhìn của lập trình viên mới.
  Chia sẻ tri thức
• Hãy tài liệu hóa và chia sẻ kinh nghiệm troubleshooting.
• Khi đưa vào công nghệ mới, hãy tạo và chia sẻ tài liệu học tập.
• Hướng dẫn viết mã hãy bao gồm cả "Vì sao chúng ta quyết định làm như vậy".
• Hãy thúc đẩy sự phát triển của cả nhóm thông qua các buổi chia sẻ kỹ thuật định kỳ.
• Tạo ra môi trường dễ đặt câu hỏi sẽ giúp hỗ trợ sự phát triển của các lập trình viên junior.

[bbulbum]

Nội dung này đủ hay để viết thành một bài riêng luôn ấy chứ haha

[laeyoung]

Thật tuyệt vời!

[aer0700]

Đây là một bình luận rất hay.