- Lập trình viên senior và người không làm kỹ thuật tiếp nhận cùng một câu nói rằng AI agent sẽ thay thế lập trình viên, nhưng dựa trên hai tiêu chí khác nhau: tính ổn định và việc học từ thị trường
- Tổ chức kinh doanh muốn phát hành thật nhanh để nhận phản hồi và giảm bất định, còn lập trình viên senior thì cảnh giác với sự gia tăng độ phức tạp có thể làm hỏng hệ thống
- Sau khi có khách hàng, hai vòng lặp là khám phá thị trường và duy trì dịch vụ sẽ cùng vận hành, và trách nhiệm cốt lõi của lập trình viên senior chuyển thành quản lý độ phức tạp
- Thuyết phục không dừng ở việc nói rằng “độ phức tạp là vấn đề”, mà chỉ khả thi khi đáp ứng được nhu cầu về tốc độ của đối phương bằng những thử nghiệm nhanh hơn như Google Forms hay nút trong UI hiện có
- AI làm tăng tốc độ phát hành, nhưng có thể làm tổn hại khả năng hiểu, sửa và gỡ lỗi, đồng thời không chịu trách nhiệm, vì vậy lập trình viên senior có thể tách Speed và Scale
Vì sao cùng một câu nói lại được nghe theo những tiêu chí khác nhau
- Lập trình viên senior và người không làm kỹ thuật tiếp nhận khác nhau cùng một câu: “AI agent là tương lai của phát triển phần mềm, và rồi sẽ không còn cần lập trình viên nữa”
- Trong copywriting, thông điệp phải phù hợp với đối tượng, và cùng một câu có thể mang ý nghĩa khác nhau tùy người nghe
- Lý do trực giác của lập trình viên senior tách khỏi sự lạc quan về AI là vì cách định nghĩa vấn đề thay đổi tùy trọng tâm công việc là học từ thị trường hay độ ổn định của dịch vụ
Điều mà lập trình viên senior cảnh giác
- Có kiểu lập trình viên senior muốn đưa thứ gì đó vào chỉ dựa trên công cụ mới, cách làm của công ty khác hoặc best practice trên Hacker News
- Kiểu senior được đánh giá cao hơn sẽ hỏi trước: “Có thật sự cần không?”, “Nếu không làm thì sao?”, “Hiện tại có thể chịu được và xem lại sau khi nó trở nên quan trọng hơn không?”
- Kiểu này cố gắng tránh phát triển mới tối đa, giảm bớt và tái sử dụng
- Trong phát triển phần mềm chuyên nghiệp, thứ mà lập trình viên senior cảnh giác nhất là độ phức tạp
- Các trường hợp đặc biệt, câu lệnh điều kiện, bảng cơ sở dữ liệu mới, component mới đều làm tăng độ phức tạp cho hệ thống
- Lập trình viên chịu trách nhiệm cho một hệ thống đang vận hành cuối cùng sẽ sợ sự gia tăng độ phức tạp
- Ngay cả những lập trình viên senior giỏi thiết kế mới mẻ và sáng tạo, khi phụ trách hệ thống đang chạy, cũng sẽ cảnh giác với độ phức tạp
Điều mà tổ chức kinh doanh cảnh giác
- Marketer, nhân viên sales, product manager và CEO đang ở trong một vòng lặp: đưa thứ gì đó ra thị trường, nhận phản hồi và học xem nó có giá trị hay không
- Mục tiêu của vòng lặp này là học hỏi, và mối đe dọa lớn nhất là bất định
- Vì không chiến lược nào đảm bảo thành công, nên bất định tác động rất khắc nghiệt
- Khi thưởng cho marketing và sales, lương của nhà sáng lập, và dữ liệu của product manager kết hợp với yếu tố thời gian, cách duy nhất để giảm bất định trước thời hạn sẽ là tung ra thị trường càng nhanh càng tốt
- Càng tung ra nhiều thứ hơn, càng nhận được nhiều phản hồi hơn, và từ đó có thể giảm bất định nhiều hơn
- Mọi công ty đều bắt đầu từ vòng lặp này, và vòng lặp này vận hành xoay quanh tốc độ thuần túy
Vòng lặp thứ hai sau khi có khách hàng
- Khi khách hàng bắt đầu trả tiền, sẽ xuất hiện vòng lặp thứ hai với mục tiêu là duy trì và bảo đảm dịch vụ
- Hệ thống phải tiếp tục hoạt động, phải có thể hiểu được, có thể gỡ lỗi, có thể sửa đổi, có thể truyền đạt lại và phải ổn định
- Lập trình viên senior coi trọng tính ổn định vì họ được giao trách nhiệm kinh doanh là tiếp tục phục vụ khách hàng
- Thứ đe dọa tất cả những điều đó, một lần nữa, là độ phức tạp
- Độ phức tạp làm cho hệ thống khó hiểu hơn, khó gỡ lỗi hơn, khó sửa hơn, khó dạy hơn, và cuối cùng là kém ổn định hơn
- Khi độ phức tạp tăng lên, độ ổn định giảm xuống, lập trình viên senior không hoàn thành được trách nhiệm của mình, và những vấn đề như gián đoạn thanh toán có thể xảy ra
- Nếu mục tiêu của vòng lặp đầu tiên là giảm bất định, thì mục tiêu của vòng lặp thứ hai là quản lý độ phức tạp
Điểm khiến giao tiếp thất bại
- Sau khi có khách hàng, hai vòng lặp là khám phá thị trường và duy trì dịch vụ cùng hoạt động song song
- Doanh nghiệp vừa phải khám phá khả năng mới, vừa phải tiếp tục cung cấp dịch vụ cho khách hàng
- Tùy dành thời gian cho vòng lặp nào mà cùng một vấn đề sẽ được nhìn nhận khác nhau
- Tổ chức kinh doanh muốn làm nhanh hơn và đưa ra thị trường sớm hơn để giảm bất định
- Lập trình viên senior thì càng có nhiều yêu cầu càng lo về độ phức tạp, chi phí bảo trì, khả năng hiểu, tốc độ phát triển bền vững và năng suất theo thời gian
- Nhưng chỉ dùng ngôn ngữ của quản lý độ phức tạp thì khó giải quyết được mong muốn giảm bất định của các bộ phận khác
- Muốn thuyết phục, giải pháp của lập trình viên senior phải được diễn đạt như một giải pháp cho vấn đề của đối phương
- Giao tiếp thất bại khi nói về vấn đề bằng góc nhìn quản lý độ phức tạp, nhưng lại không thể nói về giải pháp bằng góc nhìn giảm bất định
Điểm mạnh thực chất của lập trình viên senior
- Năng lực hữu ích nhất của lập trình viên senior là không tạo ra những thứ không cần thiết và tìm ra cơ hội tái sử dụng những gì đã có
- Nếu cần thu thập dữ liệu khảo sát, chỉ cần dùng Google Forms
- Thay vì xây hẳn một tính năng mới để kiểm thử, có thể thêm một nút vào UI hiện có và xem người dùng có bấm hay không
- Trước khi đưa vào một dịch vụ phân tích mới, có thể hỏi trước quyết định quan trọng nhất thật sự cần phân tích là gì, rồi bắt đầu với một quyết định, một biểu đồ, một chỉ số
- Có thể tiếp cận theo kiểu cắm một cây nến lên sandwich thay vì nướng cả chiếc bánh sinh nhật
- Lập trình viên senior học cách tận dụng phần mềm sẵn có để cung cấp điều mọi người muốn
- Câu ngắn gọn để truyền đạt điều này là “Can we try something quicker?”
- “quicker” thừa nhận tốc độ mà đối phương thực sự mong muốn
- “something” hàm ý rằng có thể có cách đạt được mục tiêu khác
- “try” chứa khả năng rằng dù chưa hoàn hảo nhưng vẫn có thể đủ tốt
- Câu này vừa thừa nhận tốc độ giảm bất định mà công ty muốn, vừa cho phép lập trình viên senior phát huy chuyên môn của mình: giảm bớt, tái sử dụng và nếu có thể thì tránh làm mới
Áp lực mà AI tạo ra và trách nhiệm vẫn còn lại
- Vì AI có thể tạo ra rất nhiều thứ trong thời gian ngắn, thái độ giảm bớt, tái sử dụng và tránh làm mới có thể trông như vô nghĩa
- Nhưng AI vẫn chưa làm được một việc mà lập trình viên senior làm: chịu trách nhiệm
- Lý do lập trình viên senior coi trọng khả năng hiểu của hệ thống là vì khi có sự cố, họ phải có thể sửa được nó
- Khả năng hiểu giúp hệ thống có thể mở rộng một cách thông minh khi phát triển, đồng thời tiếp tục cung cấp dịch vụ ổn định cho khách hàng trả phí
- AI làm tăng đáng kể tốc độ đưa sản phẩm ra thị trường, nhưng cũng ảnh hưởng đến vòng lặp ổn định mà lập trình viên senior chịu trách nhiệm
- Khi AI agent, lập trình viên junior, người không làm kỹ thuật, nhà đầu tư và cả những người xung quanh họ cùng thêm code vào hệ thống, hệ thống sẽ thưởng quá mức cho tốc độ và đánh đổi bằng sự ổn định
- AI có thể làm xấu đi khả năng hiểu, khả năng sửa đổi, khả năng gỡ lỗi, khả năng truyền đạt và khả năng bảo đảm
- AI có thể khiến hệ thống trở nên bất ổn nhưng lại không chịu trách nhiệm
- Đây chính là mối lo cốt lõi của lập trình viên senior
Lập trình viên senior gần với biên tập viên hơn là người viết
- Một cách mà lập trình viên senior có thể dùng là tách rời (decoupling)
- Trong thời gian dài, chỉ lập trình viên mới có thể tạo phần mềm, nên họ phải chịu trách nhiệm cho cả hai vòng lặp: học từ thị trường và độ ổn định dịch vụ
- Một hệ thống duy nhất phải gánh đồng thời cả hai mục tiêu
- Nếu dùng hai hệ thống khác nhau cho từng mục tiêu, có thể tách tốc độ và độ ổn định ra khỏi nhau
- Điều này giống như việc một tiểu thuyết gia hoàn thành bản thảo đầu rất nhanh, rồi sau đó trải qua quá trình biên tập để giữ lại những phần hiệu quả và bỏ đi những phần không hiệu quả
- Công việc của biên tập viên là lấy những mảnh ghép hoạt động tốt và gọt giũa chúng thành một tổng thể gắn kết
- Phiên bản Speed là hệ thống dành cho tốc độ, nơi AI agent, mã sinh ra nhưng chưa được rà soát, lập trình viên junior, marketing và các bên khác có thể nhanh chóng biến ý tưởng thành hiện thực
- Phiên bản Speed không nhắm đến khả năng hiểu, mà nhắm đến trạng thái đủ tốt để nhận phản hồi từ thị trường
- Phiên bản Scale là hệ thống dành cho độ ổn định, được lập trình viên senior thiết kế để ổn định, dễ hiểu và có thể mở rộng
- Phiên bản Speed giúp doanh nghiệp tiếp tục học từ thị trường, còn lập trình viên senior đi phía sau để xây dựng một hệ thống đã được rà soát kỹ và có thể hiểu được
- Thiết kế của phiên bản Scale chịu ảnh hưởng từ việc điều gì hoạt động tốt và điều gì không hoạt động trong phiên bản Speed
- Tính năng được tạo ở Speed, rồi sau đó được ổn định hóa ở Scale
- Hình thức triển khai thực tế có thể chưa rõ ràng, nhưng cốt lõi là tách bạch một cách rõ ràng giữa công việc theo đuổi tốc độ và công việc theo đuổi độ ổn định
- Khi nhận một yêu cầu đầy tham vọng, có thể nói rằng “phiên bản Speed sẽ sẵn sàng trong 3 ngày, còn phiên bản Scale sẽ sẵn sàng sau khoảng 6 tuần”
- Đối phương có được tốc độ và đà tiến, còn lập trình viên senior có được thời gian để quan sát và thiết kế
- Theo góc nhìn này, lập trình viên senior có thể gần với một biên tập viên phần mềm senior hơn là một “người viết phần mềm senior”
1 bình luận
Ý kiến trên Hacker News
Phần quan trọng nhất của chuyên môn đến từ mô hình thế giới bên trong, và không thể tách rời khỏi nó
Thông thường người ta tin rằng mọi thứ đều có thể diễn đạt bằng lời, và chỉ cần truyền lời nói đi thì người nghe sẽ hiểu đúng ý người nói, nhưng chính niềm tin đó tạo ra yêu cầu rằng chuyên môn của lập trình viên phải được “truyền đạt” cho người khác
Trên thực tế, tri thức có thể được truyền đạt bằng lời khá tốt, nhưng mô hình thế giới đã được kết nối và đông cứng từ toàn bộ tri thức thì không phải vậy. AI có thể biết nhiều sự thật hơn rất nhiều, nhưng vẫn chưa thể dùng lượng tri thức đó theo cách tạo ra những hiểu biết sâu sắc đúng một cách đáng kinh ngạc với tần suất cao
Việc truyền đạt chuyên môn thực ra gần hơn với gợi ý về việc nên đi đâu và nên học gì, và người nhận phải tự nỗ lực nội hóa nó, đồng thời thông qua những dự án phù hợp để đạt được cùng mức chuyên môn đó
Có thể phân biệt giữa người hiểu và áp dụng được các “định luật vật lý” của phần mềm với người chỉ đơn thuần viết ra các bước thủ tục mà không cố hiểu bản chất của từng bước
Điều này đặc biệt nổi bật khi dạy lập trình hàm cho người đã quen với hướng đối tượng: có người thấy mô hình của mình sụp đổ, còn có người nhanh chóng nhận ra rằng có thể dịch từ thế giới của biến sang thế giới của monad tương đối dễ dàng
Tôi đã làm việc gần 30 năm, phần lớn ở một tập đoàn lớn, và mỗi tuần dành khá nhiều thời gian để trả lời các vấn đề mà người mới vào gặp phải. Chỉ cần nghe câu hỏi thôi tôi thường đã nhận ra ngay rằng gốc rễ của vấn đề nằm ở chỗ mô hình thế giới của họ, tức Theory theo cách Naur gọi, còn thiếu hoặc bị méo mó nên việc suy luận trở nên khó khăn
Nhiệm vụ là chuyển lý thuyết của bản thân thành các biểu đạt mang tính ký hiệu như văn bản và sơ đồ, để một người có đủ kinh nghiệm và trí tuệ có thể hình dung ra một mô hình tinh thần tương tự. Nói cách khác là muốn cài lý thuyết của tôi vào trong đầu người khác
Loại lý thuyết mà Naur nói tới không thể cấy ghép trực tiếp, nhưng tôi cho rằng công việc của senior developer, dù trong lớp học hay ngoài hiện trường, là kéo kinh nghiệm vào và tìm cách tái tạo loại lý thuyết đó. Vì thế kỹ năng giao tiếp rất quan trọng, và phải nhiều lần trải qua quá trình nhận lấy lý thuyết vận hành từ người khác thì mới hình thành được bản năng hiệu quả
Giờ đây đây đã trở thành phần đáng làm nhất trong công việc của tôi, và chừng nào tôi còn cảm thấy mình thực hiện tốt chức năng này thì tôi chưa muốn vội nghỉ hưu
Khi đào tạo và mentoring cho junior, tôi cố cho họ thấy điều gì khả thi và những mẫu hình dẫn tới thất bại, nhưng quá trình đào tạo đó phần lớn vẫn rời rạc và không hoàn chỉnh
Tôi cố giải thích càng nhiều càng tốt vì sao phải làm như vậy, nhưng không có quá nhiều thứ mà tôi cấm tiệt kiểu “đừng bao giờ làm”. Tôi thường xuyên ngạc nhiên trước cách những người tôi dạy giải quyết vấn đề, và bản thân tôi cũng thường học được nhiều điều
Việc đào tạo kém hiệu quả hơn với những người không quan tâm đến đóng góp của bản thân và chỉ xem công việc là công cụ kiếm lương. Không phải nghĩ vậy là sai, nhưng nếu xây dựng thế giới quan về công việc trên nền tảng thờ ơ thì rất khó nội hóa được sự đào tạo
https://andymatuschak.org/books/
Là một senior developer, tôi thực sự ghét những khẳng định bao trùm một kiểu
Tôi đã thấy các trường hợp thất bại vì kiểu thái độ như “Cái này thật sự cần không?”, “Nếu không làm thì sẽ xảy ra chuyện gì?”, “Cứ chống đỡ trước rồi sau quay lại khi nó quan trọng hơn được không?”, cũng nhiều như các trường hợp thất bại vì những người thích thử nghiệm
Mỗi hệ thống khác nhau và mỗi sản phẩm khác nhau. Nếu bạn đang làm firmware cho máy CT scanner thì cách tiếp cận với việc thử cái mới phải khác với một CRUD SaaS có 100 khách hàng
Chắc chắn có những senior quá nhiệt tình và quá cởi mở khiến hệ thống bị dồn vào góc khó thoát ra, nhưng cũng có những người nói rằng PHP5 là đủ rồi
Senior giỏi phải biết nhận ra thời điểm đó
Thế là chuyện này biến thành kiểu phải nghe lời phó chủ tịch khi ra quyết định công nghệ và dùng Elasticsearch
Dĩ nhiên có lúc cần hành động, nhưng hiện nay cán cân đang nghiêng quá mức về phía làm mọi thứ phức tạp hơn cần thiết
Không phải là đừng tạo sản phẩm và dịch vụ mới, mà là khi tạo thì hãy tìm con đường có entropy tổng thể thấp nhất. Điều đó cũng áp dụng cho vận hành và giảm technical debt
Tối ưu hóa quá sớm là nguồn gốc của mọi điều xấu
Tùy là startup hay tập đoàn lớn đã có dòng tiền mạnh mà đánh giá khi thay đổi tính năng cốt lõi của sản phẩm sẽ khác nhau
Tôi thấy bài viết khá thú vị và đồng ý với thông điệp cốt lõi là giao tiếp tốt hơn theo đúng đối tượng
Tuy vậy, cách đóng khung vấn đề có cảm giác bắt đầu đúng hướng rồi hơi lệch sang một hướng khác
Cả hai vòng lặp được nêu ra đều có lợi nếu dày hơn và nhanh hơn. Một cái đưa hệ thống nhanh hơn tới điểm cân bằng “ổn định” và dễ bảo trì, cái còn lại xử lý sự bất định
Cả nhận định bổ sung rằng nên chia nhỏ hệ thống để thích ứng với AI tốt hơn cũng là điều mà người ta đã giải thích bằng spike từ rất lâu trước khi AI trở thành xu hướng chính
Tôi nhận ra rằng mong muốn truyền đạt và chia sẻ chuyên môn của mình thường không có nhu cầu từ các junior developer
Nhìn chung, các developer không quan tâm đến việc tìm mentor. Họ cũng không xem hồ sơ LinkedIn, và không nhìn tôi như một nguồn tri thức hay chuyên môn tiềm năng
Không phải sau 30 năm trong ngành mà tôi không có gì để chia sẻ, mà là không có ai để chia sẻ cùng
Một developer ít kinh nghiệm đề xuất thay bộ kiểm tra URL bằng phép màu AI, còn tôi phản đối và đề xuất một giải pháp fuzzy matching dựa trên cache được điền sẵn bằng AI, nhưng chẳng ai quan tâm. Giờ thì model AI đột ngột bị gỡ xuống và hệ thống vỡ tung. Toàn bộ hệ thống phải được kiểm định lại
Một developer trẻ được thăng chức trước tôi đã viết tài liệu về cách sửa chuyện này rồi nói “Dan, anh có thể giúp em vụ này không?”. Anh ta được thăng chức vì cách tiến lên là viết tài liệu và họp hành thay vì làm việc hợp lý, còn giờ lại muốn dùng công sức của tôi để chứng minh năng lực lãnh đạo
Càng đề xuất giải pháp tốt hơn thì tôi càng trở thành mối đe dọa với các developer ít kinh nghiệm, và vì phần lớn mọi thứ vẫn tạm chạy nên manager cũng không bận tâm. Có lẽ tôi cũng có thể xử lý chuyện này tốt hơn, nhưng việc chiến đấu với những lời nhảm nhí quá mệt mỏi và tôi chỉ muốn viết code tốt
Trong khi đó các junior lại muốn nói chuyện, ăn trưa và chia sẻ mình đang làm gì. Các senior thì khép kín và cô lập
Có thể chỉ riêng nơi làm việc của chúng tôi như vậy, nhưng văn phòng là quan trọng
Một số senior developer ở đó nổi giận khi junior đặt câu hỏi. Chỉ riêng việc hỏi một người đã làm 20 năm cũng đã cần dũng khí rồi, thế mà có đến 50% khả năng họ cư xử tệ
Đó là một trải nghiệm học tập tốt, và giờ tôi cố ý nỗ lực làm mentoring
Trong vài thập kỷ qua tôi đã mentoring ngắt quãng, và may mắn gặp được những mentee rất tuyệt. Tôi đã theo dõi một vài người gần 10 năm và giờ họ đang làm rất tốt
Tôi không có lời khuyên hữu ích hơn về cách tìm họ, nhưng những người như vậy thực sự tồn tại
Nhưng ngay sau khi tôi đến thì anh ấy thông báo nghỉ việc vì đã tìm được người kế nhiệm, và rốt cuộc chuyện đó không thực sự suôn sẻ với tôi
Phần lớn proof of concept mà tôi từng thấy khi có được lực kéo thì đều trở thành production
Đã có vài lần mọi người cùng hứa rằng “nếu nó cất cánh thì ta sẽ viết lại từ đầu”, nhưng chuyện đó không xảy ra
Bài viết đụng đến trách nhiệm và accountability, nhưng với những người chấp nhận rủi ro thì những thứ đó không tồn tại. Họ vội vàng tung ra ý tưởng điên rồ và mong khách hàng cắn câu rồi hưởng lợi. Làm sao để nó vận hành và mở rộng được, làm sao để chi phí vận hành không vượt giá bán, đó không phải vấn đề của họ
Đã có những công ty đẩy vòng lặp bên phải tới cực đoan, và hiện giờ có hai công ty như thế rất nổi tiếng. Họ tung ra thứ gì đó thật nhanh rồi chỉ mở rộng tuyến tính, sau đó đi gọi vốn. Đó là những công ty thành công, có vô số người dùng và một phần còn trả tiền. Bất kỳ senior developer hay người hợp lý nào đặt câu hỏi “cái này có bền vững không, lối thoát là gì” đều bị sa thải, và người ở lại chỉ còn là tín đồ
Nếu kỹ sư chỉ ngoan ngoãn làm theo điều stakeholder không chuyên kỹ thuật yêu cầu thì sẽ xuất hiện khoảng trống trách nhiệm, và đến một ngày nó nổ tung như thảm họa thì người kém khả năng tự bảo vệ nhất sẽ bị đổ lỗi
Ngược lại, nếu mở rộng tầm nhìn đủ nhiều và hỏi đủ nhiều về “tại sao”, thì gần như mọi bài toán kinh doanh đều có thể được giải theo cách hợp lý mà không đẩy hệ thống vào một cánh cửa một chiều kinh khủng
Không phải nơi nào cũng trao quyền đó cho kỹ thuật, nhưng nơi nào không trao thì cũng không giữ được các senior vốn muốn làm ở chỗ có phán đoán của mình được tôn trọng. Đôi khi technical debt là lựa chọn đúng về mặt kinh doanh, nhưng kỹ sư đủ senior luôn có thể chuẩn bị sẵn đường rút
Tuy vậy cũng không thể đặt sự thuần khiết của hệ thống cao hơn vấn đề kinh doanh. Chi phí hệ thống là do doanh nghiệp chi trả, nên nếu quên điều đó thì cũng mất luôn nền tảng tạo ảnh hưởng
Kết luận của bài viết thực ra gần như là lời khuyên cũ: “hãy xây một cái với kế hoạch sẽ vứt nó đi”. Tôi cũng đã đọc Mythical Man-Month, nhưng vấn đề là làm sao thuyết phục người có quyền quyết định
Nếu không đạt kỳ vọng thì tính năng sẽ bị tắt hoặc xóa, còn nếu không thì sau khi đánh giá sẽ được refactor cho đúng nghĩa
Nhóm có mức tự chủ cao và gần như không có phàn nàn về tiến độ, chủ yếu vì các bộ phận khác còn chậm hơn. Chỉ riêng marketing là lúc nào cũng có “ý tưởng”
Việc nó là prototype hay proof of concept tự thân vốn không quan trọng, nếu bạn không thể liệt kê vấn đề thực tế là gì
Tôi thấy nhiều nhóm than phiền rằng mình chìm trong technical debt, rằng đó là rủi ro lớn và làm chậm tiến độ, nhưng trong hồ sơ sự cố lại không có nhiều incident, cũng không có gì cho thấy là do chạy code nguy hiểm trên production. Trong sổ đăng ký rủi ro cũng không có mục nào kiểu “đoạn code này cũ kỹ, tệ hại và phụ thuộc vào thứ đã hết hỗ trợ”, và cũng chẳng nhóm nào giải thích được technical debt đang làm họ chậm đi như thế nào và bao nhiêu
Ngược lại, tôi cũng thấy có nhóm đã refactor suốt nhiều tháng trước khi phát hành chỉ vì nghĩ rằng có thể làm ứng dụng của mình “tốt hơn”. Mọi việc tạo ra giá trị đều bị trì hoãn, ban lãnh đạo tất nhiên nổi giận và niềm tin gần như cạn sạch
Cần có những cuộc trao đổi tốt giữa nhóm và stakeholder về việc bàn giao thì tất cả mới hài lòng, nhưng nếu không có thì stakeholder luôn thắng
Bạn đang bỏ qua vấn đề cốt lõi là động lực khuyến khích. Điều “công ty” muốn không quan trọng, điều quan trọng là những người đưa ra quyết định cụ thể muốn gì
Có những người giữ được công việc chỉ bằng cách tung ra tính năng hay ứng dụng mới để nó xuất hiện đâu đó trong các chỉ số của công ty. Dù senior developer nói đó là ý tưởng tồi thì họ cũng không nghe hoặc không quan tâm, vì việc làm của họ phụ thuộc vào đó
Nhưng nếu là phía sản phẩm thì phải điều chỉnh tính năng theo nhu cầu khách hàng, nên cần bảo nhà nghiên cứu ngừng ép tiến độ lại
Senior thật sự giỏi là người nắm được văn hóa chi phối ở công ty hiện tại là gì và 5 năm nữa sẽ cần gì, rồi thích nghi theo đó
Một startup 5 người có thể không cần thêm độ phức tạp làm giảm runway. Một công ty 500 người có thể cần độ phức tạp đó để giảm thiểu hiệu ứng bậc hai của mọi quyết định kinh doanh
Không phải kiểu tư duy trắng đen “luôn tránh độ phức tạp”, mà là “hãy thêm độ phức tạp khi nó hợp lý”, và ngay cả câu hỏi đó cũng trở nên rất tinh tế khi doanh nghiệp đang ở tình thế phải sống thêm vài tháng nữa
Nếu chỉ còn hai giờ trước khi cơn bão tới, bạn sẽ không nghĩ về kiến trúc mà sẽ hỏi “nước có dâng quá nhiều đến mức không thể tát ra được nữa không?”
Vấn đề tôi thấy là ban điều hành không nói thật công ty còn bao nhiêu tiền, lịch trình thực sự ra sao, mà cứ chơi trò ú tim. Họ sợ contributor sẽ bỏ đi trước thời khắc quan trọng, nhưng như vậy thì mọi người vẫn tiếp tục đưa ra quyết định ngớ ngẩn trong bối cảnh đó và cuối cùng ai cũng đi tìm việc mới
Vài ngày nay tôi cũng đang cố truyền đạt gần như đúng cảm giác này cho team, đặc biệt là câu “Chúng ta có thực sự cần xây toàn bộ tính năng mới và test nó không? Hay chỉ cần thêm một nút vào UI hiện tại rồi xem người ta có bấm không?” gần như giống hệt
Có vẻ như toàn bộ kỹ sư đang cùng nhau đau khổ sau khi phía sản phẩm quyết định rằng họ không còn cần dùng đến năng lực tư duy của mình nữa. Cứ xây trước đi, rồi persona người dùng và tính hữu ích để sau, hoặc không bao giờ, hẵng tìm hiểu
Trước đây người ta dành thời gian để hiểu domain, hiểu người dùng và sản phẩm phù hợp với quy trình nào, còn giờ thì chỉ phát hành thứ mà họ nghĩ là người dùng tưởng tượng sẽ muốn, rồi thử nghiệm cho đến khi thành công
Chính xác là vấn đề mà bài gốc nói đến. Mỗi tính năng ngẫu nhiên được làm bằng vibe coding đều trở thành một nguồn bất ổn và rủi ro, và vì không ai có mô hình tinh thần vận hành về đối tượng đó nên nó chỉ còn có thể được bảo trì bằng nhiều vibe coding hơn nữa
Ngay cả khi có thể rút gọn độ phức tạp thành một chiều đo duy nhất, đó vẫn chỉ là một trong nhiều yếu tố của không gian lời giải
Còn có các thuộc tính khác như khả năng bảo trì, khả năng mở rộng, độ tin cậy, khả năng phục hồi, antifragility, khả năng scale, tính tổng quát, độ bền lâu, khả năng kết hợp, và không phải lúc nào tất cả cũng áp dụng
Tôi cho rằng khả năng nói về trade-off trong không gian lời giải thay vì một chiều đo đơn lẻ là điểm khác biệt giữa senior developer và Staff+ developer
Ngược lại, nếu hiểu đó là yếu tố sẽ giúp việc phát triển hệ thống này trong 10 người-năm tới trở nên dễ và nhanh hơn, thì nó có nghĩa là chọn cách đi vòng sang bên ở chỗ mà cách tiếp cận ngây thơ đang cố lao thẳng vào
Giống như câu chuyện rùa và thỏ, nhịp độ đốt cháy hai tuần đầu để hái quả thấp, lấy thành quả dễ thấy và MVP, rồi tốc độ cứ giảm dần vì thiết kế non nớt và gánh nặng bảo trì trong lúc phát triển, là điều khó nhận ra. Trong vài tuần đầu nó có vẻ “nhanh”, nhưng rốt cuộc lại làm lịch bị trễ 6 tháng
Nhưng là lập trình viên thì cuối cùng phải nhận ra rằng mọi khía cạnh có thể có của thiết kế đều là trade-off