Hai loại chính trực, hai cái trần khác nhau
Khi nói về "chính trực", chúng ta thường gộp hai thứ rất khác nhau làm một.
Chính trực với bản thân (intellectual honesty — sự thành thật trí tuệ) là khả năng nhìn vào năng lực thật của mình mà không bóp méo. Là dám nói "tôi không biết" khi không biết. Là dám viết một dòng ghi chú // TODO: chỗ này tôi chắp vá thay vì giả vờ đã giải quyết. Là dám thừa nhận người ngồi bên cạnh giỏi hơn mình ở một thứ — và đi học từ họ.
Chính trực với người khác (ethical integrity — sự liêm chính đạo đức) là không nhận công của đồng đội, không đổ lỗi cho hệ thống thượng nguồn khi mình sai, không ước lượng thời hạn theo kiểu chính trị thay vì kỹ thuật, không che giấu lỗi để giữ mặt.
Hai thứ này gắn với nhau, nhưng không phải một. Và chúng đặt ra hai cái trần khác nhau:
- Thiếu chính trực với bản thân đặt trần cứng lên năng lực.
- Thiếu chính trực với người khác đặt trần cứng lên tầm ảnh hưởng.
Một người có thể đụng trần thứ hai mà chưa đụng trần thứ nhất — đó là những "kỹ sư 10x độc hại" mà nhiều công ty đều có. Họ code giỏi, nhưng không ai muốn làm với họ, và đội ngũ họ xây dựng không bao giờ trưởng thành. Nhưng — và đây là điểm quan trọng — không ai vượt được trần thứ nhất mà thiếu sự thành thật trí tuệ. Không có ngoại lệ.
Bài viết này tập trung vào trần thứ nhất. Vì nó là cái trần gần như mọi người đụng phải, kể cả những người được xem là "tốt tính".
Vòng lặp mà người thiếu chính trực không bao giờ chạy được
Mọi kỹ sư giỏi đều vận hành một vòng lặp đơn giản:
- Gặp một vấn đề vượt khả năng hiện tại
- Thừa nhận với bản thân rằng mình thiếu cái gì đó
- Đi học, đi hỏi, đi đọc
- Áp dụng và kiểm chứng kết quả
- Cập nhật lại bản đồ năng lực thật của mình
Vòng lặp này nghe có vẻ tầm thường. Nhưng nó đứng yên ngay ở bước 2 đối với người thiếu chính trực với bản thân.
Họ không thể thừa nhận họ thiếu, vì thừa nhận đồng nghĩa với việc đối diện một sự thật khó: rằng mình không giỏi như mình tưởng, rằng người kia thực sự giỏi hơn, rằng cách mình đã làm 5 năm qua có thể đã sai.
Thay vì đối diện, họ chọn các đường vòng:
- "Cái đó không quan trọng" — khi đồng nghiệp dùng kỹ thuật họ không hiểu
- "Code đó phức tạp hóa quá mức" — khi đọc code sạch hơn code mình
- "Lỗi đó là do thư viện" — khi không gỡ rối được
- "Tôi biết rồi" — khi nghe điều gì đó mới mà chưa kịp nghĩ kỹ
- "Người dày dạn (senior) thì cũng vậy thôi" — khi gặp người thực sự giỏi hơn
Mỗi câu đó là một cánh cửa bị đóng lại. Mỗi cánh cửa đóng là một cơ hội học bị bỏ qua. Sau 5 năm, họ có 5 năm kinh nghiệm. Sau 10 năm, họ vẫn có 5 năm kinh nghiệm — lặp lại hai lần.
Dạng thiếu chính trực tinh vi nhất: bám vào "đủ tốt"
Có một dạng thiếu chính trực với bản thân mà gần như ai cũng mắc phải ít nhất một lần, và nó không lộ ra rõ như những dạng trên.
Đó là khi bạn đã chọn một giải pháp — một bộ khung phát triển (framework), một kiến trúc, một quy trình, một cách làm — và sau một thời gian, bằng chứng bắt đầu xuất hiện rằng nó chưa đủ tốt. Có thể có giải pháp khác phù hợp hơn. Có thể cách tiếp cận ban đầu đã sai từ giả định.
Người chính trực với bản thân sẽ dừng lại, thừa nhận, và bỏ công ra tìm kiếm giải pháp tốt hơn — kể cả khi điều đó có nghĩa là vứt bỏ công sức đã đầu tư.
Người thiếu chính trực sẽ tự biện minh (rationalize):
- "Cái này vẫn chạy được mà"
- "Thay đổi giờ rủi ro cao quá"
- "Để chu kỳ phát triển (sprint) sau tính"
- "Chưa đến mức phải làm lại"
Mỗi câu nói trên có thể đúng. Nhưng phép thử là: bạn có thực sự đánh giá lại không, hay bạn chỉ nói câu đó để khỏi phải đánh giá lại?
Khác biệt rất tinh tế, nhưng quyết định. Người đánh giá lại thật sự sẽ có dữ liệu, có so sánh, có lý do cụ thể để giữ lại. Người tự biện minh chỉ có cảm giác — và chi phí đã chìm (sunk cost) không lên tiếng.
Đây là lý do nhiều mã nguồn (codebase), nhiều quy trình, nhiều quyết định kiến trúc tồn tại lâu hơn vòng đời hợp lý của nó rất nhiều. Không phải vì chúng tốt. Mà vì không ai đủ chính trực để nói: "Cái này tôi chọn sai. Tôi phải bỏ công ra làm lại."
Bỏ công ra tìm giải pháp tốt hơn là một hành vi tốn kém. Nó tốn thời gian, tốn năng lượng, đôi khi tốn cả cái tôi. Đó chính là lý do nó cần chính trực để khởi động — không có chính trực, não sẽ luôn tìm được lý do thuyết phục để không phải làm.
Khiêm tốn không cứu được họ
Đây là chỗ nhiều bài viết về "kỹ năng mềm" của kỹ sư hiểu sai.
Họ bảo: hãy khiêm tốn, hãy lắng nghe, hãy giữ "tâm thế của người mới bắt đầu". Nghe rất hay. Nhưng khiêm tốn có thể diễn ra (performative) — diễn ra để được khen là khiêm tốn. Một người có thể cúi đầu, gật gù, nói "em còn phải học nhiều lắm" — và về bàn vẫn viết code y hệt, vẫn không đọc cuốn sách đồng nghiệp giới thiệu, vẫn không thử bộ công cụ mới.
Khiêm tốn là thái độ. Sự thành thật trí tuệ là hành vi.
Thái độ có thể giả. Hành vi thì không — vì hành vi để lại dấu vết: lịch sử mã nguồn, các lần duyệt code (code review), quyết định kỹ thuật, cách bạn phản ứng khi bị chỉ ra cái sai.
Một kỹ sư thực sự chính trực với bản thân không cần tỏ ra khiêm tốn. Họ có thể tự tin, thậm chí gay gắt khi tranh luận. Nhưng khi đối phương đưa ra một lập luận tốt hơn, họ đổi ý ngay tại chỗ — không phải vì lịch sự, mà vì họ quan tâm đến sự thật hơn là quan tâm đến việc mình đúng.
Đây là phép thử quan trọng nhất. Lần cuối bạn đổi ý giữa một cuộc tranh luận kỹ thuật là khi nào?
Vì sao càng lên cao càng nguy hiểm
Ở vị trí mới vào nghề (junior), thiếu chính trực vẫn cho phép một người làm được việc. Nhiệm vụ được giao rõ ràng, code chạy được hay không có sự thật phơi bày tức thời. Bạn không thể giấu lỗi khỏi môi trường vận hành (production) lâu được.
Nhưng từ cấp dày dạn (senior) trở lên — và đặc biệt ở vị trí trưởng nhóm (Lead), kiến trúc sư (Architect), giám đốc công nghệ (CTO) — công việc chuyển sang phán đoán dưới điều kiện bất định: chọn nền tảng công nghệ nào, bỏ tính năng nào, khi nào nói "không" với CEO, kiến trúc này có mở rộng được không.
Những quyết định này không có phản hồi tức thời. Bạn ra quyết định hôm nay, hậu quả lộ ra 6-12 tháng sau. Trong 6-12 tháng đó, một người thiếu chính trực với bản thân sẽ làm một việc rất nguy hiểm: biện minh cho quyết định sai thành đúng.
Họ tìm cách giải thích sao cho mình vẫn đúng. Đổ cho thị trường, đổ cho đội ngũ, đổ cho yêu cầu thay đổi. Và vì không bao giờ thừa nhận quyết định đó sai, họ không bao giờ học được từ nó. Lần sau gặp tình huống tương tự, họ ra quyết định tương tự, và lại biện minh tương tự.
Đây là lý do bạn thấy có những CTO "có vẻ giỏi" mà đội ngũ dưới họ không bao giờ trưởng thành. Không phải vì họ không dạy. Mà vì cái họ làm mẫu cho đội ngũ là: né tránh sự thật là một kỹ năng sinh tồn. Và đội ngũ học theo cái họ thấy, không phải cái họ được dạy.
Phép thử cho chính bạn
Nếu bạn đang đọc đến đây, có lẽ bạn đang tự hỏi: vậy tôi thì sao?
Đây là vài câu hỏi khắc nghiệt để tự thử:
- Lần cuối bạn nói "tôi sai rồi" trong một cuộc họp kỹ thuật là khi nào?
- Khi đồng nghiệp viết code hay hơn bạn, phản ứng đầu tiên trong đầu bạn là gì — học hỏi, hay tìm lý do để chê?
- Bạn có một người dẫn dắt (mentor) thực sự — người bạn thừa nhận giỏi hơn bạn và bạn thực sự nghe lời họ không?
- Trong các lần duyệt code, bạn dễ tiếp nhận góp ý hơn hay dễ giải thích/biện minh hơn?
- Khi đọc câu này, bạn đang nghĩ "đúng rồi, mấy đứa kia thiếu chính trực thật" — hay đang nghĩ "ờ, mình có làm vậy không nhỉ"?
Câu cuối là câu quan trọng nhất. Vì người thiếu chính trực với bản thân, khi đọc một bài như thế này, sẽ luôn nghĩ về người khác. Không bao giờ về mình.
AI đang phá hủy vòng phản hồi cuối cùng
Cho đến gần đây, người thiếu chính trực với bản thân vẫn có một thứ giữ họ không trôi quá xa khỏi thực tế: những va chạm với thế giới. Lần duyệt code chê. Đồng nghiệp phản biện. Sếp lắc đầu. Hệ thống vận hành sập lúc 2 giờ sáng. Những va chạm này khó chịu, nhưng chúng là tín hiệu — buộc người ta phải đối diện sự thật dù không muốn.
AI đang lấy đi những va chạm đó.
Các mô hình ngôn ngữ lớn (LLM) hiện tại được huấn luyện để hữu ích, đồng thuận, và làm người dùng cảm thấy thông minh. Đây không phải lỗi — đây là chủ đích thiết kế. Nhưng với người thiếu chính trực, đặc tính này biến thành một thứ vũ khí tự hủy âm thầm:
- Bạn đưa ra một ý tưởng tệ. AI tìm cách làm nó nghe hợp lý.
- Bạn viết một đoạn code lười biếng. AI khen "sạch và có cấu trúc tốt".
- Bạn hỏi "cách tôi làm có đúng không". AI nghiêng về xác nhận hơn là phản bác.
- Bạn tranh luận với AI về một quyết định kỹ thuật. Bạn "thắng" dễ hơn tranh luận với con người — vì AI nhường.
Trước AI, một kỹ sư thiếu chính trực ít nhất còn bị thực tế va vào. Bây giờ, họ có một công cụ luôn đồng thuận, luôn khen, luôn tìm cách làm họ đúng — và công cụ đó nghe có vẻ thông minh, có vẻ khách quan, có vẻ đã đọc cả mạng internet.
Họ tin nó. Họ dùng nó như một buồng vọng âm (echo chamber) cá nhân hóa. Và lựa chọn của họ — vốn đã méo mó vì thiếu chính trực — giờ được khuếch đại bởi một bộ máy có khả năng thuyết phục mạnh chưa từng có.
Kết quả là một dạng thoái hóa năng lực rất mới và rất nguy hiểm: không chỉ chững lại, mà còn tin chắc rằng mình đang lên cao. Vì AI nói vậy.
Người chính trực với bản thân dùng AI theo cách ngược lại. Họ chủ động yêu cầu phản biện: "Tìm cho tôi lỗ hổng trong lập luận này". "Lập luận ngược lại quyết định của tôi". "Giả định tôi sai — tôi sai ở đâu". Họ biết AI có xu hướng đồng thuận, và họ chủ động kéo nó về phía sự thật. Họ dùng AI như một đối thủ tập luyện (sparring partner), không phải một người cổ vũ (cheerleader).
Cùng một công cụ. Hai cách dùng. Hai kết quả khác nhau hoàn toàn — và khoảng cách giữa hai kết quả đó đang lớn lên mỗi ngày.
Trần đó là chính bạn
Năng lực kỹ sư không phải là một con số IQ cố định. Nó là kết quả của hàng nghìn vòng lặp học hỏi nhỏ qua nhiều năm. Mỗi vòng lặp đó đều bắt đầu bằng một hành vi đơn giản nhưng khó: nhìn vào khoảng trống năng lực của mình mà không bóp méo nó.
Trước đây, hành vi này khó vì cái tôi. Bây giờ, nó còn khó hơn — vì bạn có cả một bộ máy thuyết phục bạn rằng khoảng trống đó không tồn tại.
Người làm được điều này trong thời đại AI sẽ bứt phá xa hơn bất kỳ thế hệ nào trước. Người không làm được sẽ chững lại nhanh hơn bất kỳ thế hệ nào trước — và không bao giờ hiểu vì sao.
Trần đó không phải do thị trường, không phải do AI, không phải do may mắn.
Trần đó là chính họ. Và AI chỉ làm trần đó thấp hơn.