Addy Osmani, Giám đốc Google Cloud AI, là một kỹ sư phần mềm và nhà tư tưởng giàu kinh nghiệm, người đã dành gần 14 năm làm Trưởng bộ phận Trải nghiệm Nhà phát triển tại Chrome, tham gia các dự án như DevTools, Lighthouse và Core Web Vitals. Hiện tại, ông điều phối công việc giữa Google DeepMind, đội ngũ kỹ thuật, sản phẩm và quan hệ nhà phát triển.
Vào ngày 3, anh ấy đã đăng tải một bài viết độ sâu trên blog cá nhân, chia sẻ kinh nghiệm và phẩm chất chuyên môn của mình tại Google trong nhiều năm. Anh ấy đã tóm tắt 21 lời khuyên quý giá về giao tiếp, lựa chọn công nghệ và định hướng nghề nghiệp, được BlockTempo và chỉnh sửa dưới đây:
Khi tôi gia nhập Google khoảng 14 năm trước, tôi nghĩ công việc này chỉ đơn thuần là viết ra những đoạn mã hoàn hảo. Tôi chỉ đúng một phần. Càng ở lại lâu, tôi càng nhận ra rằng những kỹ sư giỏi nhất không nhất thiết là những lập trình viên giỏi nhất, mà là những người đã học được cách xử lý mọi thứ bên ngoài mã nguồn : bao gồm cả các mối quan hệ giữa các cá nhân, chính trị nơi công sở, sự đồng thuận và sự không chắc chắn.
Đây là những bài học mà tôi ước mình đã học được sớm hơn. Một số bài học giúp tôi tránh được hàng tháng trời bực bội, trong khi những bài khác tôi phải mất nhiều năm mới thực sự hiểu thấu. Không bài học nào liên quan đến bất kỳ công nghệ cụ thể nào: công nghệ thay đổi quá nhanh nên không có nhiều ý nghĩa. Chúng nói về những mô hình lặp đi lặp lại trong các dự án và đội ngũ khác nhau.
Tôi chia sẻ điều này vì tôi đã được hưởng lợi rất nhiều từ những kỹ sư sẵn lòng hướng dẫn những người trẻ hơn. Đây là một món quà nhỏ thể hiện lòng biết ơn của tôi.
1. Các kỹ sư hàng đầu luôn say mê giải quyết các vấn đề của người dùng.
Thật khó cưỡng khi phải lòng một công nghệ nào đó và tìm kiếm các ứng dụng của nó. Tôi đã từng như vậy, ai cũng vậy. Nhưng những kỹ sư tạo ra giá trị lớn nhất lại làm việc "ngược lại": họ bị ám ảnh bởi việc thấu hiểu sâu sắc các vấn đề của người dùng và để các giải pháp tự nhiên nảy sinh từ sự thấu hiểu đó.
Sự tận tâm với người dùng nghĩa là dành thời gian nghiên cứu các yêu cầu hỗ trợ khách hàng, trò chuyện với người dùng, quan sát những khó khăn họ gặp phải trong quá trình vận hành và liên tục đặt câu hỏi "tại sao" cho đến khi tìm ra cốt lõi vấn đề. Những kỹ sư thực sự hiểu vấn đề thường nhận thấy rằng các giải pháp hiệu quả thường đơn giản hơn dự kiến. Ngược lại , những kỹ sư bắt đầu bằng việc đưa ra giải pháp thường tạo ra sự phức tạp không cần thiết để hợp lý hóa giải pháp của mình.
2. Việc "chứng minh mình đúng" là vô ích; điều quan trọng là cùng nhau đạt được mục tiêu đúng đắn.
Bạn có thể thắng mọi cuộc tranh luận kỹ thuật, nhưng lại thua cả dự án. Tôi đã chứng kiến nhiều kỹ sư tài giỏi tích tụ sự bất mãn âm thầm vì họ luôn cố gắng trở thành người thông minh nhất trong phòng. Cái giá phải trả cho điều này sau đó sẽ bộc lộ ra dưới dạng "các vấn đề thực thi bí ẩn" hoặc "sự kháng cự không rõ nguyên nhân".
Kỹ năng không nằm ở việc "đúng" mà nằm ở việc tham gia thảo luận để thống nhất quan điểm, tạo không gian cho người khác và duy trì thái độ hoài nghi về sự chắc chắn của chính mình. Quan điểm mạnh mẽ và tư duy cởi mở – điều này không phải vì bạn thiếu niềm tin, mà vì những quyết định được đưa ra trong những tình huống không chắc chắn không nên gắn liền với lòng tự trọng của bạn.
3. Hành động quyết đoán. Ra mắt! Bạn có thể sửa một trang bị lỗi, nhưng bạn không thể sửa một trang trắng.
Việc theo đuổi sự hoàn hảo có thể dẫn đến sự tê liệt. Tôi đã chứng kiến nhiều kỹ sư dành hàng tuần để thảo luận về kiến trúc lý tưởng cho một thứ mà họ chưa từng thực sự xây dựng. Các giải pháp hoàn hảo hiếm khi xuất phát từ lý thuyết thuần túy—chúng nảy sinh từ sự xung đột với thực tế. Trí tuệ nhân tạo có thể giúp ích theo nhiều cách.
Hãy làm trước, rồi làm cho đúng, và cuối cùng là làm tốt hơn nữa. Trình bày bản nguyên mẫu xấu xí cho người dùng. Viết bản nháp đầu tiên lộn xộn của tài liệu thiết kế. Phát hành sản phẩm tối thiểu khả thi (MVP) hơi đáng xấu hổ đó. Bạn sẽ học được nhiều hơn từ một tuần phản hồi thực tế hơn là từ một tháng tranh luận lý thuyết. Hành động mang lại sự rõ ràng; sự trì trệ do phân tích quá mức dẫn đến chẳng được gì.
4. Kinh nghiệm được thể hiện qua sự rõ ràng, thông minh trong việc đảm nhận trách nhiệm.
Bản năng viết mã "thông minh" gần như phổ biến ở mọi kỹ sư; nó giống như một bằng chứng về năng lực. Nhưng kỹ thuật phần mềm là một phản ứng hóa học được tạo ra bởi "thời gian" cộng với "các lập trình viên khác". Trong hoàn cảnh này, sự rõ ràng không phải là một sở thích về phong cách, mà là một cách để giảm thiểu rủi ro vận hành .
Mã nguồn của bạn giống như một bản ghi nhớ chiến lược được viết cho những người lạ, những người có thể đang sửa lỗi lúc 2 giờ sáng. Hãy ưu tiên sự dễ hiểu của họ, chứ không phải sự tinh tế của bạn. Những kỹ sư kỳ cựu mà tôi ngưỡng mộ nhất lần chọn cách đánh đổi "sự khéo léo" lấy "sự rõ ràng".
5. "Sự mới lạ" là một khoản vay lãi suất cao được vay từ việc duy trì, tuyển dụng và gánh nặng nhận thức.
Hãy coi các lựa chọn công nghệ của bạn như một công ty "token đổi mới" với ngân sách hạn chế. Hãy chi một mã thông báo mỗi khi bạn áp dụng một công nghệ thực sự phi tiêu chuẩn. Bạn không thể chi quá nhiều. Vấn đề không phải là "đừng bao giờ đổi mới", mà là " chỉ đổi mới khi bạn sẽ nhận được những phần thưởng độc đáo ".
Mọi thứ khác đều nên được coi là "nhàm chán", bởi vì sự nhàm chán ngụ ý rằng phương thức thất bại của nó đã được biết trước. "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 trên nhiều công việc" — bởi vì việc điều hành một "vườn thú công nghệ" sẽ là một gánh nặng thực sự.
6. Mã nguồn sẽ không nói thay bạn, con người sẽ nói thay bạn.
Thời gian đầu sự nghiệp, tôi từng nghĩ rằng hiệu suất làm việc xuất sắc sẽ tự nói lên tất cả. Tôi đã sai. Mã nguồn chỉ nằm im lặng trong kho lưu trữ. Điều quan trọng là liệu người quản lý có nhắc đến bạn trong các cuộc họp hay không và liệu đồng nghiệp có đề cử bạn cho các dự án hay không.
Trong các tổ chức lớn, các quyết định được đưa ra trong các cuộc họp không được mời, bởi những người chỉ có năm phút để giải quyết mười hai vấn đề ưu tiên, dựa trên các bản tóm tắt mà bạn chưa viết. Nếu không ai có thể diễn đạt được tầm ảnh hưởng của bạn khi bạn vắng mặt, thì tầm ảnh hưởng của bạn là không đáng kể. Điều này không hoàn toàn là về việc tự quảng bá bản thân; mà là về việc làm cho Chuỗi giá trị trở nên rõ ràng đối với mọi người, kể cả chính bạn .
7. Dòng mã tốt nhất là dòng mã bạn không bao giờ viết.
Văn hóa kỹ thuật đề cao sự sáng tạo. Không ai được thăng chức vì xóa mã, mặc dù việc xóa thường tối ưu hóa hệ thống hơn là thêm vào. Mỗi dòng mã bạn không viết ra là mã bạn sẽ không bao giờ cần phải gỡ lỗi, bảo trì hoặc diễn giải.
Trước khi bắt tay vào xây dựng, hãy tự hỏi mình câu hỏi này thật kỹ: " Điều gì sẽ xảy ra nếu chúng ta không làm điều đó? " Đôi khi câu trả lời là "không có gì xấu cả," và đó chính là giải pháp. Vấn đề không phải là các kỹ sư không thể viết mã hoặc không thể sử dụng trí tuệ nhân tạo để viết mã; mà là chúng ta quá giỏi viết mã đến nỗi quên mất câu hỏi "chúng ta có nên viết mã đó không?"
8. Khi bạn đạt đến quy mô đủ lớn, ngay cả những lỗi nhỏ cũng sẽ có người dùng.
Khi bạn có đủ người dùng, bất kỳ hành vi nào có thể quan sát được đều trở thành một yếu tố phụ thuộc — bất kể những gì bạn đã hứa ban đầu (Định luật Hiram). Ai đó đang thu thập dữ liệu từ API của bạn, tự động hóa các lỗi nhỏ và lưu trữ các lỗi của bạn.
Điều này dẫn đến một nhận thức chuyên nghiệp: bạn không thể coi công việc tương thích là "bảo trì" và các tính năng mới là "công việc thực sự". Khả năng tương thích chính là sản phẩm. Khi thiết kế các giải pháp loại bỏ API lỗi thời, hãy coi đó là một quá trình chuyển đổi cần thời gian, công cụ và sự thấu hiểu. Hầu hết "thiết kế API" thực chất là "loại bỏ API".
9. Hầu hết đội ngũ"chậm" thực chất là đội ngũ".
Khi các dự án bị đình trệ, phản ứng tự nhiên là đổ lỗi cho khâu thực thi: thiếu nhân lực, lựa chọn công nghệ sai lầm. Thông thường, đây không phải là vấn đề cốt lõi. Trong các công ty lớn, đội ngũ là những đơn vị hoạt động đồng thời, nhưng chi phí phối hợp tăng trưởng theo cấp số nhân với số lượng đội ngũ . Hầu hết các sự chậm trễ thực chất là do thất bại trong việc phối hợp – mọi người đang xây dựng những thứ sai, hoặc xây dựng những thứ đúng nhưng theo những cách không tương thích. Các kỹ sư cấp cao dành nhiều thời gian hơn để làm rõ hướng đi, giao diện và ưu tiên hơn là "viết mã nhanh hơn", bởi vì đó mới là nút thắt cổ chai thực sự.
10. Hãy tập trung vào những gì bạn có thể kiểm soát và bỏ qua những gì bạn không thể.
Trong các công ty lớn, vô số biến số nằm ngoài tầm kiểm soát của bạn—tái cấu trúc tổ chức, quyết định quản lý, biến động thị trường, thay đổi sản phẩm. Việc cứ mãi lo lắng về những điều này chỉ làm tăng thêm lo âu và cuối cùng là vô ích. Những kỹ sư lý trí và hiệu quả tập trung vào phạm vi ảnh hưởng của mình.
Bạn không thể kiểm soát quá trình tái cấu trúc, nhưng bạn có thể kiểm soát chất lượng công việc, phản ứng và những gì bạn học được. Khi đối diện sự không chắc chắn, hãy phân tích vấn đề và xác định những hành động cụ thể mà bạn có thể thực hiện. Đây không phải là chấp nhận thụ động, mà là tập trung chiến lược. Năng lượng dành cho những điều bạn không thể thay đổi sẽ bị lấy đi từ năng lượng mà bạn có thể thay đổi.
11. Sự trừu tượng không loại bỏ sự phức tạp, nó chỉ đơn thuần là chuyển dịch sự phức tạp đó.
Mỗi sự trừu tượng đều là một canh bạc, một canh bạc mà bạn không cần phải hiểu các nguyên tắc cơ bản. Đôi khi bạn thắng, nhưng các sự trừu tượng luôn có những lỗ hổng. Khi nó thất bại, bạn cần phải biết điều gì đang xảy ra ở bên trong. Các kỹ sư cấp cao tiếp tục học hỏi về "các cấp độ thấp hơn" ngay cả khi hệ thống công nghệ của họ ngày càng cao hơn. Điều này không phải vì hoài niệm, mà là vì sự tôn trọng đối với những khoảnh khắc khi các sự trừu tượng thất bại. Hãy sử dụng chuỗi công cụ của bạn, nhưng hãy nắm vững mô hình tư duy về các chế độ lỗi tiềm ẩn của nó.
12. Viết bắt buộc giúp hiểu rõ vấn đề; dạy học là phương pháp học nhanh nhất.
Viết lách buộc bạn phải suy nghĩ. Khi tôi giải thích một khái niệm cho người khác—cho dù trong tài liệu, bài phát biểu, nhận xét đánh giá mã nguồn, hay thậm chí chỉ là trò chuyện với AI—tôi đều phát hiện ra những lỗ hổng trong hiểu biết của mình.
Việc làm cho nội dung trở nên dễ hiểu đối với người khác cũng giúp tôi hiểu rõ hơn. Điều này không chỉ đơn thuần là chia sẻ kiến thức một cách hào phóng; đó còn là một kỹ thuật học tập mang tính vị kỷ . Nếu bạn cho rằng mình hiểu điều gì đó, hãy thử giải thích nó một cách đơn giản. Bạn gặp khó khăn ở đâu thì đó chính là nơi mà sự hiểu biết của bạn còn nông cạn. Dạy học chính là việc sửa chữa những sai sót trong mô hình tư duy của chính mình.
13. Công việc tạo điều kiện cho các công việc khác diễn ra là vô cùng quý giá, nhưng lại thường vô hình.
Công việc "kết nối" - bao gồm lập tài liệu, hướng dẫn nhân viên mới, phối hợp giữa đội ngũ, cải tiến quy trình - là rất quan trọng. Nhưng nếu bạn làm một cách vô thức, nó có thể 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à coi đó như "giúp đỡ" hơn là một đóng góp có ý thức, có giới hạn và rõ ràng . Hãy đặt ra giới hạn thời gian, luân phiên nhau làm việc và chuyển đổi nó thành kết quả cụ thể (tài liệu, mẫu, công cụ tự động hóa).
Nó nên được xem như một yếu tố ảnh hưởng, chứ không phải là một đặc điểm tính cách.
14. Nếu bạn thắng mọi cuộc tranh luận, bạn có thể đang tạo ra sự kháng cự ngầm.
Tôi đã học cách nghi ngờ chính sự chắc chắn của mình. Khi tôi "thắng" quá dễ dàng, thường thì có điều gì đó không ổn. Mọi người ngừng tranh luận không phải vì bạn đã thuyết phục được họ, mà vì họ đã từ bỏ việc cố gắng – họ thể hiện sự phản đối này trong quá trình thực hiện, chứ không phải trong các cuộc họp. Sự đồng thuận thực sự cần nhiều thời gian hơn.
Bạn phải thực sự hiểu quan điểm của người khác, tiếp thu phản hồi, và đôi khi thậm chí phải công khai thay đổi quan điểm của mình. Sự thỏa mãn ngắn hạn khi thắng một cuộc tranh luận có giá trị thấp hơn nhiều so với giá trị lâu dài của việc hợp tác với những đối tác thực sự tin tưởng vào quan điểm của bạn.
15. Khi chỉ báo trở thành mục tiêu, nó không còn là một chỉ báo tốt nữa.
Mọi chỉ báo bạn trình bày cho ban quản lý cuối cùng đều sẽ bị "thao túng". Điều này không phải do ác ý, mà vì con người luôn tối ưu hóa những gì họ đang đo lường (Định luật Goodhard). Nếu bạn theo dõi số dòng mã, bạn sẽ nhận được nhiều dòng mã hơn. Nếu bạn theo dõi tốc độ, bạn sẽ nhận được các ước tính phóng đại.
Một cách tiếp cận kinh nghiệm: Với mỗi yêu cầu chỉ báo, hãy cung cấp một cặp chỉ báo. Một chỉ số về tốc độ, và một chỉ số về chất lượng hoặc rủi ro. Tập trung vào việc phân tích xu hướng , chứ không phải là quá chú trọng đến các ngưỡng. Mục tiêu là hiểu biết sâu sắc, chứ không phải là giám sát.
16. Thừa nhận "Tôi không biết" tạo ra cảm giác an toàn hơn là giả vờ biết.
Các kỹ sư cấp cao khi nói "Tôi không biết" không phải đang thể hiện sự yếu kém; họ đang tạo ra "sự cho phép". Khi các nhà lãnh đạo thừa nhận sự không chắc chắn, điều đó gửi đi tín hiệu rằng môi trường làm việc an toàn cho tất cả mọi người. Tôi đã từng chứng kiến đội ngũ mà các nhân viên cấp cao không bao giờ thừa nhận sự bối rối, và điều đó vô cùng tai hại: không ai đặt câu hỏi, không ai thách thức các giả định, và các kỹ sư cấp dưới im lặng vì họ nghĩ rằng họ là người duy nhất không hiểu. Hãy thể hiện sự tò mò, và bạn sẽ xây dựng được một đội ngũ thực sự ham học hỏi.
17. Mạng lưới quan hệ của bạn rộng lớn hơn bất kỳ công việc nào bạn từng làm.
Thời gian đầu sự nghiệp, tôi chỉ tập trung vào công việc mà bỏ bê việc xây dựng mạng lưới quan hệ. Nhìn lại, đó là một sai lầm. Những đồng nghiệp đầu tư vào các mối quan hệ (cả trong và ngoài công ty) đã gặt hái được rất nhiều lợi ích trong nhiều thập kỷ. Họ biết đến các cơ hội đầu tiên, xây dựng cầu nối nhanh hơn, nhận được lời giới thiệu việc làm và bắt đầu kinh doanh với những người mà họ đã xây dựng được lòng tin trong nhiều năm. Công việc không tồn tại mãi mãi, nhưng mạng lưới quan hệ thì có. Hãy xây dựng các mối quan hệ với sự tò mò và lòng hào phóng, chứ không phải với tư duy giao dịch.
18. Hầu hết các cải tiến về hiệu suất đến từ việc "loại bỏ công việc", chứ không phải từ "các thuật toán thông minh".
Khi hệ thống hoạt động chậm lại, theo bản năng người ta thường thêm vào: các lớp bộ nhớ đệm, xử lý song song, thuật toán thông minh hơn. Đôi khi điều này đúng, nhưng tôi thấy hiệu suất được cải thiện thường xuyên hơn khi đặt câu hỏi: " Chúng ta đang tính toán những gì mà chúng ta không cần? " Loại bỏ công việc không cần thiết hầu như luôn mang lại hiệu quả cao hơn so với việc thực hiện công việc cần thiết nhanh hơn. Mã nhanh nhất là mã không bao giờ chạy.
19. Các quy trình tồn tại để giảm thiểu sự không chắc chắn, chứ không phải để tạo ra hồ sơ trên giấy tờ.
Các quy trình tốt nhất giúp việc phối hợp dễ dàng hơn và giảm chi phí do sai sót. Các quy trình tệ nhất là "những màn kịch quan liêu" - chúng tồn tại không phải để giúp đỡ, mà để né tránh trách nhiệm khi mọi việc không suôn sẻ. Nếu bạn không thể giải thích được một quy trình giúp giảm rủi ro hoặc tăng tính minh bạch như thế nào, thì có lẽ nó chỉ là một gánh nặng. Nếu mọi người dành nhiều thời gian ghi chép hơn là thực hiện công việc, thì đó là một vấn đề lớn.
20. Cuối cùng, thời gian sẽ quý giá hơn tiền bạc; hãy hành động cho phù hợp.
Ở giai đoạn đầu sự nghiệp, việc đánh đổi thời gian lấy tiền bạc là điều bình thường. Nhưng đến một lúc nào đó, quy luật sẽ đảo ngược. Bạn nhận ra rằng thời gian là một nguồn tài nguyên không thể tái tạo. Tôi đã chứng kiến nhiều kỹ sư kỳ cựu kiệt sức vì cố gắng theo đuổi vị trí cao hơn hoặc tối ưu hóa mức lương của mình chỉ vài phần trăm. Một số người hiểu điều đó, nhưng hầu hết sau này đều tự hỏi liệu cái trả giá phải trả có xứng đáng hay không. Câu trả lời không phải là "đừng làm việc chăm chỉ", mà là " hãy biết mình đang đánh đổi điều gì và hãy đánh đổi một cách có ý thức ".
21. Không có con đường tắt nào cả, nhưng có hiệu ứng của lãi kép.
Năng lực chuyên môn đến từ việc luyện tập có chủ đích—vượt xa kỹ năng hiện tại của bạn, suy ngẫm, lặp lại và tiếp tục trong nhiều năm. Không có phiên bản rút gọn nào cả. Nhưng hy vọng là nó sẽ tích lũy dần khi việc học tạo ra những lựa chọn mới thay vì chỉ là kiến thức rời rạc. Hãy viết (để rõ ràng), xây dựng các nguyên mẫu có thể tái sử dụng và biên soạn những bài học kinh nghiệm thành một cuốn hướng dẫn. Những kỹ sư coi sự nghiệp của mình như "lãi kép" chứ không phải "vé số" thường tiến xa hơn nhiều.
Một suy nghĩ cuối cùng
21 điểm này nghe có vẻ nhiều, nhưng thực chất ý tưởng cốt lõi chỉ có một vài: hãy luôn tò mò, hãy luôn khiêm tốn, và hãy nhớ rằng công việc luôn xoay quanh con người — bao gồm cả những người dùng mà bạn xây dựng sản phẩm cho và những đồng đội cùng xây dựng sản phẩm với bạn.
Sự nghiệp của một kỹ sư đủ dài để bạn có thể mắc nhiều sai lầm mà vẫn thành công. Những kỹ sư mà tôi ngưỡng mộ nhất không phải là những người không bao giờ mắc sai lầm, mà là những người học hỏi từ sai lầm, chia sẻ những phát hiện của mình và kiên trì.
Nếu bạn mới bắt đầu hành trình này, hãy nhớ rằng mọi thứ sẽ chỉ tốt hơn theo thời gian. Nếu bạn đã làm việc trong lĩnh vực này nhiều năm, hy vọng một trong đó sẽ có ích cho bạn.
