[Series: Tư duy bứt phá] Phần 1: Bắt bệnh - Bạn đang "Build hệ thống" hay chỉ đang "Dịch task sang Code"?

Mỗi buổi sáng thứ Hai, bạn mở máy tính, nhấp một ngụm cà phê và mở bảng Jira (hay Trello, Asana) lên. Kéo một ticket từ cột To Do sang In Progress. Bạn đọc lướt requirement, mở IDE, gõ lạch cạch, commit code, tạo Pull Request và thở phào nhẹ nhõm khi QA pass.

Vòng lặp đó lặp lại ngày qua ngày. Mọi thứ trông có vẻ ổn. Bạn vẫn nhận lương đều, task vẫn done.

Nhưng hãy thành thật với nhau: Bạn đang thực sự xây dựng một hệ thống, hay chỉ là một cỗ máy "chuyển ngữ" từ tiếng Việt của BA/PO sang ngôn ngữ lập trình?

Nếu câu trả lời nghiêng về vế thứ hai, rất có thể bạn đang mắc kẹt ở hội chứng "Thợ gõ" (Coder) thay vì là một "Kỹ sư" (Software Engineer). Hôm nay, chúng ta sẽ cùng "bắt bệnh" một cách thẳng thắn nhất.

1. Hội chứng "Ticket-Driven Development" (Làm việc theo Ticket)

Đặc điểm dễ nhận diện nhất của Thợ gõ là sự phục tùng tuyệt đối vào requirement mà không có màng lọc tư duy phản biện.

• Thợ gõ: Đọc ticket "Làm API xuất báo cáo Excel cho admin". OK, viết một hàm query database, ném dữ liệu vào thư viện export, trả về file. Code chạy mượt mà ở local với 100 dòng data. Xong!
• Kỹ sư: Nhìn vào ticket và bắt đầu đặt câu hỏi. Khoan đã, bảng này có 5 triệu record. Nếu admin bấm export dải thời gian 1 năm thì sao? DB có bị lock không? Server có bị OOM (Out Of Memory) rồi văng luôn màn hình đen không? Có nên đẩy task này vào background job (Message Queue) rồi gửi thông báo khi file generate xong không?

Kỹ sư không làm việc để đóng ticket. Họ làm việc để giải quyết bài toán kinh doanh (Business Value) một cách an toàn và tối ưu nhất.

2. Ám ảnh với Cú pháp (Syntax) thay vì Hệ thống (System)

Thợ gõ thường rất tự hào về việc mình thuộc lòng các function của Laravel, hàm map/reduce của Javascript hay cách ép kiểu trong Golang. Nhưng khi bức tranh lớn hơn xuất hiện, họ lại lúng túng.

Bạn có thấy mình trong những tình huống này không?

• Gặp một bug khó, việc đầu tiên là copy nguyên dòng log lỗi ném lên StackOverflow hoặc ChatGPT. Nhận được một đoạn code chạy được là paste thẳng vào project, không cần quan tâm nó ảnh hưởng đến Memory hay Performance ra sao. Cốt là "qua ải".
• Rất giỏi viết thuật toán, nhưng mù tịt về cách ứng dụng giao tiếp với nhau. Khi được hỏi: "Tại chỗ này lại dùng Redis thay vì truy vấn thẳng vào PostgreSQL?", câu trả lời thường là: "Thấy dự án cũ làm thế nên em làm theo

Kỹ sư biết rằng ngôn ngữ lập trình chỉ là công cụ. Hôm nay bạn dùng PHP, ngày mai công ty chuyển sang Go hoặc Node.js. Thứ giúp bạn tồn tại không phải là cú pháp, mà là Tư duy thiết kế hệ thống và Khả năng giải quyết vấn đề.

3. Nỗi sợ mang tên "Legacy Code"

Đây là ranh giới rõ ràng nhất giữa thợ và thầy.

Thợ gõ nhìn vào một đống code cũ nát, không comment, logic chằng chịt và có phản xạ: "Đừng đụng vào, nó đang chạy thì cứ để nó chạy". Họ vá víu (patch) thêm những đoạn if/else vào bên ngoài chỉ để xong task của mình, mặc kệ việc Technical Debt (Nợ kỹ thuật) ngày một phình to.

Ngược lại, Kỹ sư coi Legacy Code là một phần trách nhiệm. Họ không đập đi xây lại một cách mù quáng, nhưng họ biết cách Refactor có chiến lược. Họ đọc hiểu business flow trong mớ code cũ, viết thêm Unit Test để bao bọc logic, và mạnh dạn tái cấu trúc khi cần thiết để hệ thống dễ thở hơn.

Câu hỏi chốt hạ: Tương lai của bạn nằm ở đâu? Chúng ta đang sống ở một thời đại mà các công cụ AI đang tiến hóa với tốc độ chóng mặt. Những việc như viết boilerplate code, gen ra các file config, CRUD cơ bản... AI có thể làm nhanh gấp 10 lần một lập trình viên bình thường, và nó không cần uống cà phê hay nghỉ ốm.

Nếu giá trị duy nhất của bạn tại công ty là biến những Requirement rõ ràng thành Code chạy được – thì tin buồn là: Bạn nằm trong danh sách rất dễ bị thay thế.

Nhưng AI (ít nhất là tính đến lúc này) không thể cãi tay đôi với Product Owner để bảo vệ một kiến trúc hệ thống. AI không thể đánh đổi (trade-off) giữa việc dùng Consistency hay Availability cho một hệ thống phân tán. Và AI không thể gánh vác trách nhiệm (Ownership) khi hệ thống sập lúc 2 giờ sáng.

Đó là sân chơi của Kỹ sư.

Bạn đang là ai trong hai bức chân dung này? Đừng vội tự ái. Nhận diện được vấn đề chính là bước đầu tiên của sự bứt phá.

Ở phần tiếp theo, chúng ta sẽ đi sâu vào Mindset - Làm sao để chuyển dịch từ tư duy "Code chạy được" sang "Hệ thống chạy ngon", với những case study thực tế rớt nước mắt. > Hãy follow series để cùng nâng cấp bản thân nhé!