- Những kỹ sư xuất sắc không phải là những lập trình viên giỏi nhất, mà là những người đã học được cách điều hướng con người, chính trị, sự phối hợp và tính mơ hồ xung quanh code
- Nội dung tập trung vào những mẫu lặp đi lặp lại trong dự án và đội ngũ hơn là công nghệ, bao quát từ giải quyết vấn đề người dùng, hợp tác nhóm, chất lượng code đến quản lý sự nghiệp
- Bài viết cho thấy sự rõ ràng là phẩm chất cốt lõi của kỹ sư cấp cao, còn sự khéo léo chỉ là overhead, đồng thời đưa ra góc nhìn nghịch lý rằng code tốt nhất là code không phải viết
- Trong các tổ chức lớn, thất bại trong việc đồng bộ là nguyên nhân chính làm chậm tốc độ, và khi chỉ số đo lường trở thành mục tiêu thì nó sẽ bị bóp méo — một cái bẫy trong vận hành tổ chức
- Ở góc nhìn dài hạn, thời gian trở thành tài nguyên giá trị hơn tiền bạc, và mạng lưới quan hệ tồn tại lâu hơn bất kỳ công việc nào, nên cần thiết kế sự nghiệp một cách có chủ đích
1. Những kỹ sư giỏi nhất bị ám ảnh bởi việc giải quyết vấn đề của người dùng
- Dễ bị cám dỗ bởi việc mê công nghệ trước rồi mới đi tìm nơi áp dụng, nhưng những kỹ sư tạo ra giá trị lớn nhất lại làm ngược lại — hiểu thật sâu vấn đề của người dùng rồi từ đó suy ra lời giải
- Ám ảnh với người dùng nghĩa là dành thời gian cho ticket hỗ trợ, trò chuyện với người dùng, quan sát khó khăn của họ, và liên tục hỏi "tại sao" cho tới khi chạm tới gốc rễ
- Những kỹ sư thực sự hiểu vấn đề thường nhận ra rằng một lời giải thanh nhã đôi khi đơn giản hơn nhiều so với dự đoán
- Những kỹ sư bắt đầu từ giải pháp thì có xu hướng dựng thêm sự phức tạp để hợp thức hóa nó
2. Đúng thì dễ, nhưng cùng nhau đi tới điều đúng mới là công việc thật sự
- Bạn có thể thắng mọi cuộc tranh luận kỹ thuật nhưng vẫn thua cả dự án; đã từng thấy những kỹ sư xuất sắc luôn là người thông minh nhất trong phòng và âm thầm tích lũy sự khó chịu từ người khác
- Cái giá của điều đó về sau xuất hiện dưới dạng "vấn đề thực thi khó hiểu" và "sự kháng cự kỳ lạ"
- Kỹ năng cốt lõi không phải là đúng, mà là tham gia thảo luận để đồng bộ vấn đề, tạo không gian cho người khác và giữ thái độ hoài nghi với chính niềm tin của mình
- Quan điểm mạnh, sự bám chấp yếu — không phải vì thiếu tự tin, mà vì không nên gắn các quyết định dưới điều kiện bất định với bản sắc cá nhân
3. Hãy phát hành với thiên hướng hành động. Một trang tệ có thể sửa, nhưng một trang trắng thì không
- Theo đuổi sự hoàn hảo dẫn tới tê liệt; đã từng thấy các kỹ sư tranh cãi hàng tuần về kiến trúc lý tưởng cho thứ họ chưa từng xây
- Lời giải hoàn hảo không xuất hiện chỉ từ suy nghĩ, mà nảy sinh khi va chạm với thực tế, và AI có thể giúp theo nhiều cách
- Hãy đi theo thứ tự: làm trước, làm cho đúng, rồi làm cho tốt hơn — đưa prototype xấu xí ra trước người dùng, viết bản nháp design doc còn lộn xộn, và phát hành một MVP hơi đáng xấu hổ
- Một tuần phản hồi thật dạy được nhiều hơn một tháng tranh luận lý thuyết; đà tiến tạo ra sự rõ ràng, còn tê liệt vì phân tích thì không tạo ra gì cả
4. Sự rõ ràng là dấu hiệu của senior, còn sự khéo léo là overhead
- Bản năng viết code khéo léo gần như phổ biến ở các kỹ sư và mang lại cảm giác như đang chứng minh năng lực
- Software engineering xuất hiện khi thời gian và những lập trình viên khác được thêm vào bài toán; trong môi trường đó, sự rõ ràng không phải sở thích về phong cách mà là giảm rủi ro vận hành
- Code là bản ghi chú chiến lược dành cho những người xa lạ sẽ phải bảo trì nó lúc 2 giờ sáng trong khi đang có sự cố, nên thay vì tối ưu cho sự thanh nhã, hãy tối ưu cho khả năng họ hiểu được
- Những kỹ sư cấp cao được kính trọng nhất là người học được cách luôn đổi sự khéo léo lấy sự rõ ràng
5. Sự mới mẻ là một món nợ phải trả bằng sự cố, tuyển dụng và overhead nhận thức
- Hãy xem các lựa chọn công nghệ như thể tổ chức có một ngân sách nhỏ gọi là "innovation token", và mỗi khi áp dụng thứ gì đó thật sự phi chuẩn thì bạn tiêu đi một token — bạn không chịu nổi quá nhiều
- Ý chính không phải là "đừng bao giờ đổi mới", mà là "chỉ đổi mới ở những nơi mà bạn được tưởng thưởng vì sự đổi mới độc nhất đó"; còn lại, mặc định nên là sự nhàm chán
- Nhàm chán là tốt vì nó có những mode lỗi đã biết
- "Công cụ tốt nhất cho công việc" thường có nghĩa là "công cụ ít tệ nhất cho nhiều loại công việc" — vì vận hành cả một sở thú công nghệ là một loại thuế rất thật
6. Code không lên tiếng bảo vệ bạn, con người mới làm điều đó
- Đầu sự nghiệp, tôi từng tin rằng công việc tốt sẽ tự nói lên tất cả, nhưng đó là một sai lầm; code chỉ nằm im trong repository
- Quản lý có thể nhắc tới bạn trong cuộc họp hoặc không; đồng nghiệp có thể giới thiệu bạn cho một dự án hoặc giới thiệu người khác
- Trong các tổ chức lớn, quyết định được đưa ra trong những cuộc họp bạn không được mời, dựa trên những bản tóm tắt bạn không trực tiếp viết, bởi những người chỉ có 5 phút và 12 ưu tiên
- Nếu không ai có thể diễn đạt tác động của bạn trong căn phòng không có bạn, thì tác động đó trên thực tế là thứ có thể bị bỏ qua; đây không phải là tự PR, mà là làm cho chuỗi giá trị trở nên dễ đọc với tất cả mọi người, kể cả chính bạn
7. Code tốt nhất là code vốn không cần phải viết
- Văn hóa kỹ thuật thường tôn vinh việc tạo ra, nhưng xóa bớt lại thường cải thiện hệ thống hơn là thêm vào, dù chẳng ai được thăng chức vì xóa code
- Mỗi dòng code không được viết ra là một dòng không cần debug, bảo trì hay giải thích
- Trước khi xây, cần hỏi cho tới cùng: "Nếu mình просто... không làm thì sao?" — đôi khi câu trả lời là "không có gì tệ xảy ra", và đó chính là lời giải
- Vấn đề không phải kỹ sư không biết viết code hay không thể dùng AI để viết, mà là họ viết quá giỏi nên quên hỏi liệu có cần viết hay không
8. Ở quy mô lớn, ngay cả bug cũng có người dùng phụ thuộc
- Khi có đủ nhiều người dùng, mọi hành vi có thể quan sát được đều trở thành một dependency, bất kể nó có được hứa hẹn hay không — sẽ luôn có ai đó scrape API, tự động hóa một điểm kỳ quặc, hoặc cache cả bug
- Điều này dẫn tới một nhận thức ở tầm sự nghiệp: không thể coi công việc tương thích ngược là "bảo trì", còn tính năng mới mới là "việc thật"; tương thích chính là sản phẩm
- Cần thiết kế việc ngừng hỗ trợ như một quá trình migration bằng thời gian, công cụ và sự thấu cảm
- Phần lớn cái gọi là "thiết kế API" trên thực tế lại là "cho API nghỉ hưu"
9. Phần lớn các đội "chậm" thực ra là chưa đồng bộ
- Khi dự án bị trễ, bản năng là đổ lỗi cho thực thi — mọi người không làm đủ chăm, công nghệ sai, không đủ kỹ sư — nhưng thường đó không phải vấn đề thật
- Trong công ty lớn, đội là đơn vị của tính đồng thời, nhưng khi số đội tăng lên thì chi phí điều phối tăng theo cấp số nhân
- Phần lớn sự chậm chạp thực chất là thất bại trong đồng bộ — xây nhầm thứ, hoặc xây đúng thứ nhưng theo cách không tương thích
- Kỹ sư cấp cao dành nhiều thời gian hơn cho làm rõ hướng đi, giao diện và mức độ ưu tiên thay vì "viết code nhanh hơn" — vì nút thắt thật nằm ở đó
10. Tập trung vào thứ có thể kiểm soát, và bỏ qua điều bất khả
- Trong các công ty lớn, vô số biến số nằm ngoài tầm kiểm soát — thay đổi tổ chức, quyết định quản lý, biến động thị trường, xoay trục sản phẩm — nếu ám ảnh vì chúng, bạn sẽ tạo ra lo âu không có năng lực hành động
- Những kỹ sư giữ được tỉnh táo và hiệu quả là người tập trung vào phạm vi ảnh hưởng của mình — bạn không kiểm soát được việc có tái cơ cấu hay không, nhưng có thể kiểm soát chất lượng công việc, cách phản ứng và những gì mình học được
- Khi đối diện với bất định, cần chia vấn đề thành từng phần và xác định những hành động cụ thể mà mình có thể làm
- Đây không phải là chấp nhận thụ động, mà là tập trung có chiến lược; năng lượng dành cho thứ không thể thay đổi là năng lượng bị lấy cắp khỏi những thứ có thể thay đổi
11. Trừu tượng hóa không xóa bỏ độ phức tạp, nó chỉ dời nó tới lúc bạn trực on-call
- Mọi lớp trừu tượng hóa đều là một cú cược rằng bạn sẽ không cần hiểu thứ nằm bên dưới, và đôi khi bạn thắng cú cược đó
- Nhưng luôn có thứ gì đó bị rò rỉ, và khi nó rò rỉ thì bạn phải biết mình đang đứng trên cái gì
- Kỹ sư cấp cao càng lên stack cao càng tiếp tục học những thứ ở "level thấp hơn" — không phải vì hoài niệm, mà vì tôn trọng những khoảnh khắc abstraction thất bại và bạn phải ở một mình với hệ thống lúc 3 giờ sáng
- Hãy dùng stack, nhưng vẫn giữ một mô hình vận hành về các mode lỗi nền tảng của nó
12. Viết buộc bạn phải rõ ràng. Cách nhanh nhất để học sâu hơn một thứ là thử dạy nó
- Viết buộc phải rõ ràng; khi bạn giải thích một khái niệm cho người khác — trong tài liệu, bài trình bày, comment review code, hay thậm chí trò chuyện với AI — bạn sẽ phát hiện ra những khoảng trống trong hiểu biết của mình
- Hành động làm cho thứ gì đó trở nên dễ đọc với người khác cũng khiến nó dễ đọc hơn với chính bạn
- Điều này không có nghĩa là bạn học làm bác sĩ phẫu thuật bằng cách đi dạy người khác, nhưng giả định đó phần lớn đúng trong phạm vi software engineering
- Đây không chỉ là sự hào phóng trong chia sẻ kiến thức, mà còn là một hack học tập vị kỷ — nếu bạn nghĩ mình hiểu điều gì đó, hãy thử giải thích nó một cách đơn giản; chỗ bạn mắc lại chính là chỗ hiểu còn nông
- Dạy người khác là debug mental model của chính mình
13. Công việc giúp những công việc khác trở nên khả thi thì có giá trị, nhưng lại vô hình
- Công việc glue — tài liệu, onboarding, điều phối liên nhóm, cải tiến quy trình — là thiết yếu, nhưng nếu làm một cách vô thức thì nó có thể làm chững quỹ đạo kỹ thuật và dẫn tới burnout
- Cái bẫy là biến nó thành việc "giúp đỡ" chung chung, thay vì xử lý nó như một thứ có chủ đích, có ranh giới và có tác động hiển thị
- Cần đặt giới hạn thời gian, luân phiên và chuyển nó thành sản phẩm đầu ra: tài liệu, template, tự động hóa — rồi biến nó thành thứ có thể đọc được như tác động, chứ không phải như một đặc điểm tính cách
- Có giá trị nhưng vô hình là một tổ hợp nguy hiểm cho sự nghiệp
14. Nếu bạn thắng mọi cuộc tranh luận, có lẽ bạn đang tích lũy sự chống đối âm thầm
- Tôi đã học cách nghi ngờ chính sự chắc chắn của mình; khi bạn "thắng" quá dễ, thường là có gì đó không ổn
- Lý do người ta ngừng tranh luận với bạn không phải vì bạn đã thuyết phục được họ, mà vì họ đã bỏ cuộc; và họ sẽ thể hiện sự bất đồng đó trong thực thi chứ không phải trong cuộc họp
- Sự đồng bộ thật sự mất nhiều thời gian hơn — bạn phải thực sự hiểu các góc nhìn khác, tích hợp phản hồi và đôi khi công khai thay đổi suy nghĩ của mình
- Cảm giác ngắn hạn của việc đúng ít giá trị hơn rất nhiều so với thực tế dài hạn là cùng xây thứ gì đó với những đồng nghiệp sẵn lòng hợp tác
15. Khi đo lường trở thành mục tiêu, nó sẽ ngừng là đo lường
- Mọi chỉ số đưa ra cho quản lý cuối cùng đều bị game hóa, không phải vì ác ý mà vì con người sẽ tối ưu thứ mình bị đo
- Theo dõi số dòng code thì bạn sẽ có nhiều dòng hơn; theo dõi velocity thì bạn sẽ có estimate bị thổi phồng
- Nước đi của senior: trả lời mọi yêu cầu về metric theo cặp — một cái cho tốc độ, một cái cho chất lượng hoặc rủi ro — rồi nhấn mạnh việc diễn giải xu hướng thay vì sùng bái ngưỡng
- Mục tiêu là insight, không phải giám sát
16. Thừa nhận điều mình không biết tạo ra nhiều an toàn hơn là giả vờ biết
- Một kỹ sư cấp cao nói "tôi không biết" không phải đang thể hiện sự yếu đuối, mà là đang tạo ra sự cho phép
- Khi người lãnh đạo thừa nhận sự không chắc chắn, đó là tín hiệu rằng người khác cũng có thể làm như vậy; lựa chọn ngược lại là một nền văn hóa nơi ai cũng giả vờ hiểu và các vấn đề bị che giấu cho tới khi phát nổ
- Đã chứng kiến những đội mà người senior nhất không bao giờ thừa nhận sự bối rối, và cái giá của điều đó — không có câu hỏi nào được nêu ra, không giả định nào bị chất vấn, các kỹ sư junior im lặng vì cho rằng ai cũng hiểu trừ mình
- Khi bạn làm gương về sự tò mò, bạn sẽ có một đội thật sự học hỏi
17. Mạng lưới quan hệ tồn tại lâu hơn mọi công việc bạn từng có
- Đầu sự nghiệp, tôi tập trung vào công việc và xem nhẹ networking; nhìn lại thì đó là một sai lầm
- Những đồng nghiệp đầu tư vào quan hệ — cả trong lẫn ngoài công ty — đã gặt hái lợi ích suốt hàng chục năm
- Họ nghe về cơ hội sớm hơn, xây cầu nối nhanh hơn, được giới thiệu vào vai trò mới và đồng sáng lập venture với những người đã gây dựng niềm tin trong nhiều năm
- Công việc không tồn tại mãi, nhưng mạng lưới quan hệ thì lâu hơn từng công việc riêng lẻ — hãy tiếp cận nó bằng sự tò mò và hào phóng, không phải kiểu hustling mang tính giao dịch
- Khi đến lúc rời đi, thường chính các mối quan hệ sẽ mở cánh cửa
18. Phần lớn cải thiện hiệu năng đến từ việc bỏ bớt công việc, không phải thêm sự khéo léo
- Khi hệ thống chậm đi, bản năng là thêm vào — layer cache, xử lý song song, thuật toán thông minh hơn — đôi khi điều đó đúng, nhưng tôi đã thấy nhiều cải thiện hiệu năng hơn khi hỏi "thứ gì mình không cần phải tính nữa?"
- Xóa bỏ công việc không cần thiết gần như luôn có tác động lớn hơn việc làm công việc cần thiết chạy nhanh hơn; code nhanh nhất là code không được thực thi
- Trước khi tối ưu, hãy chất vấn xem công việc đó có cần tồn tại hay không
19. Quy trình tồn tại để giảm bất định, không phải để tạo ra dấu vết giấy tờ
- Quy trình tốt nhất giúp việc phối hợp dễ hơn và làm cho thất bại rẻ hơn, còn quy trình tệ nhất chỉ là sân khấu quan liêu — nó tồn tại không phải để giúp đỡ mà để phân bổ blame khi có chuyện xảy ra
- Nếu bạn không thể giải thích quy trình đó giảm rủi ro hay tăng sự rõ ràng như thế nào, thì có lẽ nó chỉ là overhead
- Nếu mọi người dành nhiều thời gian để ghi lại công việc hơn là làm công việc, thì chắc chắn đang có điều gì đó rất sai
20. Cuối cùng thời gian sẽ trở nên giá trị hơn tiền bạc, hãy hành xử tương ứng
- Ở giai đoạn đầu sự nghiệp, bạn đổi thời gian lấy tiền, điều đó không sao; nhưng đến một lúc nào đó phép tính sẽ đảo chiều — bạn bắt đầu nhận ra thời gian là tài nguyên không thể tái tạo
- Đã thấy những kỹ sư cấp cao đốt sức vì đuổi theo cấp thăng tiến tiếp theo, tối ưu thêm vài phần trăm đãi ngộ
- Một số đạt được điều đó, nhưng phần lớn về sau lại tự hỏi liệu những gì mình từ bỏ có thật sự đáng giá 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à đánh đổi một cách có chủ đích"
21. Không có lối tắt, nhưng có lãi kép
- Chuyên môn đến từ luyện tập có chủ đích — đẩy bản thân hơi vượt quá kỹ năng hiện tại, suy ngẫm, lặp lại — trong nhiều năm — không có phiên bản nén nào cả
- Phần đáng hy vọng là: việc học vận hành theo lãi kép khi nó tạo ra những lựa chọn mới, chứ không chỉ là vài mẩu kiến thức mới
- Hãy viết — không phải để tương tác, mà để có sự rõ ràng — xây những primitive có thể tái sử dụng, và gom góp mô sẹo thành playbook
- Những kỹ sư xem sự nghiệp như lãi kép thường tiến xa hơn rất nhiều so với những người xem nó như vé số
Suy nghĩ cuối cùng
- 21 bài học nghe có vẻ nhiều, nhưng thực ra chúng quy về vài ý cốt lõi: giữ sự tò mò, giữ sự khiêm tốn, và công việc rốt cuộc luôn xoay quanh con người — người dùng mà bạn đang xây cho họ, và những đồng đội mà bạn đang cùng xây với họ
- Sự nghiệp kỹ sư đủ dài để bạn vẫn tiến lên dù mắc nhiều sai lầm, và những kỹ sư tôi kính trọng nhất không phải người làm đúng mọi thứ mà là những người học từ điều sai, chia sẻ điều mình tìm ra và tiếp tục xuất hiện
- Nếu bạn đang ở đầu hành trình, hãy biết rằng những điều này sẽ trở nên phong phú hơn theo thời gian; còn nếu bạn đã đi sâu, hy vọng một vài điều trong số đó sẽ tạo được sự đồng cảm
5 bình luận
Ý kiến trên Hacker News
Câu “khi quy mô lớn lên thì ngay cả bug cũng có người dùng” làm tôi nhớ lại một chuyện
Khi ở công ty đầu tiên, tôi từng giảm thời gian tải từ 5 phút xuống còn 30 giây, và khách hàng lại phàn nàn
Vì trước đó họ có thời gian bật máy tính lên, đi lấy cà phê rồi tán gẫu, còn khoảng thời gian ấy đã biến mất
Bài học ở đây không phải là đừng cải tiến, mà là đừng quên rằng phần mềm tồn tại trong sự tương tác với thói quen của con người thật
Công việc của kỹ sư không phải là xử lý ticket, mà là giải quyết vấn đề thực sự của người dùng
Hiệu suất càng tăng thì nhân viên lại càng phải làm nhiều lao động tay chân hơn, nên cuối cùng họ càng bất mãn
Rốt cuộc tôi lại bị nhìn như “kẻ đã phá hỏng một hệ thống vốn đang ổn”
Có câu rằng: “Nếu có đủ nhiều người dùng, thì mọi hành vi có thể quan sát được của hệ thống đều sẽ trở thành thứ mà ai đó phụ thuộc vào”
Mỗi lần tôi đều nghĩ “lần này chắc họ sẽ sửa”, nhưng suốt 10 năm họ không sửa, và chính điều đó lại giúp công việc kinh doanh tiếp tục tồn tại
Ba chủ thể này hiểu vấn đề theo những cách khác nhau
Ý nghĩa của mã nguồn không thay đổi chỉ vì ý định hay hy vọng, mà chỉ vận hành trong những ràng buộc của thế giới thực
Bài liên quan: Laws of Software Evolution
Nhưng không phải công ty nào cũng nghĩ như vậy
Điều quan trọng là phải xác định rõ kỳ vọng khi phỏng vấn
Đọc bài của Addy Osmani khiến tôi cảm thấy có phần đạo đức giả
Trước đây anh ấy từng đạo văn mã của tôi, và sau đó có đăng bài xin lỗi, nhưng lại không chia sẻ nó trên mạng xã hội
Nếu là một lời xin lỗi chân thành, tôi nghĩ nó cũng nên được công khai cho những người theo dõi anh ấy biết
Ba bài học đầu tiên đặc biệt chạm tới tôi
Vấn đề là trong giáo dục người ta chỉ dạy ngôn ngữ và framework, chứ không dạy bản thân bài toán
Sự đồng thuận được tích lũy trong quá trình sáng tạo, còn quyền lực chỉ nên dùng khi khủng hoảng
Có quá nhiều trường hợp người ta sợ thất bại nên chỉ tranh luận mãi và lãng phí thời gian
Chính từ bài luận “Boring Technology” mà tôi lần đầu biết đến khái niệm “innovation tokens”
Bài ở boringtechnology.club, và đến giờ vẫn là một trong những bài viết về kiến trúc tôi thích nhất
Câu “trừu tượng hóa không loại bỏ độ phức tạp, nó chỉ chuyển nó sang lúc bạn là người trực on-call” khiến tôi nhớ đến Law of Leaky Abstractions của Joel Spolsky
Trong 15 năm làm lãnh đạo, tôi đã vận hành các hệ thống trị giá hàng tỷ đô ở những tập đoàn bán lẻ lớn
Nhưng cuối cùng thứ quan trọng vẫn là chính trị và các mối quan hệ con người
Những người thông minh hơn tôi cũng không được thăng tiến chỉ vì không giỏi chuyện chính trị
Kết luận cay đắng là phải dạy con cái mình “hãy học chính trị và cả việc nịnh nọt”
Tôi cực kỳ đồng cảm với câu “Clarity is seniority”
Sự rõ ràng là cốt lõi của khả năng bảo trì và mở rộng
Tôi đã viết cuốn Elements of Code để dạy điều đó
Trừu tượng hóa không xấu, vấn đề là sự rõ ràng của mục đích
Nó giống như một kỹ sư xây cầu trong nhà kho mà không nhìn địa hình bên ngoài
Điều đáng trách không phải là bản thân sự trừu tượng hóa, mà là việc không hiểu mình đang cố mô hình hóa điều gì
Trừu tượng hóa sai còn làm hại sự rõ ràng và tạo ra độ phức tạp không cần thiết
Tôi thà có ít trừu tượng hóa còn hơn
Giá trị thật sự của những danh sách kiểu này là tự tay viết ra
Chỉ đọc thôi thì rất nhanh sẽ quên, còn khi tự nhìn lại sự nghiệp và tự sắp xếp lại thì nó mới có ý nghĩa
Bài này không phải là giá trị chính thức của Google, mà là những bài học cá nhân học được khi làm việc ở Google
Đó không phải điều tổ chức dạy, mà là những điều tự ngộ ra qua trải nghiệm
Điểm cốt lõi là ngay cả ở một công ty lớn, đây vẫn là những phần khó
Câu “khi quy mô lớn lên thì ngay cả bug cũng có người dùng” cũng giống với hiện tượng ossification (sự xơ cứng)
Nó không chỉ áp dụng cho giao thức mạng mà cho mọi hệ thống
Lý do thiết kế mã hóa trong HTTP/3 và QUIC cũng là để các thiết bị trung gian không thể đưa ra những giả định sai
API cũng vậy, không nên để lộ trạng thái nội bộ
Câu “Bias towards action” rất ấn tượng
Dù lời khuyên có hay đến đâu thì cũng không giúp được gì cho một trang giấy trắng
Phải làm ra thứ gì đó trước thì mới có thể nhận phản hồi
Ngay từ khoảnh khắc gõ ký tự đầu tiên, những vấn đề ngoài dự tính sẽ bắt đầu lộ ra
Tổ chức càng lớn thì càng có nhiều nút thắt cổ chai vô hình kiểu này
“Ship fast” không có nghĩa là “đẩy ra một cách cẩu thả”
Tôi nghĩ một sản phẩm tối thiểu nhưng hoàn thiện tốt còn hay hơn
Khoảng cách giữa thực tế và lý tưởng là rất lớn, và người viết mỉa mai rằng “Kool Aid rất ngon”
Nếu không thì sẽ bị hiểu thành “làm ẩu”, và khi có vấn đề xảy ra thì bạn sẽ thành vật tế thần
Bài viết rất hay. Đây là dịp để tôi một lần nữa được nhắc nhớ về khái niệm rằng sự phát triển trong sự nghiệp cũng bao hàm cả sự trưởng thành về nhân cách. Cảm ơn, tôi đã đọc rất thú vị.
Những lời này quả thật câu nào cũng đúng.
Ngay từ bài học số 1 đã là một bài học cực kỳ quan trọng rồi.
Dạo này tôi đang cảm nhận điều đó một cách sâu sắc haha
Có quá nhiều nội dung hay và nhiều câu đầy tính chiêm nghiệm đến mức tôi phải thốt lên cảm thán. Việc các câu chính được in đậm cũng khiến bài viết càng dễ đọc hơn.
"Cảm giác mình đúng trong ngắn hạn có giá trị kém xa thực tế dài hạn của việc cùng những đồng đội sẵn lòng hợp tác xây dựng điều gì đó."
"Cần thực hiện sự tập trung mang tính chiến lược; năng lượng dành cho những thứ không thể thay đổi là năng lượng bị lấy mất khỏi những thứ có thể thay đổi."
Không chỉ trong công việc mà còn có nhiều điều rất đáng để áp dụng vào cuộc sống. Cảm ơn vì bài viết hay.
"Code là bản ghi nhớ chiến lược dành cho những người xa lạ sẽ bảo trì nó vào lúc 2 giờ sáng giữa một sự cố, nên nó phải được tối ưu hóa cho mức độ dễ hiểu."
"Động lực tạo ra sự rõ ràng, còn tê liệt vì phân tích thì không tạo ra được gì cả."