- vừa được xem lúc

Criticism - Sự phê bình, chỉ trích

0 0 22

Người đăng: Khang

Theo Viblo Asia

Bài viết được dịch từ dev.to. Truy cập bài viết gốc: About criticism.

Sau khi rời xa chiếc ghế giảng đường, bước chân vào cuộc sống bộn bề của xã hội, mỗi chúng ta đều sẽ phải tiếp tục đối mặt với nhiều vấn đề, nhất là trong môi trường làm việc, nơi mà chúng ta phải dành phần lớn thời gian mỗi ngày để học hỏi và phát triển bản thân trên con đường sự nghiệp. Do đó, có lẽ ai đi làm cũng mong muốn được phát triển thật nhiều với hi vọng có thể thăng tiến, cùng những đồng lương tỷ lệ thuận với kiến thức, công sức mình bỏ ra. Và để phát triển, những lời phê bình, chỉ trích đóng vai trò không hề nhỏ, chúng giúp chúng ta nhìn nhận lại mình, thấy được những quan điểm sai lệch để khắc phục và cải thiện bản thân.

Nhưng có phải ai cũng có thái độ đúng đắn khi đi chỉ trích người khác hoặc khi tiếp nhận sự chỉ trích từ người khác? Dưới đây là bài dịch của mình từ một bài chia sẻ khá hay của một anh dev đã có nhiều năm kinh nghiệm trong ngành IT về vấn đề này.


Nhân vật Anton Ego trong Ratatouille - một nhà phê bình nổi tiếng trong giới ẩm thực

Ai cũng có quyền chỉ trích. Mọi lập trình viên ít nhiều đều phải trả qua cả hai phía: chịu sự chỉ trích và đưa ra những lời chi trích. Điều này rất bình thường, đi làm ai cũng sẽ phải trả qua, có thể là trong những buổi meeting, những lần review code hay kể cả khi chúng ta đi comment dạo trên mạng xã hội. Chúng ta hãy cùng xem xét về việc này từ cả hai phía nhé:

Khi bị chỉ trích

Đầu tiên, chúng ta phải phân biệt rõ giữa một lời chỉ trích thực sự và một lời ngụy biện (những lập luận không hợp lý). Những lập luận ngụy biện thường có dạng công kích cá nhân (không đưa ra quan điểm về một đoạn code hoặc bài viết, mà chỉ comment kiểu: "Tấm chiếu mới nên chưa đủ trình hiểu được đâu") hay song đề sai (chỉ đưa ra hai lựa chọn trong khi còn rất nhiều cách, vd như: "Một là dùng React, không thì dùng Vue"). Trong trường hợp này, chúng ta phải chỉ ra:

"Bạn làm ơn nhận xét về đoạn code đi, bình luận kiểu công kích đó không có ích gì cả."

"Đâu phải chỉ có React với Vue, còn vô số framework/library mình có thể sử dụng mà!"

Kế đến là hãy tiếp thu nếu đó là một lời chỉ trích hợp lý, cho dù lời chỉ trích đó có khó nghe đi chăng nữa, vì những lời chỉ trích như vậy ít nhiều cũng đều có ích, giúp cho bạn có cách nhìn khác về giải pháp/lựa chọn của mình. Và quan trọng nhất là cố gắng dẹp bỏ cái tôi của mình trong những cuộc tranh luận vì những lợi ích to lớn hơn.

"Cảm ơn anh đã cho ý kiến"

Chả có gì đáng xấu hổ khi thừa nhận việc mình sai, quan trọng là bạn biết sửa chữa để không tiếp tục sai. Như khi bạn bị một anh mentor hay đồng nghiệp chỉ trích về lỗi sai của mình, hãy vui vẻ:

"Cảm ơn anh đã chỉ ra lỗi đó giúp em"

Đây là một nước đi đỉnh của chóp thể hiện bạn là một người biết lắng nghe, sẵn sàng đảm nhận những trọng trách quan trọng hơn.

Cuối cùng, hãy tìm cách khắc phục: từ những lời phê bình, chỉ trích đó thì chúng ta có thể làm gì để cải thiện, không còn phạm phải lỗi đó nữa? Nếu chưa thể tìm ra cách, bạn có thể trực tiếp xin lời khuyên từ người chỉ trích mình:

"Anh có suggestion gì để giải quyết vấn đề này không?"

Chỉ qua 3 bước trên, bạn sẽ khiến người chỉ trích mình phải, hoặc là câm họng, hoặc là đưa ra những biện pháp để cải thiện, kiểu gì thì bạn cũng là người có lợi. Và vậy là bạn đã xử lý việc bị người khác phê bình, chỉ trích một cách thật chuyên nghiệp và hợp lý. Xứng đáng tăng lương! 😉

Khi đưa ra lời chỉ trích

Khi đưa ra những lời chỉ trích thì bạn đang muốn đạt được điều gì? Có phải chỉ để chứng minh là mình đúng? Hay muốn thuyết phục người khác phải làm theo ý mình? Hay bạn muốn được mọi người công nhận mình là một "expert" trong mảng đó?

Dù mục đích của bạn là gì thì cũng nên tránh những cuộc tranh luận mà bạn chắc chắn sẽ chẳng đạt được lợi ích gì. Đừng để lún sâu vào tình trạng phải tiêu tốn quá nhiều thời gian, công sức vào một việc mà chắc chắn sẽ không đem lại kết quả. Việc chấm dứt một cuộc tranh luận đơn giản hơn bạn nghĩ: cứ "say goodbye" và đừng nói gì thêm. Cho dù có ai không hài lòng và đi nói xấu bạn thì bạn cũng đừng tìm cách trả đũa, không đáng tẹo nào đâu, cứ nhớ là những người đi nói xấu người khác sẽ chẳng tốt đẹp gì trong mắt mọi người đâu.

Nhưng lưu ý là, nếu bạn có thể đưa ra những lời chỉ trích có tính xây dựng (thẳng thắn, rõ ràng, có hướng giải quyết cụ thể) thì sẽ tốt hơn cho cả bạn và người phải chịu những lời chỉ trích từ bạn. Một lời chỉ trích tốt sẽ thỏa 3 tiêu chí sau:

1. Nghe phải hợp lý

Như đã đề cập ở trên, lập luận của những lời chỉ trích phải hợp lý chứ đừng ngụy biện.

👎 "Người người, nhà nhà đều dùng React thì mày cũng nên dùng."

👍 "Cưng nên dùng React vì nó có hệ sinh thái đồ sộ (nhiều tool, nhiều package), giúp cho cưng làm dễ và nhanh hơn."

2. Đừng thể hiện cái tôi

Lời chỉ trích nên có tính khách quan, cả về nội dung lẫn hình thức.

👎 "Chỗ này gặp tao là tao dùng đệ quy chứ không dùng cách của mày."

👍 "Chỗ này chế nghĩ dùng đệ quy sẽ thích hợp hơn, cưng thử đi."

3. Có hướng giải quyết

Một lời chỉ trích đỉnh của chóp là khi người nghe tiếp thu và có được hướng giải quyết.

👎 "Code dở như hạch, không có cách nào cải thiện đâu."

👍 "Cưng có thể áp dụng builder pattern nếu cần phải viết lại chỗ code này."

Ngoài ra, bạn cũng có thể đưa ra những nguồn tư liệu bên ngoài để củng cố luận điểm của mình, đồng thời giúp cho đối phương có thể dễ tiếp nhận lời chỉ trích hơn và cũng để có thêm kiến thức.

Và sau khi đã đưa ra những lời chỉ trích thì hãy sẵn sàng tâm thế và thái độ tích cực, vì những lời đó rất có thể sẽ lại trở thành chủ đề để những người khác chỉ trích.


@khangnd
Github Linkedin Dev.to Fandom

Bình luận

Bài viết tương tự

- vừa được xem lúc

Cách báo cáo sự cố và mindset về cách phòng tránh lặp lại sự cố mà engineer nên biết

Về các loại incident và báo cáo incident (sự cố). .

0 0 42

- vừa được xem lúc

Lập trình viên trưởng thành >< Không trưởng thành trong công việc

Mở đầu. Cùng tuổi, cùng môi trường, nhưng sau 1 năm làm việc vẫn có sự khác biệt giữa các lập trình viên. Sự nhạy bén khi thực hiện công việc. Năng lực tư duy logic.

0 0 29

- vừa được xem lúc

Không nhất thiết phải biết rộng, nhưng nên biết sâu

Bài viết được dịch từ Dev.to.

0 0 32

- vừa được xem lúc

What is Teamwork? (1)

About Us. We are MMJ Vietnam, a product company.

0 0 29

- vừa được xem lúc

97 lời khuyên dành cho lập trình viên – Phần 3

Bạn có thể xem bài viết gốc của mình tại đây: https://phucluong.com/97-loi-khuyen-danh-cho-lap-trinh-vien-phan-3/.

0 0 39

- vừa được xem lúc

97 lời khuyên dành cho lập trình viên – Phần 4

Bạn có thể xem bài viết gốc của mình tại đây: https://phucluong.com/97-loi-khuyen-danh-cho-lap-trinh-vien-phan-4/.

0 0 26