Coding không phải là công việc Bài học mà dev nào cũng cần nghe

Hồi mới đi làm, mình nghĩ đơn giản lắm: viết code tốt = làm việc tốt. Ship feature nhanh, code sạch, ít bug thế là xong. Nhưng sau vài năm, mình nhận ra một sự thật khá phũ: coding chỉ chiếm khoảng 30-40% công việc thực sự của một software engineer.

Chuyện này không phải mình tự nghĩ ra. Gần đây, một bài viết của dev có nickname Itsugo trên Dev.to đã viral trong cộng đồng với tiêu đề thẳng thừng: "I Thought Coding Was The Job". Và nó chạm đúng nỗi đau mà rất nhiều anh em dev Việt Nam đang trải qua.

Chuyện gì đang xảy ra?

Itsugo chia sẻ một hành trình mà hầu hết dev đều trải qua: bắt đầu sự nghiệp với niềm tin rằng kỹ năng technical là tất cả. Viết code giỏi, hiểu algorithm, master framework đó là con đường duy nhất để thăng tiến.

Nhưng thực tế thì khác hoàn toàn. Càng lên level cao, coding càng chiếm ít thời gian hơn. Thay vào đó, những thứ "không ai dạy ở trường" mới là thứ quyết định bạn có thành công hay không.

Theo kinh nghiệm của mình, đây là bảng so sánh giữa những gì mình nghĩ công việc dev là gì vs. thực tế:

Những kỹ năng "ẩn" mà không ai nói cho bạn

Communication Kỹ năng số 1 mà dev hay bỏ qua

Điều mình thấy hay là Itsugo nhấn mạnh: khả năng giải thích một vấn đề kỹ thuật cho người không technical quan trọng hơn rất nhiều so với việc giải quyết vấn đề đó.

Mình đã chứng kiến nhiều senior dev cực giỏi về technical nhưng mãi không lên được Staff hay Principal engineer. Lý do? Họ không thể communicate được impact của công việc mình cho stakeholder. Họ không viết được một cái RFC cho ra hồn. Họ không thể convince team tại sao nên chọn solution A thay vì B.

Ngược lại, mình cũng thấy những dev technical "tầm trung" nhưng lại thăng tiến rất nhanh vì họ biết cách:

• Viết proposal rõ ràng
• Trình bày trade-off một cách logic
• Lắng nghe và incorporate feedback
• Translate business requirement thành technical decision

Hiểu context Biết "tại sao" quan trọng hơn biết "làm thế nào"

Hồi mới đi làm, mình nhận ticket là code luôn. Không hỏi, không challenge, không tìm hiểu context. Kết quả? Nhiều lần ship xong mới phát hiện mình giải quyết sai vấn đề.

Một senior dev thực sự sẽ dành thời gian để hiểu:

• Tại sao feature này cần được build?
• Ai sẽ dùng nó?
• Metric nào sẽ thay đổi nếu ship thành công?
• Có cách nào đơn giản hơn để đạt được mục tiêu không?

Đôi khi câu trả lời tốt nhất là: "Chúng ta không cần build cái này." Và đó là giá trị mà không IDE hay AI nào tạo ra được.

Managing up Không phải nịnh, mà là alignment

Đây là thứ mà dev Việt Nam hay ngại nói đến. "Managing up" nghe có vẻ political, nhưng thực ra nó đơn giản là:

• Chủ động update progress thay vì đợi bị hỏi
• Flag risk sớm thay vì giấu đến phút cuối
• Hiểu priority của manager và align công việc theo đó
• Biết cách nói "không" một cách professional

Theo kinh nghiệm của mình, những dev biết manage up tốt thường được trust nhiều hơn, được giao việc quan trọng hơn, và tự nhiên thăng tiến nhanh hơn. Không phải vì họ nịnh mà vì họ giảm cognitive load cho người quản lý.

Ai bị ảnh hưởng nhiều nhất?

Nếu bạn đang ở giai đoạn 2-5 năm kinh nghiệm, đây chính là lúc bạn cần nghe điều này nhất. Vì sao?

Giai đoạn 2-5 năm là "ngã ba đường". Nhiều dev mắc kẹt ở đây vì cứ nghĩ học thêm một framework nữa, một language nữa sẽ giúp mình breakthrough. Nhưng thực tế, bottleneck không phải technical mà là những kỹ năng xung quanh technical.

Thời đại AI càng làm điều này rõ hơn

Với sự bùng nổ của GitHub Copilot, ChatGPT, Cursor phần "viết code" đang ngày càng bị commoditize. AI có thể generate code, fix bug, viết test. Nhưng AI không thể:

• Ngồi trong meeting và đọc vị stakeholder đang thực sự cần gì
• Navigate office politics để push một technical decision
• Mentor một junior dev đang burn out
• Quyết định nên build hay buy hay bỏ hẳn

Điều này không có nghĩa technical skill không quan trọng. Nó vẫn là foundation. Nhưng nó không còn là differentiator nữa. Cái tạo ra sự khác biệt giữa một dev tốt và một dev xuất sắc nằm ở những thứ mà bài viết của Itsugo đã chỉ ra.

Những điều mình rút ra được

• Coding là necessary nhưng không sufficient. Bạn cần viết code tốt, nhưng chỉ code tốt thôi thì không đủ để thăng tiến.
• Đầu tư vào communication sớm. Viết tốt, nói tốt, present tốt những thứ này compound theo thời gian.
• Hiểu business context. Đừng chỉ là người nhận ticket và code. Hãy là người hiểu tại sao ticket đó tồn tại.
• Chủ động manage up. Đừng ngồi chờ được công nhận. Hãy làm cho công việc của bạn visible.
• Technical depth vẫn quan trọng nhưng hãy kết hợp nó với technical breadth và soft skills.

Tiếp theo thì sao?

Nếu bạn đọc đến đây và thấy "ừ, đúng rồi, nhưng bắt đầu từ đâu?" thì đây là gợi ý của mình:

Tuần này, thử làm một việc: trong mỗi task bạn nhận, hãy hỏi ít nhất 2 câu hỏi "tại sao" trước khi bắt đầu code. Tại sao cần feature này? Tại sao approach này chứ không phải approach khác? Chỉ cần thói quen nhỏ đó thôi, bạn sẽ thấy góc nhìn của mình thay đổi rất nhiều.

Coding không phải là công việc. Coding là công cụ để bạn làm công việc. Và công việc thực sự? Đó là giải quyết vấn đề cho con người bằng bất cứ cách nào hiệu quả nhất.