The Courage to Be Disliked: Sách gối đầu của Senior?

Sáng thứ Năm tuần trước, tôi ngồi nhìn chằm chằm vào 17 cái comments gay gắt trên một Pull Request, nhịp tim tăng nhanh và cảm giác muốn cãi tay đôi với gã Tech Lead trào lên dữ dội. Đó là khoảnh khắc tôi lôi cuốn “The Courage to Be Disliked” (Dám Bị Ghét) ra khỏi góc tủ, cuốn sách tôi từng đánh giá là “triết lý rẻ tiền” cách đây 3 năm, để đọc lại với một tâm thế hoàn toàn khác.

🧠 Tâm lý học Adler giữa những dòng code

Hầu hết kỹ sư phần mềm chúng ta được đào tạo để giải quyết vấn đề của máy tính, nhưng lại khủng hoảng khi đối mặt với con người. Bạn leo lên vị trí Senior, bạn nhận ra code chỉ chiếm 30% công việc. 70% còn lại là đàm phán với Product Manager (PM), review code cho Junior, và bảo vệ kiến trúc hệ thống trước những yêu cầu vô lý.

Đây chính là lúc triết lý của Alfred Adler — được diễn giải trong cuốn sách này — phát huy tác dụng. Khác với Freud cho rằng quá khứ quyết định hiện tại, Adler khẳng định mọi rắc rối của con người đều bắt nguồn từ các mối quan hệ cá nhân.

Cuốn sách không dạy bạn cách trở thành một kẻ thô lỗ. Nó dạy bạn khái niệm “Phân tách nhiệm vụ” (Separation of Tasks) — một design pattern cho tâm trí.

🎭 Ảo tưởng về sự công nhận

Khi code của bạn không phải là bạn

Bệnh chung của dân kỹ thuật là gắn chặt cái tôi vào những dòng code. Khi ai đó chê kiến trúc của bạn dở, bạn cảm thấy họ đang chê bai chính con người bạn.

Adler đập tan ảo tưởng này bằng một gáo nước lạnh: Bạn không sống để đáp ứng kỳ vọng của người khác. Nếu bạn thiết kế một hệ thống tối ưu nhưng PM không thích vì nó mất thêm 2 ngày, việc họ bực tức là nhiệm vụ của họ. Việc bảo vệ chất lượng dự án là nhiệm vụ của bạn. Sự tách bạch này giống hệt như nguyên tắc Tư Duy Kiến Trúc Hệ Thống: Đừng Mắc Bẫy — module nào lo việc của module đó.

⚔️ Phân tách nhiệm vụ: Tắt thông báo Slack trong đầu

Bug của ai, người nấy lo

Hãy lấy một ví dụ thực tế. Gần đây team tôi dùng Claude Sonnet 4.6 để auto-generate boilerplate code. Một cậu Junior copy-paste nguyên xi mà không kiểm tra, gây ra lỗi trên production.

Phản xạ cũ của tôi là nhảy vào fix hộ để giữ hòa khí, hoặc cảm thấy tội lỗi vì mình review PR không kỹ. Phản xạ theo Adler: Chỉ ra lỗi sai và yêu cầu cậu ta tự sửa. Sự thất vọng của cậu ta khi bị bắt làm lại là “nhiệm vụ” của cậu ta. Việc duy trì tiêu chuẩn code là “nhiệm vụ” của tôi. Từ chối gánh vác cảm xúc của người khác giúp bạn tiết kiệm năng lượng để thực sự làm việc.

⚠️ Điểm yếu chí mạng của cuốn sách

Triết lý có phần cực đoan và độc hại

Tôi chỉ chấm cuốn này 3.2 sao vì những hạt sạn không thể bỏ qua. Sách được viết theo format đối thoại giữa một Triết gia và một Chàng thanh niên. Cách gã Triết gia dồn ép và phủ nhận hoàn toàn khái niệm “sang chấn tâm lý” (trauma) đôi khi mang đậm tính đổ lỗi cho nạn nhân (victim-blaming).

Nếu bạn đang gặp vấn đề tâm lý nặng nề, cuốn sách này có thể làm mọi thứ tệ hơn. Nó chỉ hữu ích khi bạn dùng nó như một công cụ thiết lập ranh giới trong công việc, chứ không phải một cuốn kinh thánh về nhân sinh quan. Đôi khi, việc đi tìm ý nghĩa công việc qua những lăng kính khác như trong Sự thật trần trụi về ‘The Pathless Path’ lại mang tính chữa lành tốt hơn.

⚖️ So sánh Mindset trong công việc

Tình huống	Tư duy thông thường (Freud)	Tư duy phân tách (Adler)	Kết quả thực tế
PM ép deadline vô lý	Ráng cày đêm để PM vui	Báo rủi ro rõ ràng, từ chối	Bị cằn nhằn ban đầu, nhưng code không rác
Bị chê bai trên PR	Tự ái, tìm cách cãi lại	Nhận lỗi nếu đúng, ignore nếu sai	Giữ được cái đầu lạnh
Junior hỏi liên tục	Cầm tay chỉ việc vì cả nể	Đưa tài liệu, yêu cầu tự research	Junior tự lập hơn

🛠️ Cách áp dụng thực dụng vào Sprint tiếp theo

Tôi không khuyên bạn mang sách này lên công ty thuyết giáo. Hãy âm thầm áp dụng nó:

1. Vẽ ranh giới trách nhiệm: Khi nhận task, xác định ngay cái gì bạn kiểm soát được (chất lượng code, thời gian estimate) và cái gì không (cảm xúc của sếp, sự thay đổi requirement).
2. Ngừng giải thích quá mức (Over-explaining): Khi say “No” với một tính năng rác, hãy nói “Không” một cách chuyên nghiệp. Đừng vòng vo xin lỗi chỉ để họ bớt ghét bạn.
3. Chấp nhận sự ma sát: Việc ai đó không hài lòng với bạn trong một cuộc họp technical là tín hiệu cho thấy bạn đang làm đúng nhiệm vụ bảo vệ hệ thống của mình.

❓ Câu hỏi thường gặp

Đọc sách này xong có thành kẻ chống đối trong team không?

Không. Adler dạy sự tự do khỏi áp lực, không phải sự nổi loạn. Bạn vẫn hợp tác, vẫn giao tiếp, chỉ là bạn không còn quỵ lụy hay sợ hãi việc bị đánh giá.

Format đối thoại của sách có dễ đọc không?

Khá mệt mỏi. Chàng thanh niên trong sách thường xuyên gào thét và cãi cùn. Bạn cần kiên nhẫn vượt qua 50 trang đầu tiên để quen với nhịp điệu này.

Kỹ sư Junior có nên đọc sách này không?

Nên, nhưng hãy đọc với tư duy phản biện. Ở level Junior, bạn vẫn cần học hỏi nhiều, đừng dùng “phân tách nhiệm vụ” như một cái cớ để từ chối nhận feedback từ những người đi trước.

🎯 Kết luận

“The Courage to Be Disliked” không phải là một cuốn sách hoàn hảo, và format đối thoại của nó thực sự thử thách lòng kiên nhẫn. Nhưng đối với một Senior Engineer đang kiệt sức vì office politics và những cuộc họp vô bổ, nó cung cấp một framework tư duy sắc bén. Dám bị ghét không phải là trở thành một gã khốn. Dám bị ghét là dũng khí để làm đúng chuyên môn của mình, mặc kệ việc ai đó có bĩu môi trong phòng họp hay không.