Release checklist đang mở ở một tab, dashboard lỗi ở một tab khác, còn ly cà phê uống dở nằm cạnh bàn phím. Sáng hôm đó, không có gì trong tech stack trông thật thú vị. API dùng những công cụ nhiều engineer đã từng gặp. Database rất bình thường. Đường deploy có vài script cũ với những cái tên ai cũng hiểu. Và chính vì vậy, khi một lỗi nhỏ xuất hiện trước giờ release, ba người có thể cùng đọc log, lần theo luồng xử lý và thống nhất cách sửa mà không biến cả buổi sáng thành một buổi nghiên cứu framework.
Những khoảnh khắc như vậy hiếm khi trở thành câu chuyện được kể trong company all-hands. Ít ai hào hứng nói rằng team đã đi qua một ngày khó nhờ technology quen thuộc. Nhưng rất nhiều phần khỏe mạnh của software work nằm ở lợi thế yên lặng đó. Tech stack không cần được ngưỡng mộ. Nó cần giúp team build, debug, tuyển người, onboarding, vận hành và thay đổi sản phẩm mà không phải dùng quá nhiều năng lượng để chứng minh lựa chọn công cụ là thông minh.
Có một thời gian, tôi bị hấp dẫn bởi technology thú vị nhiều hơn mức tôi muốn thừa nhận. Một framework mới làm công việc có cảm giác tươi hơn. Một database khác gợi ý cách modeling sạch hơn. Một deployment platform mới hứa hẹn ít vấn đề cũ hơn và một mental model gọn hơn. Đôi khi sự tò mò đó có ích. Có những hệ thống thật sự cần công cụ mới vì công cụ cũ không còn gánh nổi yêu cầu. Nhưng cũng có lúc tôi không chọn công cụ tốt hơn. Tôi chọn một hình ảnh thú vị hơn cho chính công việc đó.
Giá trị của một tech stack nhàm chán là nó giữ sự chú ý ở sản phẩm và ở team. Khi language, framework, database và operational model đều quen thuộc, nhiều người hơn có thể tham gia vào cuộc trò chuyện. Một junior engineer có thể search lỗi và tìm được nhiều câu trả lời hữu ích. Một teammate mới có thể nhận ra hình dạng của project ngay trong tuần đầu. Một reviewer có thể tập trung vào business behavior thay vì vừa review vừa học triết lý của framework trong pull request. Technology trở thành một mặt sàn chung, không phải một cầu thang riêng.
Reliability thường lớn lên từ mặt sàn chung đó. Technology ổn định thường đã từng thất bại công khai trong nhiều năm. Những góc cạnh khó chịu của nó đã được viết lại trong tài liệu. Những lỗi kỳ lạ đã có forum thread, GitHub issue, migration note và những teammate từng vấp qua. Điều đó không làm nó hoàn hảo. Nó chỉ làm failure mode bớt bí ẩn hơn. Khi production chậm lúc nửa đêm, một stack quen thuộc cho team cơ hội tốt hơn để hỏi những câu quen thuộc: query nào vừa đổi, queue nào đang nghẽn, deploy nào chạm vào luồng này, metric nào dịch chuyển trước.
Tuyển dụng cũng thay đổi. Một stack hiếm có thể là lựa chọn đúng cho một bài toán hiếm, nhưng nó thu hẹp nhóm người có thể gia nhập với sự tự tin. Một stack quen thuộc cho team nhiều lựa chọn hơn: người có kinh nghiệm có thể đóng góp nhanh, engineer mới có nhiều tài liệu để học, contractor hoặc partner team có thể hỗ trợ mà không cần một lớp dịch thuật dài. Đây không chỉ là tiện lợi trong recruiting. Nó ảnh hưởng đến resilience. Một hệ thống khỏe hơn khi knowledge không tập trung vào đúng một người hiểu công cụ lạ.
Maintainability cũng có hình dạng tương tự. Phần khó của một codebase thường không phải viết phiên bản đầu tiên. Phần khó là sống cùng phiên bản thứ năm, sau khi product đã đổi ý, team đã đổi người, và context ban đầu đã mờ đi. Technology nhàm chán giúp vì nó làm những việc maintenance bình thường rẻ hơn: upgrade dependency, đọc code cũ, debug integration issue, thêm test, tìm ví dụ, và giải thích quyết định cho một người không có mặt từ đầu. Không việc nào trong số đó nghe có vẻ hào nhoáng. Nhưng cộng lại, chúng quyết định sản phẩm có tiếp tục đi được hay không.
Dĩ nhiên, nhàm chán không tự động đồng nghĩa với tốt. Một stack quen thuộc vẫn có thể trở nên cũ kỹ. Một team có thể núp sau sự thoải mái rồi gọi đó là thận trọng. Có những lựa chọn cũ mang chi phí thật: security posture yếu, performance không hợp workload, ecosystem không còn được hỗ trợ, hoặc không còn khớp với cách sản phẩm cần lớn lên. Stability chỉ có giá trị khi nó phục vụ hệ thống. Nếu một tool nhàm chán vì mọi người hiểu nó và nó vẫn hoạt động tốt, đó là sức mạnh. Nếu nó nhàm chán vì chưa ai đủ can đảm thay thế, đó là technical debt đang mang một gương mặt bình tĩnh.
Vì vậy quyết định này không hẳn là cũ hay mới, mà là chi phí của sự bất ngờ. Mỗi lựa chọn technology bắt team trả tiền cho learning, hiring, debugging, operations và future change. Đôi khi trả khoản đó là hợp lý, vì công cụ mới gỡ một bottleneck thật hoặc mở ra một capability sản phẩm thật sự cần. Đôi khi chi phí lại nằm ẩn trong onboarding, incident lúc khuya, tài liệu mỏng hơn, và một expert trở thành người không thể thiếu. Câu hỏi không phải innovation có tốt không. Câu hỏi là sự mới mẻ cụ thể này có xứng đáng với hệ thống cụ thể này không.
Tôi ngày càng tôn trọng những team có thể chọn technology nhàm chán mà không cần nói như đang tự vệ. Có một sự tự tin rất yên trong câu: chúng ta hiểu tool này, nó hợp bài toán, chúng ta tuyển được người cho nó, chúng ta vận hành được nó, và trade-off là chấp nhận được. Câu đó có thể không gây ấn tượng với người đứng ngoài. Nhưng bên trong công việc, nó tạo ra khoảng trống. Khoảng trống cho product thinking tốt hơn. Khoảng trống cho code review rõ hơn. Khoảng trống để một người nghỉ phép mà không lo cả hệ thống đứng lại. Khoảng trống để engineer tiếp theo gia nhập và đóng góp trước khi thấy mình lạc đường.
Tech stack tốt nhất hiếm khi là stack trông hiện đại nhất trên slide. Nó là stack mà team có thể mang chi phí của nó với đôi mắt mở. Đôi khi điều đó nghĩa là nhận một công cụ mới vì con đường cũ đang kéo sản phẩm lại. Đôi khi điều đó nghĩa là chọn công cụ ổn định, quen thuộc, và chấp nhận rằng quyết định ấy gần như vô hình khi mọi thứ chạy tốt.
Có lẽ đó là giá trị thật của một tech stack nhàm chán: nó không đòi làm nhân vật chính. Nó lặng lẽ giảm số việc mà team phải can đảm đối mặt mỗi tuần. Nếu bạn từng làm trong một hệ thống nơi một lựa chọn nhàm chán đã tiết kiệm thời gian, giảm rủi ro hoặc làm onboarding tử tế hơn, tôi rất muốn nghe câu chuyện phía sau lựa chọn đó.