- Kỹ sư chỉ biết nói “không” là một mẫu hình senior mặc định ngăn thay đổi mã, làm chậm các tính năng phức tạp và cố gắng để lượng mã được viết ra là ít nhất có thể
- Trong thời kỳ ZIRP, nhờ lãi suất thấp và tuyển dụng mở rộng, tổn thất năng suất ít quan trọng hơn, và vai trò chặn các đề xuất kỹ thuật cực đoan trở nên hữu ích với doanh nghiệp
- Sau khi lãi suất tăng, các công ty công nghệ đã sa thải 5~20% kỹ sư, và khi doanh thu được coi trọng hơn giá cổ phiếu, lớp bảo vệ thay cho câu “không được” cũng giảm đi
- LLM làm gia tăng áp lực với PR do AI tạo ra và lượng mã đủ dùng, nhưng thay đổi cốt lõi không nằm ở AI mà ở động lực kinh tế đã đổi khác do ZIRP kết thúc
- Vai trò này không biến mất, nhưng phù hợp hơn với các mảng kỹ thuật thuần túy, và phải chấp nhận phạm vi hẹp hơn cùng mức độ hiện diện thấp hơn so với thập niên 2010
Vai trò của “kỹ sư chỉ biết nói không”
- Kỹ sư chỉ biết nói “không” là một mẫu hình nằm đâu đó giữa senior và staff engineer, gần với vai trò làm chậm phát triển tính năng, ngăn các thay đổi làm tăng độ phức tạp, và đảm bảo lượng mã được viết ra ít nhất có thể
- Ở phía đối diện, kỹ sư chỉ biết nói “được” ưu tiên di chuyển nhanh, mặc định chấp thuận thay đổi mã, coi trọng MTTR hơn MTBF, và có xu hướng triển khai rất nhiều mã
- Phần lớn kỹ sư nằm ở đâu đó giữa hai cực này, nhưng trọng tâm ở đây là những người đồng nhất mạnh mẽ bản thân với vai trò nói “không”
- Trong thời đại AI, họ không chỉ phải từ chối hàng loạt PR của junior engineer mà còn cả mã do AI tạo ra; đôi khi mã đó lại do manager hoặc VP viết nên việc bác bỏ còn trở nên nhạy cảm về mặt chính trị
- Lần đầu tiên trong sự nghiệp, họ bị gây áp lực lớn phải hạ chuẩn và nói “có”, nhưng nguyên nhân cốt lõi không phải bản thân AI mà là sự chấm dứt của ZIRP
Môi trường do ZIRP tạo ra
- ZIRP là viết tắt của “chính sách lãi suất bằng 0”, chỉ thời kỳ phát triển phần mềm từ 2008 đến 2022 khi ngân hàng cho doanh nghiệp vay tiền với lãi suất gần như bằng 0
- Các nhà đầu tư đổ tiền vay đó vào gần như mọi thứ, và các công ty công nghệ có động lực lớn để tiếp tục tuyển kỹ sư cho những dự án có rủi ro thấp và phần thưởng kỳ vọng cao
- Những công ty thành công mở rộng số lượng kỹ sư từ vài chục lên đến hàng nghìn người, rồi giao cho họ những việc như dự án mã nguồn mở bên lề, các cuộc di cư công nghệ bất tận, hay viết lại bằng ngôn ngữ khác
- Đây là giai đoạn các software engineer có sức mặc cả lớn và gần như làm việc gì cũng được trả lương cao
- Ban lãnh đạo khó mà để ý chi tiết vì đội ngũ tăng quá nhanh, và chỉ riêng việc số kỹ sư tăng lên cũng giúp ích cho giá cổ phiếu, nên nhiều hoạt động không bị xem là vấn đề lớn
- Nhưng khi quá nhiều kỹ sư được tự do hành động, hệ thống có thể trở nên không thể kiểm soát, và đó là lúc kỹ sư chỉ biết nói “không” trở nên hữu ích với doanh nghiệp
Vì sao thời ZIRP câu “không” lại có giá trị
- Vì tổn thất năng suất không phải vấn đề lớn, công ty vẫn chịu được ngay cả khi một nửa kỹ sư rơi vào vòng lặp đề xuất thay đổi rồi bị từ chối
- Cách này cũng có tác dụng khiến kỹ sư không đụng vào các hệ thống cốt lõi của doanh nghiệp
- Nó còn giúp kiểm soát 5% kỹ sư dễ say mê tự do kỹ thuật đến mức đưa ra những đề xuất cực đoan kiểu di cư sang một cơ sở dữ liệu tự làm
- Danh tiếng là một công ty có tiêu chuẩn kỹ thuật rất cao cũng có lợi cho tuyển dụng, và trong thời ZIRP thì mọi công ty công nghệ đều luôn tuyển người
- Câu nói “junior tạo ra nhiều mã, senior tạo ra ít mã hơn, còn staff thì xóa mã” nghe hấp dẫn vì gợi ra hình ảnh chuyên gia hầu như không cần làm gì, nhưng thực ra không đúng ở chỗ staff engineer cũng phải có khả năng tạo ra rất nhiều mã chạy được trong thời gian rất ngắn khi cần
Thay đổi sau khi ZIRP kết thúc
- Khi ngân hàng tăng lãi suất, gần như mọi công ty công nghệ đều lập tức sa thải 5~20% kỹ sư
- Việc duy trì một tổ chức kỹ sư phình to chỉ để nâng giá cổ phiếu không còn sinh lời nữa, và doanh nghiệp giờ phải thực sự kiếm tiền
- Ở đây, “phải kiếm tiền” không nhất thiết có nghĩa là phải có lãi, mà ít nhất là phải tạo ra doanh thu
- Thừa nhận rằng hàng trăm kỹ sư được giao những việc không sinh lợi rõ ràng không phải là lời giải thích công khai tốt cho các đợt sa thải
- Việc ZIRP chấm dứt diễn ra gần trùng với sự trỗi dậy của ChatGPT, nên doanh nghiệp có thể giải thích việc sa thải là do sức mạnh của AI
- Thông điệp kiểu “nhờ công nghệ mang tính chuyển đổi này, một nửa số kỹ sư vẫn có thể tạo ra giá trị gấp 10 lần” nghe rất mạnh, nhưng nếu thật sự như vậy thì lại nảy sinh câu hỏi vì sao không giữ lại kỹ sư để tạo ra giá trị gấp 20 lần
Doanh nghiệp tập trung hơn và lớp bảo vệ mỏng đi
- Các công ty công nghệ hiện tập trung hơn bất kỳ thời điểm nào trong 20 năm qua, và thay vì bày ra nhiều việc ngẫu nhiên, họ đang tuyệt vọng theo đuổi những năng lực và tính năng mới có thể kiếm tiền
- Môi trường mới này chủ động bất lợi cho kỹ sư chỉ biết nói “không”
- Trước đây, kiểu kỹ sư này nhận được sự hậu thuẫn ngầm từ ban lãnh đạo, và ngay cả khi ai đó phàn nàn, mọi chuyện vẫn có thể được bỏ qua theo kiểu “chúng tôi biết người đó đang làm gì, nếu họ nói không được thì cứ tin vậy”
- Giờ đây, sự hậu thuẫn đó đã biến mất, và cùng một hành vi như cũ lại bị ban lãnh đạo chỉ trích hoặc chủ động lật ngược
- Họ bị yêu cầu phải hợp tác hơn, tìm cách để nói “có”, hoặc thậm chí không còn được tham vấn trong các quyết định quan trọng
- Những hành vi từng được thưởng trước năm 2022 nay dẫn tới đánh giá xấu, và đôi khi thay đổi văn hóa đi sau thay đổi động lực kinh tế vài năm
- Sự chuyển dịch này không phụ thuộc vào AI; ngay cả khi LLM không nổi lên trong thập niên này, doanh nghiệp vẫn sẽ sa thải kỹ sư, và những người phụ trách nói “không” vẫn sẽ bối rối vì sao cùng một hành vi lại bị trừng phạt
Cú sốc mà AI bổ sung thêm
- Nếu ZIRP chưa kết thúc, LLM có lẽ đã mang lại cho kỹ sư chỉ biết nói “không” một lý do chính đáng rất mạnh
- Những công ty khó công khai hoặc nội bộ hoài nghi về lập trình có hỗ trợ AI hẳn sẽ phải phụ thuộc rất nhiều vào nhóm kỹ sư này để ngăn trận sóng thần mã AI tràn ngập công ty
- Nhưng trên thực tế, LLM đang giống như xát muối vào vết thương cũ hơn
- Họ phải chứng kiến những PR do AI tạo ra vốn trước đây sẽ bị chặn nay lại được merge, đồng thời còn bị yêu cầu tự dùng chính các công cụ đó
- Tệ hơn nữa là các công cụ AI nhìn chung thực sự hoạt động
- Chúng chưa gây ra kiểu thảm họa nào rõ ràng, và dù mã có kém gọn gàng hơn một chút, mức độ hiểu biết có thấp hơn đôi chút, thì vẫn đủ dùng
- Đặc biệt trong môi trường doanh nghiệp đang thử nhiều thứ mới rồi bỏ đi những gì thất bại, mã “đủ tốt” vẫn phát huy tác dụng
- Ngay cả nếu cho rằng các sự cố gần đây đã tăng lên, thì điều đó cũng có thể là nhận định sai, hoặc còn có những nguyên nhân khác từ hậu ZIRP như tốc độ tăng lên hay sa thải mới là yếu tố chính
- Kỹ sư chỉ biết nói “không” không chỉ đối mặt với đe dọa về sinh kế mà còn cả đe dọa về bản sắc nghề nghiệp
- Họ buộc phải chấp nhận rằng vai trò kỹ thuật của mình từng phụ thuộc vào một môi trường kinh tế rất đặc thù của ngành công nghệ, hoặc tiếp tục khẳng định rằng ngày tận thế đã ở ngay trước mắt
Kỹ thuật thuần túy và kỹ thuật không thuần túy
- Kỹ sư chỉ biết nói “không” sẽ không biến mất, nhưng cũng không còn phù hợp rộng rãi với mọi công ty công nghệ nữa
- Kỹ thuật thuần túy như được phân biệt trong Pure and impure software engineering là những công việc như compiler hay runtime ngôn ngữ, nơi phạm vi được xác định rõ và mục tiêu chủ yếu mang tính kỹ thuật
- Kỹ thuật không thuần túy là những công việc có phạm vi mơ hồ và mục tiêu do khách hàng dẫn dắt, như thử nghiệm các tính năng mới mà không thể chắc chắn trước thành công hay thất bại
- Trong thời ZIRP, các công ty công nghệ làm nhiều công việc thuần túy hơn rất nhiều, như React), và còn có xu hướng đối xử cả công việc không thuần túy như thể nó là công việc thuần túy
- Kỹ sư chỉ biết nói “không” rất phù hợp với công việc thuần túy
- Lý do là codebase thuần túy đòi hỏi tiêu chuẩn chất lượng cao hơn nhiều và có thể chịu được chu kỳ phát triển chậm hơn
- Phần lớn công ty công nghệ vẫn còn một số dạng công việc thuần túy trong các mảng như hạ tầng cốt lõi
- Công việc này là thiết yếu, nhưng không cần những đội ngũ kỹ thuật khổng lồ và cũng hiếm khi nhận được ánh đèn sân khấu
- Nếu vẫn muốn tiếp tục là kỹ sư chỉ biết nói “không”, bạn nên chuyển sang những vai trò như vậy, nhưng phải chấp nhận phạm vi hẹp hơn so với thập niên 2010
Tranh luận và góc nhìn được bổ sung
- Trên lobste.rs và Reddit, có phê bình cho rằng tác động của mã AI chỉ lộ rõ theo thời gian nên còn quá sớm để kết luận rằng nó “nhìn chung hoạt động được”
- Phản biện “vẫn còn quá sớm để nói” rất khó bác bỏ, nhưng có vẻ rõ ràng rằng mã AI hiện chưa gây chết người ngay lập tức
- Cũng có phản biện rằng mẫu hình kỹ sư chỉ biết nói “không” đã tồn tại từ hàng chục năm trước ZIRP, và Linus Torvalds thường được nêu làm ví dụ
- Bản thân mẫu hình này không phải do ZIRP tạo ra, nhưng quan điểm ở đây là ZIRP đã mở rộng một cách nhân tạo ngách dành cho vai trò đó, và nay ngách này lại thu hẹp
- Cũng có phản biện rằng việc dùng ngôn ngữ động cùng công cụ observability và feature flag còn non nớt mới là thứ tạo ra ngách cho vai trò này
- Trên Hacker News, nhiều ý kiến cho rằng lý thuyết này cần bằng chứng vững chắc hơn
- Góc nhìn này dựa trên một ô cửa nhỏ mang tính trải nghiệm cá nhân, nên việc khái quát hóa về ngành trước và sau ZIRP có thể khác nhau tùy người
- Muốn kiểm chứng, có thể khảo sát hàng trăm kỹ sư từ senior trở lên vào năm 2010 và 2026, hỏi họ mỗi tuần đã nói “không” bao nhiêu lần và những lời từ chối đó bị đảo ngược thường xuyên đến mức nào
- Cả trước lẫn sau ZIRP, việc nói “không” vẫn là điều thiết yếu, nhưng điểm khác biệt sau ZIRP là ban lãnh đạo đã nhanh chóng tự có được khả năng đó, làm giảm nhu cầu về một tầng kỹ sư chuyên nói thay câu này
1 bình luận
Ý kiến trên Hacker News
Code là nợ. Khi kỹ sư nói “không”, đó không phải vì ám ảnh một cách chủ quan với chất lượng code mà là để giảm độ phức tạp
Dạo này ban lãnh đạo thường hiểu sai từ “chất lượng”. Chất lượng là lượng nỗ lực phù hợp để tạo ra sản phẩm nhanh nhất có thể với chi phí thấp nhất có thể, đồng thời tính đến việc đội ngũ kỹ sư có thể dễ dàng thêm và sửa đổi code
Có một cách giải thích hay hơn ở đây: https://www.nair.sh/guides-and-opinions/communicating-your-e...
Mọi nỗ lực cố pháp điển hóa thành các quy tắc cứng nhắc về việc người đó đã làm gì và vì sao đều chắc chắn sẽ thất bại
Vấn đề với kiểu kinh tế học bàn giấy này là có thể lập luận theo cả hai hướng
Cũng có thể gọi là “sự kết thúc của thời kỳ lãi suất gần 0 và sự trỗi dậy của kỹ sư chỉ-biết-nói-không”. Chi phí vốn đắt hơn, nên công ty phải dùng tiền khôn ngoan hơn và cần phán đoán của những kỹ sư dám nói không nhiều hơn để tránh đốt tiền vào thứ không cần thiết
Càng đọc tôi càng nghĩ: “bài này có đủ mọi thuật ngữ nghe rất hợp lý, nào là thời kỳ ZIRP, nào là kỹ sư chỉ-biết-nói-không, trông có vẻ sâu sắc, nhưng đào sâu vào thì hoàn toàn không khớp với trải nghiệm của tôi trong ngành kỹ thuật phần mềm thời đó, và cũng chẩn đoán không đúng những thay đổi lớn đang diễn ra với AI hiện nay”. Nói cách khác, nó giống mớ từ khóa thời thượng vô nghĩa, nên tôi mừng vì cộng đồng đã chỉ ra điều đó thay cho việc bài viết không có nút downvote
Dù dự án AI có thất bại thì cũng không sao, miễn là thất bại đủ sớm để còn chuyển sang việc khác. Làm cho đúng ngay từ đầu chỉ trở nên quan trọng với những dự án dài hạn cần đầu tư ban đầu lớn
Câu “việc một nửa kỹ sư trong công ty bị mắc kẹt trong vòng lặp vô tận của đề xuất thay đổi rồi bị từ chối vẫn hoàn toàn ổn. Đằng nào họ cũng không cần phải làm việc hiệu quả, và cách đó giúp họ không ảnh hưởng đến các hệ thống cốt lõi của doanh nghiệp” thì, ừ, cũng là một góc nhìn. Khá yếm thế
Nhìn lại thì nghe khá yếm thế, nhưng hồi đó người ta diễn đạt cùng một tập hợp sự thật đó theo cách khác để bớt làm tổn thương cảm xúc hơn
Người làm Metaverse ở Facebook là nhân sự chủ chốt đang tạo mẫu cho mô hình kinh doanh mới, hay chỉ đang làm việc kiểu bận-rộn-giả-vờ, thì chỉ về sau mới rõ được
Đây là một cách diễn giải khá cực đoan. Nếu sau khi ZIRP kết thúc mà mức độ tập trung tăng lên, thì kết luận tự nhiên chẳng phải là nên từ chối nhiều hơn chứ không phải ít hơn sao?
Nếu muốn lập luận rằng ZIRP đã tạo ra đủ loại công việc giả tạo, rồi còn tạo ra cả các tầng lớp để kiểm soát đám việc giả đó, thì phải uốn người khá gượng ép mới nói được
Tôi thích cách phân biệt giữa “kỹ sư chỉ-biết-gật” và “kỹ sư chỉ-biết-lắc”, cũng như quan điểm ưu tiên MTTR hơn MTBF
Tôi chắc chắn nghiêng về phía “chỉ-biết-gật”, nhưng cũng phải nói rằng các lựa chọn kiến trúc tệ có thể cực kỳ đau đớn để sửa về sau, và tính năng thì khó sửa hơn nhiều sau khi đã có người dùng so với trước khi phát hành. Vì vậy tôi cũng hơi nghiêng về “chỉ-biết-lắc”, hoặc ít nhất là “hãy nghĩ một chút trước đã”
Cân bằng giữa “chỉ-biết-gật” và “chỉ-biết-lắc” phụ thuộc rất nhiều vào dự án. Nếu là tài chính hay y tế thì mặc định “không” có thể tốt hơn, còn nếu là một ý tưởng startup điên rồ nào đó thì YOLO
Yêu cầu thời gian để dọn dẹp thực chất cũng gần như nói không. Người phụ trách kỹ thuật nên có quyền đó và thực sự phải dùng nó. Nếu tuyệt đối không bao giờ dùng thì thực chất cũng chẳng khác gì không có quyền ấy
Đừng trở thành kiểu kỹ sư chỉ biết nói “không” mà không đưa ra phương án thay thế. Đó không phải kỹ sư giỏi mà là kiểu lười biếng nhưng muốn trông có vẻ giỏi
Kỹ sư thường đưa ra những giải pháp cần thiết dù không lý tưởng vì hệ thống legacy. Và không, bạn không thể viết lại cả hệ thống để làm theo “đúng cách”. Chỉ nói “không” hoặc chỉ ra giải pháp không lý tưởng không biến bạn thành thiên tài siêu trí tuệ
Trong các cuộc họp với phía kinh doanh, ông ta tỏ ra áp đảo chỉ vì biết code, và điều tệ nhất là khi không đồng ý với đề xuất thì hoàn toàn không đưa ra phương án thay thế nào. Làm việc cùng rất khó chịu
Có khi kiểu người ZIRP mà bài này nói đến chính là ông ta đấy
Nếu LLM và agent còn thiếu sót, có một luồng tư duy rao bán ý tưởng hạ thấp tiêu chuẩn thay vì chờ chúng được cải thiện. Kiểu như “hãy tập trung vào MTTR”
Code tệ à? Đừng đọc, đừng review, và hãy loại con người đang là nút thắt khỏi vòng lặp. Kiểu tự sự này đang lan ra khắp nơi
Công nghệ này khá hữu ích, nên thay vì chỉ xử lý triệu chứng, mong là mọi người tập trung vào cách làm việc tốt hơn với công cụ và cải thiện quy trình cho phù hợp
Có vô số việc có thể làm, nhưng vấn đề là nên chia thời gian giữa việc dùng nó cho dự án thực tế và việc dành thời gian cho các cải thiện đó như thế nào
Có câu “càng nhiều kỹ sư thì càng có lợi cho giá cổ phiếu… khi ngân hàng tăng lãi suất… việc duy trì một tổ chức kỹ sư phình to để đẩy giá cổ phiếu không còn sinh lời nữa”, vậy có cơ chế nào đã được biết đến để nối số lượng kỹ sư phần mềm và giá cổ phiếu với nhau không? Hay đây chỉ là hiện tượng được quan sát theo kinh nghiệm?
“Ngày xưa chỉ cần nói không với PR do kỹ sư junior viết tay, nhưng giờ thì code do AI tạo ra đổ về, mà một phần trong số đó lại do các manager và VP tạo ra nên rất khó từ chối về mặt chính trị”, trời đất
Tôi từng làm ở công ty công nghệ lớn nhưng đã rời ngành trước khi InstructGPT và các thứ tương tự xuất hiện, nên chưa từng trải qua việc tạo mã bằng LLM ở nội bộ. Chuyện này thật sự đang xảy ra à? Quản lý cấp cao và VP đề xuất các thay đổi mã do LLM tạo ra sao? Tôi chắc không chịu nổi
Gánh nặng chính trị cũng là thật. Bạn không thể chỉ nói “không được”, nhưng lại khá khó để review một cách có ý nghĩa một PR 25 nghìn dòng được gửi bởi người không thực sự biết mình đang làm gì và cũng không trả lời được các câu hỏi
Nói cho công bằng thì hồi đầu công ty ông ấy đã trực tiếp xây dựng liquid và nhiều phần của Shopify, nên không phải người thiếu kinh nghiệm, nhưng dù vậy thì vẫn là như thế
Có vẻ là một giả thuyết khó kiểm chứng. Nếu là một công ty đang cố làm ra điều gì đó, chẳng phải việc có người giúp sắp xếp ưu tiên bằng cách chỉ ra quyết định nào sẽ tạo ra chi phí dài hạn là điều hoàn toàn hợp lý sao?