Management Mantras
Bài viết trên blog Stay SaaSy tổng hợp bốn “câu thần chú” dành cho người làm quản lý. Thứ nhất là “đừng ban ơn cho ai”: mọi việc ở công ty đều nên là việc quan trọng nhất có thể làm, nên khi ai đó nói “để tôi giúp bạn” thì đó thường là trách nhiệm vốn có của họ, là lỗ hổng trong quy trình, hoặc là hành động phá vỡ thứ tự ưu tiên. Từ đó dẫn tới nguyên tắc thứ hai: nhân viên không cần sự ban phát. Những gì công ty làm cho nhân viên là phần thưởng họ xứng đáng nhận hoặc là trách nhiệm của người quản lý, nên khi báo tin tăng lương mà nhân viên cảm ơn, hãy đáp rằng “không cần cảm ơn, bạn xứng đáng với điều đó”.
Nguyên tắc thứ ba là “tôi có thể sửa được”. Công ty càng lớn thì càng có nhiều người để đổ lỗi. Tác giả cho rằng ở những công ty tốt, nếu mọi dự án bạn tham gia đều thất bại thì bạn phải tự chứng minh mình không có lỗi, vì vậy người quản lý cần hướng dẫn đội nhận trách nhiệm với mọi vấn đề cản trở kết quả. Cuối cùng, quản lý là việc diễn ra hằng ngày: phần lớn công việc là những việc không dễ chịu như thúc đẩy mọi người làm tốt hơn, giải quyết xung đột và đưa ra phản hồi. Giá trị của người quản lý nằm ở việc thay đổi hành vi, và điều đó đến từ sự tích lũy của những lần nhắc nhở, hỗ trợ nhỏ mỗi ngày chứ không phải vài quyết định lớn hiếm hoi.
The Ultimate Guide to Programming Languages: Choosing the Right Tool for the Job
Bài viết trên DEV Community điểm qua năm ngôn ngữ lập trình phổ biến năm 2025 cùng điểm mạnh, điểm yếu của từng ngôn ngữ. Python dễ học, có hệ sinh thái thư viện phong phú cho học máy, khoa học dữ liệu, phát triển web và tự động hóa, nhưng chậm hơn các ngôn ngữ biên dịch và không hợp với ứng dụng di động. JavaScript là “ông vua” của web: chạy trực tiếp trên trình duyệt, dùng được ở phía máy chủ với Node.js và cho ứng dụng đa nền tảng với Electron hay React Native, đổi lại kiểu động dễ gây lỗi lúc chạy. Java là “ngựa thồ” của doanh nghiệp nhờ JVM, tính ổn định, khả năng mở rộng, dù cú pháp dài dòng và khởi động chậm với ứng dụng nhỏ. C++ mạnh về hiệu năng và khả năng kiểm soát tài nguyên, phù hợp cho game engine, hệ thống nhúng và mô phỏng, nhưng khó học và phải tự quản lý bộ nhớ. Rust là ngôi sao đang lên với sự an toàn bộ nhớ mà không cần bộ thu gom rác, hợp cho lập trình hệ thống, WebAssembly và mật mã, nhưng hệ sinh thái còn nhỏ.
Về xu hướng, Python vẫn dẫn đầu mảng học máy dù Julia đang tiến lên ở các tác vụ đòi hỏi hiệu năng; Solidity và Rust nổi bật trong lĩnh vực blockchain; còn Kotlin Multiplatform và Flutter (Dart) được ưa chuộng nhờ thống nhất việc phát triển cho di động, web và máy tính. Kết luận của tác giả: không có ngôn ngữ nào phù hợp với mọi trường hợp, và lựa chọn đúng phụ thuộc vào yêu cầu dự án, kinh nghiệm của đội và mục tiêu dài hạn.
Discovery Coding
Jimmy Miller mượn một sự phân biệt quen thuộc trong giới viết văn: có người lập dàn ý trước, có người khám phá câu chuyện ngay trong lúc viết. Tác giả gọi phiên bản trong lập trình là “Discovery Coding” (lập trình khám phá), tức hiểu vấn đề bằng cách viết mã nguồn trước thay vì thiết kế kỹ từ đầu. Người lập trình khám phá tự hỏi đoạn mã mới cần giải quyết điều gì, các phần của hệ thống tương tác ra sao, và chỉ khi viết mã, thấy hệ thống “phản kháng” thế nào, họ mới vạch ra hướng đi. Cách làm này dễ bị xem là bừa bộn, nhất là khi văn hóa hiện nay chuộng hệ thống kiểu tĩnh và các công cụ ràng buộc chặt chẽ, nhưng tác giả nhấn mạnh cần tách quá trình sáng tạo khỏi sản phẩm cuối: người lập trình khám phá vẫn có thể tạo ra kết quả chặt chẽ.
Theo tác giả, ngay cả người quen lập dàn ý cũng được lợi: vì không mang sẵn giải pháp, việc viết mã để thăm dò giúp tránh cái bẫy áp dụng lời giải quen thuộc và nạp vào đầu những ràng buộc thực sự của hệ thống. Các công cụ như lập trình trực tiếp trên hệ thống đang chạy (kiểu Clojure hay Smalltalk) và trực quan hóa tức thời rất hữu ích cho lối làm việc này. Bài viết kết thúc bằng lời kêu gọi cộng đồng chấp nhận rằng mỗi người tư duy một kiểu: kém ngăn nắp hơn không có nghĩa là kém hiệu quả hơn, và thiết kế phần mềm suy cho cùng là một quá trình của con người.
Building a best-selling game with a tiny team
Tập podcast The Pragmatic Engineer này có khách mời Jonas Tyroller, một trong hai nhà phát triển của Thronefall, trò chơi chiến lược tối giản kết hợp thủ thành và xây dựng vương quốc, bán được khoảng 1 triệu bản trong năm đầu. Jonas dùng Unity, C# và Blender; mỗi màn chơi là một cảnh chứa các đối tượng được gắn script điều khiển hành vi. Điều bất ngờ là đội không review mã nguồn, không viết kiểm thử đơn vị và đẩy thẳng lên nhánh chính: với một trò chơi nhỏ chỉ phát hành một lần và hai lập trình viên giàu kinh nghiệm, các thực hành này không đáng công sức, dù chúng sẽ quan trọng hơn ở dự án lớn. Lỗi chủ yếu được phát hiện qua việc tự chơi thử, thử nghiệm beta và phản hồi của người chơi sau khi ra mắt.
Quy trình bắt đầu bằng giai đoạn làm mẫu thử, mỗi mẫu chỉ mất 1–2 ngày, ưu tiên lối chơi trước rồi mới đến hình ảnh, nhằm tìm ý tưởng vừa bán được vừa khiến chính đội thích làm. Thách thức kỹ thuật lớn nhất là tìm đường đi cho các đơn vị: đội mua một plugin dùng thuật toán A* rồi tùy chỉnh để chuyển động trông tự nhiên. Jonas còn dùng ChatGPT để sinh mã khung, chuyển đổi mã shader và hỏi về những chủ đề chưa quen. Những bài học rút ra: làm game độc lập đòi hỏi rất nhiều kỹ năng, từ thiết kế, lập trình, soạn nhạc đến quảng bá; muốn giỏi thì phải làm thật nhiều game; và với Unity cùng vô số tài liệu hướng dẫn, làm game chưa bao giờ dễ như bây giờ.
Serving a billion web requests with boring code
Bill Mill kể lại quá trình thiết kế hệ thống API cho trang so sánh gói bảo hiểm Medicare của chính phủ Mỹ, nơi hàng triệu người tìm và mua gói bảo hiểm y tế. Hệ thống phục vụ khoảng 5 triệu yêu cầu mỗi ngày, độ trễ trung bình dưới 10 mili giây, và tổng cộng hơn một tỷ yêu cầu. Kim chỉ nam của tác giả là chọn công nghệ “nhàm chán” theo tinh thần bài “Choose Boring Technology”: PostgreSQL, Go và React. Hai canh bạc duy nhất là chia phía máy chủ thành ba module lớn (druginfo, planinfo, beneinfo), mỗi module có cơ sở dữ liệu riêng, và dùng gRPC để giao tiếp giữa chúng. gRPC giúp định nghĩa giao diện bằng mã nhưng bộ công cụ rườm rà, và tác giả thừa nhận có lẽ không dùng thì tốt hơn; ngược lại grpc-gateway phục vụ hơn một tỷ yêu cầu mà chưa từng gây sự cố.
Nhiều quyết định khác cũng đề cao sự đơn giản: tuân thủ tương thích ngược nghiêm ngặt (chỉ thêm, không xóa trường), làm tìm kiếm theo nhiều tiêu chí bằng cách ghép chuỗi truy vấn SQL trong một hàm dài nhưng được chú thích kỹ thay vì dùng Elasticsearch, và tạo lại cơ sở dữ liệu mỗi ngày bằng quy trình ETL chạy bằng shell script và cron, dùng lệnh COPY của PostgreSQL để nạp hơn 250 triệu dòng. Sai lầm lớn nhất theo tác giả là viết kiểm thử dựa trên giả lập SQL tốn nhiều công bảo trì, thay vì kiểm thử với cơ sở dữ liệu thật. Thông điệp chính: phần mềm chất lượng hoàn toàn có thể được xây dựng dưới những ràng buộc của khu vực nhà nước.
Java Language Evolution in 2025 - Inside Java Newscast #84
Tập Inside Java Newscast #84 điểm lại các hướng phát triển của ngôn ngữ Java trong năm 2025 thông qua Project Amber, dự án chuyên cải tiến cú pháp và tính năng ngôn ngữ. Các nội dung chính gồm thân hàm tạo linh hoạt (cho phép chạy lệnh trước khi gọi super() hoặc this()), hàm main đơn giản hóa giúp viết chương trình nhỏ gọn hơn, nhập cả module bằng một lệnh, và pattern matching cho kiểu dữ liệu nguyên thủy trong instanceof và switch. Video cũng bàn về những ý tưởng xa hơn như phân rã cấu trúc để trích xuất dữ liệu từ đối tượng, “withers” để tạo bản sao của record với vài giá trị được thay đổi, tiến độ của chuỗi mẫu (string templates) và cải tiến cơ chế tuần tự hóa. Đây là bản tóm lược hữu ích để lập trình viên Java nắm được ngôn ngữ đang đi về đâu và chuẩn bị tận dụng các tính năng mới.
Valhalla - Java’s Epic Refactor
Trong video này, Brian Goetz cập nhật tiến độ của Project Valhalla, dự án được ví như cuộc “tái cấu trúc vĩ đại” của Java nhằm hiện đại hóa hệ thống kiểu của ngôn ngữ. Mục tiêu là mang lại hiệu năng tốt hơn trong khi giúp việc lập trình trở nên đơn giản hơn, và video giải thích các tính năng mới cùng định hướng của dự án.
Protecting your time from predators in large tech companies
Thorsten Ball khẳng định AI chắc chắn sẽ thay đổi lập trình, dẫn chứng bằng loạt công cụ Claude đã viết giúp anh: một script Python chuyển RSS của bản tin thành Markdown, một MCP server cho Tailscale, hơn 200 dòng Rust và một máy chủ Go nhỏ hiển thị tệp Markdown, phần lớn chạy được ngay từ lần đầu. Dù AI chưa hiệu quả với mọi kho mã, việc viết và viết lại một số loại mã đã trở nên rất rẻ, và điều đó sẽ thay đổi nghề lập trình giống như trình biên dịch, Internet, quản lý phiên bản hay StackOverflow từng làm. Câu hỏi là thay đổi như thế nào.
Tác giả liệt kê hàng loạt câu hỏi mở: liệu ngôn ngữ mới có còn phổ biến được khi mô hình ngôn ngữ lớn thiếu dữ liệu huấn luyện cho chúng; liệu ta sẽ lưu prompt bên cạnh mã nguồn, hay chia mã thành nhiều chương trình nhỏ để AI dễ tiếp nhận; liệu CONTEXT.md có trở thành robots.txt mới, hướng dẫn AI hiểu kho mã; liệu sẽ xuất hiện một loại nợ kỹ thuật mới khi mã được tối ưu cho mô hình hiện tại; liệu trình biên dịch sẽ đưa ra thông báo lỗi giàu ngữ cảnh hơn để AI dễ sửa; và liệu tên hàm sẽ dài, rõ nghĩa hơn vì dễ hiểu hơn với AI. Bài viết không đưa ra đáp án, nhưng gợi mở nhiều hướng suy nghĩ đáng giá về tương lai của nghề.
Hands-On Career: The Evolution of a Java Champion
Peter Lawrey, nhà sáng lập Chronicle Software và là Java Champion năm thứ mười, chia sẻ góc nhìn sau hơn 30 năm viết mã về sự nghiệp lập trình trong thời AI tạo sinh. Ông mô tả tám hướng phát triển sự nghiệp, từ chiều sâu kỹ thuật, giải quyết vấn đề, cộng tác và giao tiếp đến hiểu biết kinh doanh và quản lý chiến lược, cùng cách trọng tâm dịch chuyển từ giai đoạn mới vào nghề đến các vai trò như kỹ sư chính hay kiến trúc sư giải pháp. Khi tự lập công ty, phạm vi trách nhiệm còn mở rộng sang bán hàng, tài chính, pháp lý và nhân sự. Giống như máy ATM không thay thế giao dịch viên ngân hàng mà khiến họ chuyển sang những việc giá trị cao hơn, lập trình viên cũng sẽ thích nghi và tìm đến những việc vẫn cần trí tuệ con người.
Về cách dùng AI, tác giả nhấn mạnh công cụ này mang tính thống kê chứ không tất định, nên kết quả chỉ có xác suất đúng và cần người có chuyên môn kiểm tra. Một mẹo thực tế là yêu cầu AI lập kế hoạch trước rồi mới thực hiện, vì cách này thường cho kết quả đầy đủ hơn; việc duy trì tài liệu yêu cầu và kế hoạch đi kèm dự án (phát triển hướng tài liệu) cũng giúp AI cho ra kết quả ổn định hơn. AI vẫn yếu ở khả năng tự đánh giá, phân tích số liệu và thẩm mỹ. Kết luận: khả năng chọn đúng mã nguồn quan trọng hơn khả năng viết mã, và AI không thể thay thế kinh nghiệm, kiến thức chuyên môn hay óc phán đoán.
Token Bucket Rate Limiter (Redis & Java)
Bài viết hướng dẫn triển khai thuật toán giới hạn tốc độ Token Bucket bằng Redis và Java. Ý tưởng là một “cái xô” được nạp token với tốc độ cố định, mỗi yêu cầu tiêu thụ một token và bị từ chối khi xô rỗng; nhờ xô có sức chứa tối đa, hệ thống vẫn chịu được các đợt tăng lưu lượng ngắn. Với Redis, mỗi client có hai khóa lưu số token và thời điểm nạp gần nhất; mỗi khi có yêu cầu, chương trình đọc hai giá trị này, tính số token cần nạp thêm theo thời gian đã trôi qua (không vượt quá sức chứa), trừ một token nếu còn, rồi ghi lại bằng giao dịch MULTI/EXEC. Tác giả dùng thư viện Jedis để xây dựng lớp TokenBucketRateLimiter, sau đó viết kiểm thử với Redis TestContainers, JUnit 5 và AssertJ cho các tình huống như cho phép yêu cầu trong sức chứa, từ chối khi hết token, nạp lại dần theo thời gian, xử lý độc lập nhiều client và không đếm các yêu cầu bị từ chối. Mã nguồn đầy đủ bằng Java và Kotlin có sẵn trên GitHub.
Bonus?
Huhu, đợt này hỏng có bonus nào hết nha mọi người :<
Bài viết đã được viết lại bởi Claude Code với Opus 5.5 vào ngày 27/09/2026.