Công Việc Thật Sự Của Dev: Giải Quyết Vấn Đề, Không Chỉ Code

Có một câu chuyện mình nghe hoài từ các junior dev, mỗi lần họ rơi vào dự án dùng tech stack chưa từng đụng.

"Em chỉ biết React thôi, không biết Vue."
"Em chưa viết Go bao giờ, em chỉ làm Python."
"Em không quen framework này."

Và ẩn sau đó là một assumption đáng nghi vấn: rằng công việc của bạn là viết code bằng những ngôn ngữ bạn đã biết. Không phải vậy đâu.

Bạn Sẽ Học Được Gì

✅ Tại sao problem-solving, không phải coding, mới là core skill của developer
✅ Cách nhìn nhận tech stack như công cụ thay vì identity
✅ Khả năng thích ứng trông như thế nào trong thực tế
✅ Business thuê developer vì điều gì — và họ thật sự đang trả tiền cho cái gì

Sự Hiểu Lầm Ở Tận Gốc Rễ

Khi ai đó hỏi "bạn làm nghề gì?", hầu hết developer trả lời: "Tôi viết code."

Cũng giống như bác sĩ phẫu thuật nói "Tôi rạch người ta ra." Về mặt kỹ thuật thì đúng. Nhưng hoàn toàn miss the point.

Công việc của bác sĩ phẫu thuật là chữa bệnh cho bệnh nhân. Dao mổ chỉ là dụng cụ. Và không ai kỳ vọng một bác sĩ giỏi nói "Xin lỗi, tôi chỉ mổ được nếu anh mang đúng con dao mổ tôi đã luyện tập."

Công việc của developer là giải quyết vấn đề bằng software. Code là dụng cụ để làm điều đó.

Sự phân biệt này nghe có vẻ triết học, nhưng nó có hậu quả rất thực tế — trong cách bạn tiếp cận dự án mới, cách bạn học, và cuối cùng là giá trị bạn mang lại cho team.

"Giải Quyết Vấn Đề" Thật Ra Có Nghĩa Là Gì

Problem-solving trong software development không chỉ là debug. Đó là toàn bộ một vòng tròn:

Hiểu vấn đề trước tiên. Trước khi chạm vào bàn phím, bạn có hiểu tại sao cần build thứ này không? Nó drive outcome gì cho business? User là ai? Constraints là gì — thời gian, budget, hệ thống hiện tại?

Chia nhỏ thành các phần. Vấn đề lớn chỉ là tập hợp của những vấn đề nhỏ hơn. Khả năng decompose một yêu cầu mơ hồ thành những unit cụ thể, có thể build được — đây là một trong những kỹ năng có giá trị nhất của developer. Và cũng là một trong những kỹ năng khó nhất.

Chọn approach phù hợp. Không phải vấn đề nào cũng cần microservice. Không phải automation nào cũng cần AI. Judgment về cách giải quyết — và khi nào thì đơn giản hơn lại là tốt hơn — đến từ việc hiểu sâu vấn đề, không phải từ việc biết nhiều syntax hơn.

Build, test, ship, iterate. Cái cycle của việc deliver thứ gì đó thật, nhận feedback, và cải thiện — đây mới là nơi hầu hết việc học thật sự xảy ra.

Để ý rằng không bước nào trong số này yêu cầu một ngôn ngữ lập trình hay framework cụ thể. Chúng yêu cầu tư duy rõ ràng.

Tech Stack Là Công Cụ, Không Phải Identity

Đây là mental model shift mà thay đổi mọi thứ:

Thợ mộc không nói "Tôi chỉ xây được bằng búa." Họ chọn công cụ phù hợp cho từng việc.

Python, Go, Java, TypeScript, React, Vue, Spring Boot, FastAPI, PostgreSQL, MongoDB — tất cả đều là công cụ. Mỗi cái có trade-off riêng. Mỗi cái phù hợp hơn hoặc kém hơn với các context khác nhau.

Khi một dự án dùng tech stack bạn chưa từng làm việc cùng, phản ứng đúng không phải là hoảng loạn. Mà là tò mò: "Tool này làm tốt cái gì, và nó approach những vấn đề mình đã biết cách giải quyết như thế nào?"

Vì đây là sự thật: hầu hết các concept đều transfer được. REST API hoạt động như nhau trong Go và Python. Database design không thay đổi tùy theo ORM bạn dùng. Authentication flow vẫn là authentication flow. State management pattern lặp đi lặp lại qua các framework.

Thứ bạn thật sự đang học khi học một ngôn ngữ mới là:

Syntax (vài ngày đến vài tuần)
Các idiom và convention của ngôn ngữ đó (vài tuần đến vài tháng)
Ecosystem — thư viện, tooling, community pattern (vài tháng)

Còn computer science cơ bản, system design, và kỹ năng problem-solving bạn đã có? Những thứ đó áp dụng được ngay lập tức.

Góc Nhìn Của Business

Các công ty không thuê developer để viết code bằng một ngôn ngữ cụ thể. Họ thuê developer để build và maintain hệ thống giúp business vận hành.

Một startup không care bạn thích Postgres hay MySQL — họ care bạn có thể ship một database layer hoạt động được, maintainable, không làm sập production. Một enterprise không care bạn yêu Python — họ care bạn có thể add feature vào Java codebase của họ mà không introduce bug.

Có nghĩa là: công việc của bạn là phục vụ nhu cầu của dự án, không phải tech preference cá nhân.

Điều đó không phải là khắt khe — thật ra nó giải phóng bạn. Nó có nghĩa là giá trị của bạn đến từ khả năng hiểu vấn đề, đưa ra quyết định tốt, và deliver software hoạt động được. Nó không lỗi thời khi có framework mới ra đời hay khi dự án dùng thứ gì bạn chưa thấy.

Dev nói "tôi chỉ làm với X" đang tối ưu cho sự thoải mái của bản thân. Dev hỏi "hệ thống này cần gì, và mình có thể contribute như thế nào?" đang tối ưu cho team — và người đó nhận được nhiều cơ hội hơn, được tin tưởng hơn, và được làm những công việc thú vị hơn.

Khả Năng Thích Ứng Là Kỹ Năng Có Thể Luyện Được

Tin tốt là: khả năng thích ứng này không phải đặc điểm tính cách cố định. Đó là skill bạn xây dựng có chủ đích.

Build trên nền tảng cơ bản. Nếu bạn hiểu sâu cách HTTP hoạt động, bạn có thể pick up bất kỳ web framework nào. Nếu bạn hiểu memory management hoạt động ra sao, chuyển đổi giữa các ngôn ngữ sẽ ít gây choáng hơn. Đầu tư vào fundamentals — data structures, algorithms, networking, databases, system design — và chúng sẽ nhân lên giá trị của mọi thứ bạn học sau này.

Đọc codebase lạ mà không sợ. Khi bạn join dự án dùng tech mới, công việc đầu tiên không phải là viết code — mà là hiểu hệ thống. Đọc code hiện tại. Hiểu nó đang làm gì và tại sao. Chạy nó ở local. Trace một request qua toàn bộ stack. Giai đoạn orientation này không phải là thời gian lãng phí — nó là thiết yếu.

Break things trong môi trường an toàn. Cách nhanh nhất để học tech stack mới là dùng nó. Build thứ gì đó nhỏ. Break it. Fix it. Đọc error message. Cảm giác không biết mình đang làm gì — đó chính là lúc bạn đang học.

Đặt câu hỏi tốt. "Em chưa quen framework này — anh/chị có thể chỉ cho em những concept cốt lõi cần hiểu trước không?" thể hiện bạn tốt hơn nhiều so với giả vờ biết hoặc tránh né vấn đề. Good team coi trọng sự thành thật và tò mò hơn là tự tin ảo.

Sự Thật Khó Nghe Về "Tôi Chỉ Biết X"

Khi developer khăng khăng chỉ có thể làm với một stack cụ thể, một vài điều có thể đang xảy ra:

Thật sự không thoải mái với sự không chắc chắn — điều này bình thường, nhưng đáng để vượt qua thay vì bảo vệ.
Nhầm lẫn giữa quen thuộc và năng lực — biết một tool sâu cảm giác như biết tất cả mọi thứ. Không phải vậy.
Sợ trông không có năng lực trước mặt teammate — điều này có thể hiểu được, nhưng giải pháp là xây dựng confidence trong việc học, không phải tránh né những thứ mới.

Không cái nào là khuyết điểm tính cách. Nhưng nếu không kiểm soát, chúng giới hạn sự phát triển của bạn và, thực tế mà nói, giới hạn career option của bạn.

Những developer được giao công việc thú vị nhất hầu như không bao giờ là những người chuyên hẹp vào một stack. Họ là những người có thể bước vào bất kỳ codebase nào, nhanh chóng định hướng, contribute có ý nghĩa, và phát triển từ trải nghiệm đó.

Kết Lại

Công việc của software developer là giải quyết vấn đề bằng software.

Code là cách bạn diễn đạt solution. Ngôn ngữ hay framework cụ thể là cách bạn diễn đạt code. Cả hai đều quan trọng — nhưng không cái nào là cốt lõi tạo nên giá trị của developer.

Điều tạo nên giá trị của bạn là:

Hiểu vấn đề rõ ràng trước khi cố giải quyết
Tư duy có hệ thống về trade-off
Học công cụ mới khi dự án yêu cầu
Ship thứ gì đó thật sự hoạt động và có thể maintain được
Ngày càng giỏi hơn ở tất cả những điều trên theo thời gian

Developer đã internalize điều này không hoảng loạn khi được giao dự án với stack lạ. Họ tò mò, định hướng, và bắt tay vào làm.

Đó mới là công việc thật sự.