Điều gì phân biệt một coder giỏi với một software engineer giỏi?

Question

Accepted Answer

Một **coder giỏi viết được code chạy đúng**. Một **software engineer giỏi giải quyết đúng vấn đề một cách toàn diện** — làm chủ requirements, thiết kế, các đánh đổi, khả năng bảo trì, testing, vận hành, và bối cảnh nghiệp vụ xung quanh đoạn code. Engineering là code cộng với khả năng phán đoán cộng với trách nhiệm trên toàn bộ vòng đời.

## Ranh giới thực sự nằm ở đâu

Viết code vượt qua được các test là phần dễ và có thể học. Phần khó hơn, giá trị hơn là tất cả những gì bao quanh nó: quyết định *cái gì* cần xây, nó *nên* khớp vào hệ thống ra sao, và *chi phí* sống chung với nó về sau là bao nhiêu.

- **Coder hỏi** "Làm sao để cái này chạy được?" và dừng lại khi nó chạy.
- **Engineer hỏi** "Chúng ta thực sự đang giải quyết vấn đề gì, ràng buộc là gì, và đâu là thiết kế rẻ nhất mà vẫn trụ được qua thay đổi?"

## Những gì engineer làm chủ ngoài đoạn code

- **Requirements** — làm rõ nhu cầu thực, chất vấn spec, phát hiện các edge case trước khi chúng thành sự cố.
- **Các đánh đổi** — cân nhắc tốc độ với sự đơn giản, tự xây với mua ngoài, bây giờ với sau này, và đưa ra lựa chọn một cách *rõ ràng*.
- **Thiết kế & khả năng bảo trì** — viết cho người đọc tiếp theo, giữ blast radius nhỏ, tránh complexity không cần thiết.
- **Testing & vận hành** — nghĩ về các kịch bản hỏng, observability, rollback, và chuyện gì xảy ra lúc 3 giờ sáng.
- **Giao tiếp** — giải thích quyết định, ghi chúng lại, và kéo người khác cùng đi.
- **Bối cảnh nghiệp vụ** — gắn công việc với kết quả, không chỉ là số ticket đã đóng.

## Một sắc thái hữu ích

Điều này **không** phải về thâm niên hay chức danh — nhiều "engineer" chỉ code, và một số "coder" thực sự làm engineering. Nó là một **lối tư duy**: nhận trách nhiệm về kết quả, không chỉ về sản phẩm đầu ra. Sự dịch chuyển là từ *"code của tôi chạy"* sang *"hệ thống này phục vụ đúng mục đích, một cách đáng tin cậy, và không hành hạ người chạm vào nó tiếp theo."*

## Tại sao điều này quan trọng

Người phỏng vấn và các team coi trọng engineer hơn coder bởi vì **bug, sự cố downtime, và những hệ thống không thể bảo trì hiếm khi đến từ code không compile được — chúng đến từ sự thiếu phán đoán**: câu hỏi không được hỏi, đánh đổi bị phớt lờ, edge case không được test. Thể hiện rằng bạn nghĩ về toàn bộ vòng đời — và có thể diễn đạt *vì sao* bạn chọn con đường này thay vì con đường kia — chính là điều cho thấy bạn có thể được tin tưởng với hệ thống thật và hậu quả thật, và đó đúng là cốt lõi của việc trưởng thành trong nghề này.