# Xuất sắc kỹ thuật từ biên giới

David Heinemeier Hansson
6 tháng 9, 2025

Những đội ngũ kỹ thuật xuất sắc nhất luôn nắm quyền kiểm soát công cụ của họ. Họ giúp phát triển các framework và thư viện mà họ phụ thuộc vào, và họ làm điều này bằng cách chạy mã sản phẩm trên biên — phiên bản tiếp theo chưa được phát hành. Đó là nơi tiến bộ được tạo ra, đó là nơi sự tham gia quan trọng nhất.

Ban đầu, điều này có vẻ đáng sợ. Biên? Không phải đó chỉ là một từ khác cho nguy hiểm sao? Và nếu có lỗi thì sao? Đúng vậy, nếu sao? Bạn nghĩ rằng lỗi mã chỉ đơn giản là xuất hiện hoặc biến mất một cách tự nhiên? Không, chúng được đặt vào đó bởi các lập trình viên và cũng được loại bỏ bởi chính những người đó. Nếu bạn muốn có framework và thư viện không có lỗi, bạn phải làm việc để đạt được điều đó, nhưng nếu bạn làm được, phần thưởng cho trách nhiệm của bạn là sự xuất sắc kỹ thuật ngày càng tăng.

Lấy Rails 8.1 làm ví dụ. Chúng tôi vừa phát hành phiên bản beta đầu tiên tại Rails World, nhưng Shopify, GitHub, 37signals và một vài đội tiên phong khác đã chạy đoạn mã này trong môi trường sản phẩm gần như cả năm rồi. Tất nhiên, đã có một số lỗi trên đường đi, nhưng các bài kiểm tra tự động tốt và các lập trình viên tận tâm đã phát hiện gần như tất cả chúng trước khi chúng đến được sản phẩm.

Không phải lúc nào cũng như vậy. Một thời gian trước, tôi cảm thấy mình là trong số ít đội ngũ chạy Rails trên biên trong môi trường sản phẩm. Nhưng bây giờ hai ứng dụng web quan trọng nhất thế giới đang làm điều tương tự! Ở quy mô và mức độ quan trọng đáng kinh ngạc.

Điều này đã cho phép cả hai công ty, và một vài người khác có cùng tham vọng tiên phong, nuôi dưỡng một nền văn hóa kỹ thuật thực sự tinh hoa. Một nền văn hóa không chỉ là người tiêu phần mềm mã nguồn mở, mà là người đồng sáng tạo theo thời gian thực. Đây là một bước nhảy vọt về năng lực và sự thành thạo cho bất kỳ đội ngũ nào.

Đây cũng là một động lực tăng cường đáng kinh ngạc. Khi các lập trình viên của bạn có thể trực tiếp ảnh hưởng đến công cụ họ đang làm việc, họ sẽ có nhiều khả năng làm điều đó hơn, và do đó, họ đào sâu hơn, học hỏi nhiều hơn và tạo ra kết nối với các chuyên gia ở những nơi khác trong tình huống tương tự. Nhưng điều này đòi hỏi phải có thể ngay lập tức sử dụng những cải tiến hoặc sửa lỗi mà họ giúp thiết kế. Điều này không hiệu quả nếu bạn chỉ ngồi chờ đợi phiên bản tiếp theo trước khi dám tham gia.

Nhiều công ty hơn có thể làm điều này. Nhiều công ty hơn nên làm điều này. Dù đó là với Ruby, Rails, Omarchy hay bất cứ thứ gì bạn đang sử dụng, đội ngũ của bạn có thể nâng cấp cấp độ bằng cách tham gia nhiều hơn, nhận trách nhiệm tìm kiếm vấn đề trên biên, và gặt hái phần thưởng của sự xuất sắc trong quá trình đó. Vậy bạn đang chờ đợi gì?

## Về David Heinemeier Hansson

Đồng sở hữu và CTO của 37signals, đã tạo ra Basecamp và HEY dành cho những người bị bỏ lại phía sau. Người sáng tạo ra Ruby on Rails. Tác giả của REWORK, It Doesn’t Have to Be Crazy at Work, và REMOTE. Đã chiến thắng ở Le Mans với tư cách là tay đua. Đầu tư vào các startup của Đan Mạch.

Đăng ký để nhận các bài viết tương lai qua email (hoặc lấy nguồn RSS)

Đăng ký

Được gửi đến thế giới với HEY