Lập trình viên không được trả tiền để viết code
03/07/2026
285
views
1
#5 on leaderboard of challenge:
Có một ngày, người quản lý giao cho tôi một tính năng mới.
Anh ấy chỉ nói rất đơn giản:
"Em thử thiết kế phần này trước nhé."
Tôi ngồi trước màn hình gần cả buổi sáng.
Không phải vì bài toán quá khó.
Mà vì tôi không biết phải bắt đầu từ đâu.
Suốt nhiều năm trước đó, công việc của tôi là đọc requirement, tạo vài file mới rồi bắt đầu viết code. Khi gặp bug thì debug, khi thiếu tài liệu thì đọc datasheet, khi hiệu năng chưa tốt thì tối ưu.
Tôi khá tự tin với khả năng lập trình của mình.
Nhưng lần đầu tiên phải tự thiết kế một hệ thống, tôi mới nhận ra mình hoàn toàn lúng túng.
Tôi không biết nên chia module như thế nào.
Không biết module nào nên chịu trách nhiệm cho việc gì.
Không biết có bao nhiêu state trong hệ thống.
Càng không biết vì sao nên chọn một kiến trúc này thay vì một kiến trúc khác.
Điều đáng buồn là... không ai dạy những điều đó.
Tôi làm trong lĩnh vực Embedded Software.
Ở trường đại học, chúng tôi học cấu trúc dữ liệu, giải thuật, vi điều khiển, hệ điều hành...
Đi làm, chúng tôi học framework, protocol, RTOS, Linux...
Nhưng rất ít nơi dạy cách biến một yêu cầu của khách hàng thành một bản thiết kế có thể triển khai.
Trong nhiều năm, tôi từng nghĩ:
"Chắc mình code chưa đủ giỏi."
Thế là tôi tiếp tục học.
Học ngôn ngữ mới.
Học framework mới.
Học cách tối ưu từng dòng code.
Nhưng càng học, tôi càng nhận ra vấn đề của mình không nằm ở coding.
Một lập trình viên có thể viết một hàm rất đẹp - Nhưng trước đó, phải có ai quyết định rằng hàm đó nên tồn tại.
Một lập trình viên có thể tối ưu bộ nhớ rất tốt - Nhưng trước đó, phải có ai quyết định cách chia dữ liệu.
Một lập trình viên có thể implement state machine hoàn hảo - Nhưng trước đó, phải có ai xác định hệ thống có những state nào.
Code luôn là bước cuối cùng.
Điều khó hơn nhiều là những quyết định diễn ra trước khi dòng code đầu tiên được viết.
Khoảng một năm trở lại đây, tôi thay đổi hoàn toàn cách học.
Tôi bắt đầu đọc về software architecture thay vì framework.
Tìm hiểu state machine thay vì chỉ học API.
Quan tâm đến trách nhiệm của từng module thay vì chỉ quan tâm hàm nên viết ở file nào.
Thậm chí tôi còn tự xây cho mình một checklist để mỗi khi nhận một feature mới, tôi có thể tự hỏi:
- Hệ thống này thực sự đang giải quyết vấn đề gì?
- Có những actor nào?
- Những state nào sẽ xuất hiện?
- Event nào làm hệ thống chuyển trạng thái?
- Module nào nên chịu trách nhiệm?
- Thành phần nào có thể thay đổi trong tương lai?
Ban đầu, việc trả lời những câu hỏi này mất rất nhiều thời gian.
Nhưng càng làm, tôi càng nhận ra mình không còn lao vào code ngay nữa.
Tôi dành nhiều thời gian hơn để suy nghĩ.
Và điều thú vị là tổng thời gian hoàn thành công việc lại ngắn hơn.
Ít bug hơn.
Ít phải sửa đi sửa lại hơn.
Ít tranh luận hơn khi review.
Rồi AI xuất hiện.
Nhiều người hỏi:
"AI viết code tốt như vậy thì lập trình viên còn giá trị gì nữa?"
Tôi nghĩ AI khiến tôi nhận ra một điều.
Nếu giá trị của tôi chỉ nằm ở việc viết code nhanh, thì sớm hay muộn AI cũng sẽ làm tốt hơn.
Nhưng AI vẫn cần một người xác định đúng bài toán.
Nó cần ai đó hiểu sản phẩm.
Hiểu người dùng.
Hiểu những ràng buộc về hiệu năng, bộ nhớ, chi phí và khả năng bảo trì.
Nó có thể đề xuất nhiều giải pháp.
Nhưng người chịu trách nhiệm chọn một giải pháp phù hợp vẫn là kỹ sư.
Có lẽ đó mới là giá trị khó thay thế nhất.
Nhìn lại chặng đường của mình, tôi không còn tin rằng chỉ cần code giỏi là đủ.
Coding rất quan trọng.
Nó là nền tảng.
Nhưng nó không phải là tất cả.
Khi sự nghiệp phát triển, chúng ta sẽ dành ít thời gian hơn để gõ bàn phím và nhiều thời gian hơn để phân tích, thiết kế, giao tiếp, đưa ra quyết định và chịu trách nhiệm cho những quyết định đó.
Có một câu mà tôi rất thích:
Code is easy. Deciding what to build is hard.
