Mời bạn thưởng thức Newsletter #70.

The developer productivity paradox: Why faster coding doesn’t mean faster software delivery

Bài viết khám phá Nghịch lý Năng suất Nhà phát triển, nơi các công cụ AI giúp lập trình nhanh hơn nhưng chỉ số tổ chức lại không cải thiện. Mặc dù 90% nhà phát triển sử dụng AI và 80% cảm thấy năng suất hơn, sự bất ổn hệ thống lại tăng do AI có tỷ lệ dự đoán sai cố hữu. Vấn đề gốc rễ là chuyển đổi ngữ cảnh đã hấp thụ lợi ích năng suất, và AI giới thiệu các gián đoạn mới trong quá trình xác thực và gỡ lỗi. Giải pháp là tổ chức cần Kỹ thuật Năng suất Nhà phát triển (DPE) để củng cố hệ thống phân phối, thiết kế lại quy trình làm việc cho hiệu quả luồng công việc, và thay đổi cách đo lường từ các chỉ số hoạt động sang các chỉ số luồng/kết quả.

Điểm chính:

• 90% nhà phát triển dùng AI nhưng sự bất ổn hệ thống vẫn tăng
• Chuyển đổi ngữ cảnh hấp thụ lợi ích năng suất từ AI
• Cần framework DPE: củng cố hệ thống phân phối, thiết kế lại quy trình làm việc, đo lường kết quả
• Đầu tư vào kỹ thuật nền tảng, vòng lặp phản hồi CI/CD, quản lý luồng giá trị

What Actually Makes You Senior

Kỹ năng cốt lõi phân biệt các kỹ sư cấp cao là giảm thiểu sự mơ hồ. Trong khi các kỹ sư cấp trung xuất sắc với các vấn đề được định nghĩa rõ, các kỹ sư cấp cao biến các yêu cầu mơ hồ như “cải thiện hiệu suất” thành các kế hoạch cụ thể và có thể thực hiện được. Các kỹ sư cấp cao hỏi các câu hỏi quan trọng: “Chúng ta thực sự đang cố gắng giải quyết vấn đề gì?” và “Ai là người dùng ở đây và điều gì gây khó khăn cho họ?” Họ xác định các giả định ẩn và đánh giá các nhược điểm tiềm tàng. Giá trị của họ nằm ở việc giảm thiểu rủi ro dự án bằng cách làm cho các vấn đề trừu tượng trở nên cụ thể.

Bài viết chỉ trích các phương pháp tuyển dụng hiện tại tập trung vào kỹ năng kỹ thuật thay vì giảm thiểu sự mơ hồ, lưu ý rằng nhiều kỹ sư “cấp cao” có thể giải quyết các vấn đề được định nghĩa rõ nhưng lại bị tê liệt với các thông số kỹ thuật không rõ ràng. Tác giả gợi ý rằng cấp độ cao có thể được phát triển qua thực hành, bắt đầu với các ticket mơ hồ và học cách làm rõ chúng ngay từ đầu thay vì chờ đợi người khác hoặc lập trình ngay lập tức. Công việc cấp cao thường trông vô hình khi làm tốt - các dự án đơn giản chạy trơn tru với ít bất ngờ hơn.

Điểm chính:

• Kỹ năng cốt lõi: giảm thiểu sự mơ hồ, không chỉ giải quyết các vấn đề được định nghĩa rõ
• Các kỹ sư cấp cao hỏi “Chúng ta thực sự đang giải quyết vấn đề gì?” và “Ai là người dùng?”
• Giá trị nằm ở việc giảm thiểu rủi ro dự án bằng cách làm các vấn đề trừu tượng trở nên cụ thể
• Phương pháp tuyển dụng sai lầm khi tập trung vào kỹ năng kỹ thuật thay vì giảm thiểu sự mơ hồ
• Cấp độ cao có thể phát triển qua thực hành với các ticket mơ hồ

Becoming unblockable

Tác giả cung cấp các chiến lược cụ thể để trở nên “không thể bị chặn” - duy trì tiến độ về phía trước bất chấp trở ngại. Lời khuyên chính bao gồm: làm việc trên nhiều nhiệm vụ đồng thời để chuyển giữa luồng công việc khi một trong số bị chặn; sắp xếp thứ tự dự án để xử lý các rào cản tiềm tàng sớm (phần gây tranh cãi, các phụ thuộc); ưu tiên môi trường phát triển ổn định sử dụng các công cụ tiêu chuẩn để tối đa hóa thời gian hiệu quả; gỡ lỗi các vấn đề ngoài khu vực trách nhiệm thay vì chờ đợi các đội khác; xây dựng mối quan hệ với các kỹ sư trên các đội khác để có sự hợp tác không chính thức nhanh hơn; tận dụng các quản lý cấp cao làm “hỗ trợ từ trên cao” để xóa các rào cản tổ chức; và chọn các dự án phù hợp với các ưu tiên của công ty để có sự ủng hộ của nhà điều hành.

Tác giả nhấn mạnh rằng việc bị chặn thường phụ thuộc vào sự chuẩn bị, các mối quan hệ, và quản lý dự án chiến lược thay vì các hoàn cảnh bên ngoài. Việc trở nên không thể bị chặn không phải là kỹ thuật mà là sự kết hợp của lập kế hoạch, xây dựng mạng lưới, và tư duy chiến lược.

Điểm chính:

• Làm việc trên nhiều nhiệm vụ để chuyển đổi khi bị chặn
• Sắp xếp thứ tự dự án để giải quyết các rào cản sớm
• Môi trường phát triển ổn định với các công cụ tiêu chuẩn
• Gỡ lỗi các vấn đề ngoài trách nhiệm thay vì chờ đợi
• Xây dựng mối quan hệ liên đội để hợp tác nhanh hơn
• Tận dụng các quản lý cấp cao làm hỗ trợ từ trên cao
• Chọn các dự án phù hợp để có sự ủng hộ của nhà điều hành

Treat test code like production code

Bài viết lập luận rằng mã kiểm thử nên được đối xử với cùng tiêu chuẩn như mã sản xuất vì nó cần bảo trì và khả năng đọc hiểu. Các vấn đề phổ biến trong mã kiểm thử bao gồm vi phạm nguyên tắc DRY, mã zombie, các chờ đợi tùy ý, và xử lý không đồng bộ không phù hợp. Tác giả nhấn mạnh rằng các tiêu chuẩn mã hóa tồn tại chủ yếu cho sự hiểu biết của con người và khả năng bảo trì, không phải cho thực thi máy tính. Vì mã kiểm thử chiếm một phần đáng kể của cơ sở mã, áp dụng các phương pháp tốt như giữ nó DRY ngăn chặn các vấn đề như “Phẫu thuật Shotgun” nơi các thay đổi yêu cầu sửa đổi trên nhiều bài kiểm thử.

Bài viết tham khảo các Mẫu Kiểm thử xUnit như là tài nguyên toàn diện cho các phương pháp kiểm thử cụ thể và phản đối quan niệm rằng các bài kiểm thử nên là DAMP thay vì DRY, lưu ý rằng các cụm từ mang tính mô tả và có ý nghĩa không xung đột với việc tránh trùng lặp. Các ngoại lệ tồn tại, đặc biệt trong các phương pháp bảo mật - mã kiểm thử có thể mã hóa cứng mật khẩu và bỏ qua xác thực đầu vào vì nó không được triển khai đến sản xuất. Các miễn lệ đặc thù nền tảng cũng có thể áp dụng, như các quy tắc ConfigureAwait trong .NET hoặc các thể chế mồ côi trong Haskell.

Điểm chính:

• Mã kiểm thử cần cùng tiêu chuẩn như mã sản xuất cho khả năng bảo trì
• Các vấn đề phổ biến: vi phạm DRY, mã zombie, chờ đợi tùy ý, không đồng bộ không phù hợp
• Tiêu chuẩn mã hóa phục vụ sự hiểu biết của con người, không phải thực thi máy tính
• Áp dụng DRY trong các bài kiểm thử để ngăn chặn các vấn đề “Phẫu thuật Shotgun”
• Ngoại lệ cho bảo mật (mã hóa cứng mật khẩu) và các quy tắc đặc thù nền tảng
• Các Mẫu Kiểm thử xUnit là tài nguyên toàn diện cho các phương pháp kiểm thử

How good engineers write bad code at big companies

Bài viết giải thích tại sao các công ty công nghệ lớn lại tạo ra mã có chất lượng thấp đáng ngạc nhiên mặc dù tuyển dụng các kỹ sư có năng lực. Lý do chính là “các công ty lớn đầy rẫy các kỹ sư làm việc ngoài lĩnh vực chuyên môn của họ” do tỷ lệ nghỉ việc cao - hầu hết nhân viên chỉ ở lại “một hoặc hai năm” trước khi chuyển đến các đội khác hoặc công ty khác. Hầu hết các thay đổi mã được thực hiện bởi những người mới bắt đầu tương đối làm việc trong các cơ sở mã không quen thuộc. Các “lão làng” có kinh nghiệm bị quá tải và phát triển chuyên môn của họ là không chính thức thay vì có hệ thống.

Kỹ sư năng lực trung bình có năng lực nhưng “cố gắng làm hết sức trong một môi trường không được thiết lập để tạo ra mã chất lượng”. Các công ty công nghệ lớn cố tình ưu tiên sự linh hoạt nội bộ hơn chất lượng phần mềm. Các kỹ sư cá nhân không có sức mạnh để thay đổi động lực tổ chức này. Tác giả lập luận rằng mã xấu là không thể tránh khỏi trong các bối cảnh “kỹ thuật không thuần túy” nơi các kỹ sư làm việc dưới áp lực thời hạn trên các hệ thống không quen thuộc, đối lập với “kỹ thuật thuần túy” nơi các sai lầm chủ yếu cho thấy sự thiếu năng lực. Nguyên nhân gốc rễ là “hầu hết các kỹ sư công ty lớn bị buộc phải làm hầu hết công việc của họ trong các cơ sở mã không quen thuộc.”

Điểm chính:

• Mã xấu tại các công ty lớn do các kỹ sư làm việc ngoài chuyên môn
• Tỷ lệ nghỉ việc cao: kỹ sư chỉ ở lại 1-2 năm trước khi chuyển đội
• Hầu hết các thay đổi được thực hiện bởi người mới bắt đầu trong các cơ sở mã không quen thuộc
• Các công ty ưu tiên sự linh hoạt hơn chất lượng phần mềm
• Các kỹ sư cá nhân không có sức mạnh để thay đổi động lực tổ chức
• “Kỹ thuật không thuần túy” với áp限 thời hạn và hệ thống không quen thuộc tạo ra mã xấu

The Success Trap

Bài viết khám phá cách thành công có thể nghịch lý lại giới hạn tự do và các lựa chọn. Nghịch lý của Tiến bộ: Thành công cảm thấy như sự mở rộng nhưng thực sự lại thu hẹp các lựa chọn. Khi các cá nhân và tổ chức phát triển, họ đánh đổi tính có thể lựa chọn để tối ưu hóa, chuyển từ khám phá sang bảo vệ. Bẫy Thành công là một trạng thái nơi các thực thể trở nên quá giỏi trong việc khai thác các thế mạnh hiện có đến nỗi họ ngừng khám phá các cơ hội mới. Điều này tạo ra căng thẳng giữa khai thác (cải thiện những gì hoạt động) và khám phá (thử nghiệm những gì có thể hoạt động tiếp theo).

Các nghiên cứu trường hợp bao gồm: một kỹ sư cấp cao ngừng xây dựng công việc thực hành do thăng tiến sự nghiệp; Kodak thất bại trong việc đón chụp nhiếp ảnh kỹ thuật số mặc dù phát minh ra nó; và Radiohead cố tình tái tạo lại sau “OK Computer”. Các giải pháp bao gồm: thể chế hóa sự tò mò trong các tổ chức; duy trì nhiều bản sắc và tư duy người mới bắt đầu; đánh giá tốc độ học tập cao hơn sự ổn định hiệu suất; và thực hành “quản lý” - nắm giữ thành công một cách nhẹ nhàng và tối ưu hóa cho sự đổi mới.

Điểm chính:

• Thành công thu hẹp lựa chọn thay vì mở rộng chúng
• Bẫy thành công: quá giỏi khai thác hiện có, ngừng khám phá cơ hội mới
• Căng thẳng giữa khai thác (cải thiện hiện tại) và khám phá (thử nghiệm tương lai)
• Các giải pháp: thể chế hóa tò mò, duy trì tư duy người mới bắt đầu
• Đánh giá tốc độ học tập hơn sự ổn định hiệu suất
• “Tự do, không phải thành tựu, là thước đo thành công thực sự”

Writing a good CLAUDE.md

Bài viết giải thích rằng các tệp CLAUDE.md rất quan trọng để đưa Claude vào làm quen với cơ sở mã của bạn vì các LLM không có trạng thái và không biết gì về dự án của bạn khi bắt đầu phiên. Tệp nên bao gồm CÁI GÌ (ngăn xếp công nghệ, cấu trúc), TẠI SAO (mục đích), và LÀM THẾ NÀO (phương pháp làm việc) của dự án.

Các khuyến nghị chính bao gồm: ít hơn là nhiều hơn - giữ hướng dẫn tối thiểu vì các LLM có thể tuân theo khoảng 150-200 hướng dẫn một cách nhất quán, với các mô hình nhỏ hơn cho thấy sự suy giảm hiệu suất theo cấp số nhân; giữ nó súc tích - nhắm mục tiêu dưới 300 dòng, lý tưởng là dưới 60 dòng như cách tiếp cận của HumanLayer; tính phổ quát - chỉ bao gồm các hướng dẫn liên quan đến tất cả các nhiệm vụ để ngăn Claude bỏ qua nội dung; tiết lộ tiến bộ - lưu trữ các hướng dẫn cụ thể của nhiệm vụ trong các tệp riêng biệt và tham chiếu chúng thay vì bao gồm mọi thứ trong CLAUDE.md; tránh sử dụng Claude làm công cụ lint - sử dụng các công cụ lint truyền thống thay vì thực thi kiểu mã dựa trên LLM tốn kém; và tạo thủ công - không tự động tạo CLAUDE.md vì nó là “điểm đòn bẩy cao nhất của bộ điều khiển”.

Bài viết lưu ý rằng Claude thường bỏ qua CLAUDE.md khi cho rằng nội dung không liên quan, được củng cố bởi các lời nhắc hệ thống nói với Claude không phản hồi trừ khi “rất liên quan đến nhiệm vụ của bạn.”

Điểm chính:

• CLAUDE.md cần thiết để onboarding Claude vào codebase
• LLM có thể tuân theo 150-200 hướng dẫn nhất quán
• Giữ dưới 300 dòng, lý tưởng dưới 60 dòng
• Chỉ bao gồm hướng dẫn phổ quát cho tất cả các nhiệm vụ
• Sử dụng tiết lộ tiến bộ - tham chiếu các tệp riêng biệt
• Không tự động tạo - tạo thủ công là điểm đòn bẩy cao nhất

We should all be using dependency cooldowns

Bài viết lập luận rằng các thời gian chờ phụ thuộc là một cách miễn phí, dễ dàng và cực kỳ hiệu quả để giảm thiểu phần lớn các cuộc tấn công chuỗi cung ứng mã nguồn mở. Tác giả phân tích dòng thời gian tấn công điển hình, cho thấy cơ hội của kẻ tấn công thường rất nhỏ - thường chỉ vài giờ đến vài ngày giữa việc phát hành các gói độc hại và việc chúng bị loại bỏ bởi các kho lưu trữ thượng nguồn.

Các cuộc tấn công chuỗi cung cấp hầu hết tuân theo một mô hình tương tự: xâm phạm → phát hành phiên bản độc hại → người dùng tự động cập nhật → nhà cung cấp phát hiện → thượng nguồn loại bỏ. Các cửa sổ tấn công thường dưới một tuần (8/10 cuộc tấn công được phân tích là <7 ngày). Cuộc tấn công xz-utils là một trường hợp ngoại lệ đáng kể với khoảng 5 tuần.

Các thời gian chờ trì hoãn cập nhật phụ thuộc theo một khoảng thời gian nhất định, cho phép các nhà cung cấp bảo mật xác định các mối đe dọa trước khi người dùng áp dụng chúng. Đơn giản để thực hiện với cấu hình như cooldown: default-days: 7. Lợi ích bao gồm: hiệu quả thực nghiệm chống lại các cuộc tấn công có tầm nhìn cao; miễn phí để thực hiện với các công cụ như Dependabot, Renovate; khuyến khích hành vi tích cực từ các nhà cung cấp bảo mật; và có thể ngăn chặn 80-90% sự tiếp xúc với nỗ lực tối thiểu.

Điểm chính:

• Phụ thuộc cooldown miễn phí, dễ dàng và hiệu quả chống tấn công chuỗi cung ứng
• Cửa sổ tấn công thường dưới 7 ngày cho hầu hết các cuộc tấn công
• Đơn giản thực hiện: chỉ cần cấu hình cooldown days
• Miễn phí với Dependabot, Renovate và các công cụ tương tự
• Có thể ngăn chặn 80-90% sự tiếp xúc với nỗ lực tối thiểu