Việc lập trình không khó, khó ở chỗ xử lý「con người」và「phức tạp」. Kỹ sư Google kỳ cựu chia sẻ kinh nghiệm 14 năm, từ tư duy người dùng đến hợp tác nhóm, 21 nguyên tắc vàng này giúp bạn đạt được sự nghiệp sâu sắc hơn.
（Tiền đề: Google dịch tức thời chính thức mở rộng tất cả các thương hiệu tai nghe: hơn 70 ngôn ngữ, ra mắt trên điện thoại Android Mỹ-Mexico-Ấn Độ）
（Bổ sung nền tảng: Google chính thức ra mắt 「Gemini 3」! Vượt lên các AI thông minh nhất toàn cầu, có điểm nổi bật gì?）

Mục lục bài viết

• 1. Kỹ sư hàng đầu đam mê giải quyết vấn đề người dùng
• 2. 「Chứng minh mình đúng」không có giá trị, đạt mục tiêu đúng chung mới là trọng tâm
• 3. Ưu tiên hành động. Ra mắt đi! Bạn có thể chỉnh sửa trang kém, nhưng không thể chỉnh sửa trang trống
• 4. Kỳ cựu thể hiện qua sự rõ ràng, trí tuệ thể hiện qua gánh nặng
• 5. 「Mới lạ」là khoản vay cao mượn từ bảo trì, tuyển dụng và gánh nặng nhận thức
• 6. Mã không thể lên tiếng thay bạn, con người mới làm được
• 7. Mã tốt nhất là dòng mã bạn chưa từng viết
• 8. Khi quy mô đủ lớn, cả lỗi của bạn cũng có người dùng
• 9. Hầu hết các nhóm 「chậm chạp」thực ra là nhóm 「mất tập trung」
• 10. Tập trung vào những điều bạn có thể kiểm soát, bỏ qua những điều không thể
• 11. Trừu tượng không xóa bỏ phức tạp, chỉ chuyển nó đi
• 12. Viết rõ ràng bắt buộc, giảng dạy là cách học nhanh nhất
• 13. Làm cho công việc khác khả thi là vô giá, nhưng cũng vô hình
• 14. Nếu bạn thắng mọi tranh luận, có thể bạn đang tích tụ lực cản âm thầm
• 15. Khi chỉ số trở thành mục tiêu, nó không còn là chỉ số tốt nữa
• 16. Thừa nhận 「Tôi không biết」 còn tạo cảm giác an toàn hơn giả vờ hiểu
• 17. Ngữ cảnh của bạn dài hơn bất kỳ công việc nào bạn từng làm
• 18. Phần lớn cải thiện hiệu suất đến từ 「Loại bỏ công việc」chứ không phải 「Thuật toán thông minh」
• 19. Quy trình tồn tại để giảm thiểu sự không chắc chắn, không phải để tạo ra hồ sơ giấy tờ
• 20. Cuối cùng, thời gian sẽ quý hơn tiền bạc, hãy hành động dựa trên đó
• 21. Không có con đường tắt, nhưng có hiệu ứng lãi kép

• Ý tưởng cuối cùng

Giám đốc AI của Google Cloud Addy Osmani, là một kỹ sư phần mềm giàu kinh nghiệm và nhà tư tưởng, từng đảm nhiệm trưởng nhóm trải nghiệm nhà phát triển tại Chrome gần 14 năm, tham gia các dự án DevTools, Lighthouse và Core Web Vitals. Hiện nay, ông phụ trách điều phối công việc giữa Google DeepMind, nhóm kỹ thuật, sản phẩm và quan hệ nhà phát triển.

Trong 3 ngày, ông đã đăng một bài viết chia sẻ sâu sắc về môi trường làm việc trên blog cá nhân. Kết hợp kinh nghiệm làm việc nhiều năm tại Google và phẩm chất nghề nghiệp, ông tổng kết 21 lời khuyên quý giá về giao tiếp, lựa chọn công nghệ và lập kế hoạch sự nghiệp, được biên tập và biên dịch như sau:

Khi tôi gia nhập Google khoảng 14 năm trước, tôi nghĩ công việc này là viết ra mã hoàn hảo. Tôi chỉ đúng một phần. Càng ở lâu, tôi càng nhận ra rằng những kỹ sư xuất sắc không nhất thiết là người viết mã tốt nhất, mà là những người biết làm chủ mọi thứ ngoài mã: bao gồm các mối quan hệ, chính trị nơi làm việc, đồng thuận và sự không chắc chắn.

Kinh nghiệm này là điều tôi ước mình biết sớm hơn. Có những điều giúp tôi tiết kiệm hàng tháng thất vọng, có những điều mất nhiều năm để thực sự hiểu. Tất cả đều không liên quan đến công nghệ cụ thể: công nghệ thay đổi quá nhanh, không quan trọng. Chúng liên quan đến những quy luật lặp đi lặp lại trong các dự án, nhóm khác nhau.

Tôi chia sẻ những điều này vì tôi đã nhận lợi ích lớn từ những kỹ sư sẵn lòng giúp đỡ người đi sau. Đây là chút đền đáp của tôi.

1. Kỹ sư hàng đầu đam mê giải quyết vấn đề người dùng

Yêu thích một công nghệ và tìm kiếm các ứng dụng là điều rất hấp dẫn. Tôi đã từng làm, ai cũng từng làm. Nhưng kỹ sư tạo ra giá trị lớn nhất là những người 「ngược dòng」: họ đam mê hiểu sâu vấn đề của người dùng, và để giải pháp tự nhiên xuất phát từ sự hiểu biết đó.

Chăm sóc người dùng có nghĩa là dành thời gian nghiên cứu các phiếu hỗ trợ khách hàng, trò chuyện với người dùng, quan sát các khó khăn trong thao tác của họ, liên tục hỏi 「tại sao」cho đến khi chạm đến cốt lõi. Những kỹ sư thực sự hiểu vấn đề thường phát hiện ra rằng, giải pháp tinh tế thường đơn giản hơn dự kiến. Từ giải pháp bắt đầu, những kỹ sư này thường thêm vào những phức tạp không cần thiết để hợp lý hóa giải pháp của mình.

2. 「Chứng minh mình đúng」không có giá trị, đạt mục tiêu đúng chung mới là trọng tâm

Bạn có thể thắng mọi tranh luận kỹ thuật, nhưng thua toàn bộ dự án. Tôi đã thấy những kỹ sư thông minh vì luôn muốn là người thông minh nhất trong phòng mà tích tụ những oán giận âm thầm. Hậu quả của điều này sẽ thể hiện qua 「vấn đề thực thi bí ẩn」hoặc 「sự cản trở vô lý」.

Kỹ năng không nằm ở 「đúng」, mà ở việc tham gia thảo luận để đồng thuận vấn đề, tạo không gian cho người khác, và giữ nghi ngờ về sự chắc chắn của chính mình. Ý kiến mạnh mẽ, tâm thế mở — điều này không phải vì bạn thiếu niềm tin, mà vì trong tình huống không chắc chắn, quyết định không nên liên quan đến lòng tự trọng của bạn.

3. Ưu tiên hành động. Ra mắt đi! Bạn có thể chỉnh sửa trang kém, nhưng không thể chỉnh sửa trang trống

Theo đuổi sự hoàn hảo sẽ gây tê liệt. Tôi đã thấy các kỹ sư mất vài tuần để thảo luận về kiến trúc lý tưởng của thứ họ chưa từng xây dựng. Giải pháp hoàn hảo hiếm khi đến từ suy nghĩ thuần túy — nó đến từ va chạm với thực tế. AI có thể giúp đỡ nhiều trong nhiều khía cạnh.

Làm trước, làm đúng, rồi làm tốt hơn. Đưa nguyên mẫu xấu xí ra trước người dùng. Viết bản nháp thiết kế lộn xộn. Phát hành MVP khiến bạn cảm thấy hơi xấu hổ. Những gì học được từ phản hồi thực tế trong một tuần còn nhiều hơn so với một tháng tranh luận lý thuyết. Động lực mang lại sự rõ ràng, phân tích tê liệt thì chẳng đi đến đâu.

4. Kỳ cựu thể hiện qua sự rõ ràng, trí tuệ thể hiện qua gánh nặng

Việc viết mã 「thông minh」 gần như là bản năng của kỹ sư, như một bằng chứng năng lực. Nhưng phần mềm là phản ứng hóa học giữa 「thời gian」và 「các kỹ sư khác」tạo ra. Trong môi trường này, rõ ràng không phải là phong cách yêu thích, mà là giảm thiểu rủi ro vận hành.

Mã của bạn là ghi chú chiến lược cho những người có thể sửa chữa vào lúc 2 giờ sáng. Tối ưu hóa khả năng hiểu của họ, chứ không phải cảm giác thanh lịch của bạn. Những kỹ sư kỳ cựu tôi kính trọng nhất luôn chọn 「thông minh」để đổi lấy 「rõ ràng」.

5. 「Mới lạ」là khoản vay cao mượn từ bảo trì, tuyển dụng và gánh nặng nhận thức

Hãy xem lựa chọn công nghệ của bạn như một công ty 「đổi mới」với ngân sách hạn chế. Mỗi lần bạn dùng công nghệ phi tiêu chuẩn, bạn tiêu một đồng. Bạn không thể trả quá nhiều. Không phải là 「không bao giờ đổi mới」, mà là 「chỉ đổi mới ở những nơi mang lại phần thưởng độc đáo」.

Mọi thứ khác nên được xem như 「nhàm chán」vì nhàm chán có nghĩa là các mô hình thất bại đã biết rõ. 「Công cụ phù hợp nhất cho công việc」thường là 「công cụ hoạt động tốt nhất trong nhiều công việc」—bởi vì duy trì một vườn thú công nghệ sẽ trở thành gánh nặng thực sự.

6. Mã không thể lên tiếng thay bạn, con người mới làm được

Trong sự nghiệp ban đầu, tôi nghĩ hiệu quả công việc sẽ tự chứng minh tất cả. Tôi đã sai. Mã lặng lẽ nằm trong kho. Điều quan trọng là quản lý của bạn có đề cập đến bạn trong các cuộc họp không, đồng nghiệp có giới thiệu bạn tham gia dự án không.

Trong tổ chức lớn, quyết định được đưa ra trong các cuộc họp không mời, bởi những người chỉ có 5 phút để xử lý 12 ưu tiên, dựa trên tóm tắt bạn chưa từng viết. Nếu khi bạn vắng mặt, không ai có thể nói rõ ảnh hưởng của bạn, thì ảnh hưởng của bạn là không đáng kể. Điều này không hoàn toàn là tự quảng bá, mà là làm rõ chuỗi giá trị cho mọi người (bao gồm chính bạn).

7. Mã tốt nhất là dòng mã bạn chưa từng viết

Văn hóa kỹ thuật vui mừng về sáng tạo. Không ai thăng chức vì xóa mã, dù xóa thường tối ưu hệ thống hơn là thêm. Mỗi dòng mã bạn chưa viết, là dòng mã bạn không cần phải gỡ lỗi, bảo trì hay giải thích.

Trước khi xây dựng, hãy tự hỏi một câu: 「Nếu chúng ta không làm gì, chuyện gì sẽ xảy ra?」 Đôi khi câu trả lời là 「Chẳng có chuyện gì xấu」, đó chính là giải pháp của bạn. Vấn đề không phải là kỹ sư không biết viết mã hoặc không biết dùng AI để viết, mà là chúng ta quá giỏi viết mã đến mức quên hỏi 「có nên viết không」.

8. Khi quy mô đủ lớn, cả lỗi của bạn cũng có người dùng

Khi người dùng đủ đông, mọi hành vi có thể quan sát đều trở thành phụ thuộc — dù bạn đã hứa gì đi nữa (định luật Hailstorm). Có người đang truy cập API của bạn, tự động hóa các tính năng kỳ quặc của bạn, cache lỗi của bạn.

Điều này tạo ra một cái nhìn chuyên nghiệp: bạn không thể xem công việc tương thích như 「bảo trì」, hay tính năng mới như 「công việc thực sự」. Tương thích chính là sản phẩm. Khi thiết kế các phương án bỏ đi, hãy xem đó như một quá trình di chuyển có thời gian, công cụ và sự đồng cảm. Hầu hết các 「thiết kế API」thực ra là 「nghỉ hưu API」.

9. Hầu hết các nhóm 「chậm chạp」thực ra là nhóm 「mất tập trung」

Khi dự án trì trệ, phản xạ tự nhiên là đổ lỗi cho khả năng thực thi: thiếu người, chọn công nghệ sai. Thường thì đó không phải là vấn đề cốt lõi. Trong các công ty lớn, nhóm là đơn vị xử lý song song của bạn, nhưng chi phí phối hợp tăng theo cấp số nhân. Hầu hết các nhóm chậm thực ra là mất kết nối—họ xây dựng thứ sai hoặc xây đúng nhưng theo cách không tương thích. Kỹ sư kỳ cựu dành nhiều thời gian hơn để làm rõ hướng đi, giao diện và ưu tiên, chứ không phải là 「viết mã nhanh hơn」, vì đó mới là điểm nghẽn thực sự.

10. Tập trung vào những điều bạn có thể kiểm soát, bỏ qua những điều không thể

Trong các công ty lớn, có vô số biến số bạn không thể kiểm soát—cấu trúc tổ chức, quyết định quản lý, biến động thị trường, hướng sản phẩm. Để tâm vào những thứ này sẽ gây lo lắng mà không giúp ích gì. Kỹ sư hiệu quả và tỉnh táo sẽ tập trung vào vòng ảnh hưởng của họ.

Bạn không thể kiểm soát việc tái cơ cấu, nhưng bạn có thể kiểm soát chất lượng công việc, phản ứng của mình và những gì bạn học được. Khi đối mặt với sự không chắc chắn, hãy phân tích vấn đề và tìm ra hành động cụ thể có thể làm. Đây không phải là chấp nhận thụ động, mà là chiến lược tập trung. Dành năng lượng cho những điều không thể thay đổi là lấy đi của bạn thời gian và năng lượng khỏi những điều bạn có thể thay đổi.

11. Trừu tượng không xóa bỏ phức tạp, chỉ chuyển nó đi

Mỗi trừu tượng đều là một cuộc đánh cược, cược rằng bạn không cần hiểu nguyên lý nền. Đôi khi bạn thắng, nhưng trừu tượng luôn có thể rò rỉ. Khi nó thất bại, bạn cần biết chuyện gì đang xảy ra ở phía dưới. Kỹ sư kỳ cựu dù trong môi trường công nghệ cao vẫn liên tục học hỏi kiến thức 「cơ bản」. Không phải vì hoài cổ, mà vì tôn trọng những lúc trừu tượng thất bại. Dùng công cụ của bạn, nhưng phải hiểu mô hình tâm trí về các điểm thất bại của nó.

12. Viết rõ ràng bắt buộc, giảng dạy là cách học nhanh nhất

Viết giúp bạn suy nghĩ rõ ràng hơn. Khi tôi giải thích một khái niệm cho người khác—dù trong tài liệu, bài thuyết trình, bình luận mã hay chỉ đơn giản là trò chuyện với AI—tôi nhận ra những chỗ còn mơ hồ trong hiểu biết của mình.

Việc làm cho nội dung rõ ràng với người khác cũng giúp tôi rõ ràng hơn. Không chỉ là chia sẻ kiến thức một cách hào phóng, mà còn là mẹo học tập mang tính vị kỷ. Nếu bạn nghĩ mình đã hiểu rõ điều gì, hãy thử giải thích đơn giản. Chỗ bạn gặp khó khăn chính là chỗ bạn hiểu chưa đủ sâu. Giảng dạy là quá trình gỡ lỗi (debug) mô hình tư duy của chính bạn.

13. Làm cho công việc khác khả thi là vô giá, nhưng cũng vô hình

「Công việc gắn kết (Glue work)」—tài liệu, hướng dẫn tuyển dụng, điều phối liên nhóm, cải tiến quy trình—rất quan trọng. Nhưng nếu bạn vô ý làm, nó sẽ cản trở sự phát triển kỹ thuật của bạn và khiến bạn kiệt sức. Cái bẫy là xem nó như 「giúp đỡ」, thay vì coi đó là đóng góp có ý thức, có giới hạn và rõ ràng. Giới hạn thời gian, luân phiên làm, chuyển thành kết quả (tài liệu, mẫu, tự động hóa).

Hãy xem nó như là ảnh hưởng, chứ không phải đặc điểm tính cách.

14. Nếu bạn thắng mọi tranh luận, có thể bạn đang tích tụ lực cản âm thầm

Tôi đã học cách nghi ngờ sự chắc chắn của chính mình. Khi tôi dễ dàng thắng mọi cuộc tranh luận, thường có điều gì đó không ổn. Người ta ngừng tranh luận không phải vì bị thuyết phục, mà vì họ từ bỏ cố gắng—họ thể hiện phản đối trong hành động, chứ không phải trong cuộc họp. Sự đồng thuận thực sự cần thời gian dài hơn.

Bạn phải thực sự hiểu quan điểm của người khác, lắng nghe phản hồi, thậm chí đôi khi thay đổi ý kiến công khai. Cảm giác thắng trong tranh luận ngắn hạn không bằng giá trị làm việc lâu dài với những đồng nghiệp chân thành.

15. Khi chỉ số trở thành mục tiêu, nó không còn là chỉ số tốt nữa

Mỗi chỉ số bạn trình bày cho quản lý cuối cùng đều sẽ bị 「điều chỉnh」. Không phải vì ác ý, mà vì con người sẽ tối ưu hóa theo thứ họ đo lường (định luật Goodhart). Nếu bạn theo dõi số dòng mã, bạn sẽ có nhiều dòng hơn. Nếu theo dõi tốc độ, bạn sẽ có ước lượng phình ra.

Cách của người kỳ cựu: yêu cầu mỗi chỉ số đều có một cặp. Một để đo tốc độ, một để đo chất lượng hoặc rủi ro. Tuân thủ diễn giải xu hướng, chứ không phải sùng bái ngưỡng. Mục tiêu là khả năng nhận thức, chứ không phải giám sát.

16. Thừa nhận 「Tôi không biết」 còn tạo cảm giác an toàn hơn giả vờ hiểu

Kỹ sư kỳ cựu nói 「Tôi không biết」 không phải là thể hiện yếu đuối, mà là tạo ra 「cho phép」. Khi lãnh đạo thừa nhận sự không chắc chắn, họ gửi đi tín hiệu: phòng này cũng an toàn cho người khác. Tôi đã thấy những nhóm không bao giờ thừa nhận bối rối, điều đó gây tổn hại lớn: không ai hỏi vấn đề, giả định không ai phản đối, kỹ sư sơ cấp im lặng vì nghĩ chỉ mình không hiểu. Thể hiện sự tò mò, bạn sẽ có một nhóm thực sự ham học hỏi.

17. Ngữ cảnh của bạn dài hơn bất kỳ công việc nào bạn từng làm

Trong giai đoạn đầu của sự nghiệp, tôi tập trung vào công việc mà bỏ qua các mối quan hệ. Nhìn lại, đó là sai lầm. Đầu tư vào các mối quan hệ (trong và ngoài công ty) đã mang lại lợi ích hàng chục năm. Họ là những người đầu tiên nghe về cơ hội, giúp xây dựng cầu nối nhanh hơn, giới thiệu vị trí, và cùng nhau khởi nghiệp với những người đã xây dựng niềm tin nhiều năm. Công việc không mãi mãi, nhưng các mối quan hệ thì có. Hãy xây dựng mối quan hệ dựa trên sự tò mò và rộng lượng, chứ không phải dựa trên giao dịch.

18. Phần lớn cải thiện hiệu suất đến từ 「Loại bỏ công việc」chứ không phải 「Thuật toán thông minh」

Khi hệ thống chậm lại, phản xạ tự nhiên là thêm: bộ đệm, xử lý song song, thuật toán thông minh hơn. Đôi khi đúng, nhưng tôi đã thấy nhiều hơn nữa là từ câu hỏi: 「Chúng ta đã tính những thứ không cần thiết chưa?」 Xóa bỏ những công việc không cần thiết gần như luôn hiệu quả hơn là làm nhanh hơn công việc cần thiết. Mã nhanh nhất là mã chưa từng chạy.

19. Quy trình tồn tại để giảm thiểu sự không chắc chắn, không phải để tạo ra hồ sơ giấy tờ

Quy trình tốt nhất giúp dễ dàng phối hợp, giảm thiểu rủi ro thất bại. Quy trình tồi nhất là 「kịch bản quan liêu」—nó tồn tại không phải để giúp, mà để đổ lỗi khi có chuyện xảy ra. Nếu bạn không thể giải thích một quy trình làm giảm rủi ro hoặc tăng rõ ràng, thì nó có thể chỉ là gánh nặng. Nếu người ta dành nhiều thời gian ghi chép hơn là làm việc, thì đã có vấn đề lớn.

20. Cuối cùng, thời gian sẽ quý hơn tiền bạc, hãy hành động dựa trên đó

Trong giai đoạn đầu của sự nghiệp, bạn đổi thời gian lấy tiền. Không sao. Nhưng đến một lúc, cách tính sẽ đảo ngược. Bạn nhận ra thời gian là tài nguyên không thể tái tạo. Tôi đã thấy kỹ sư kỳ cựu kiệt sức vì theo đuổi cấp bậc tiếp theo, tối ưu hóa vài phần trăm lương. Có người thành công, nhưng đa số sau đó đều tự hỏi liệu có đáng bỏ công hay không. Câu trả lời không phải là 「đừng cố gắng」, mà là hiểu rõ bạn đang giao dịch gì, và có ý thức về giao dịch đó.

21. Không có con đường tắt, nhưng có hiệu ứng lãi kép

Chuyên môn đến từ luyện tập có chủ đích—vượt ra ngoài kỹ năng hiện tại một chút, phản tư, lặp lại, kéo dài nhiều năm. Không có phiên bản rút gọn. Nhưng hy vọng: khi học tạo ra lựa chọn mới chứ không chỉ tích lũy kiến thức rời rạc, nó sẽ sinh ra lãi kép. Viết lách (để rõ ràng), xây dựng bộ nguyên liệu tái sử dụng, thu thập bài học đắng cay thành sổ tay hướng dẫn. Kỹ sư xem sự nghiệp như 「hiệu ứng lãi kép」chứ không phải 「xổ số」, thường đi xa hơn nhiều.

Ý tưởng cuối cùng

21 nguyên tắc nghe có vẻ nhiều, nhưng cốt lõi thực ra chỉ có vài điều: Giữ tò mò, giữ khiêm tốn, và luôn nhớ rằng công việc luôn liên quan đến con người—bao gồm người dùng bạn xây dựng sản phẩm cho họ, và đồng đội cùng bạn xây dựng sản phẩm.

Sự nghiệp kỹ sư rất dài, đủ để bạn mắc nhiều sai lầm rồi vẫn thành công. Những kỹ sư tôi ngưỡng mộ không phải là người không bao giờ sai, mà là người học hỏi từ sai lầm, chia sẻ phát hiện và kiên trì.

Nếu bạn mới bắt đầu hành trình này, hãy biết rằng theo thời gian, nó sẽ trở nên ngày càng thú vị. Nếu bạn đã nhiều năm, hy vọng vài điều trong đó có thể khiến bạn đồng cảm.