Làm Sao Để Không Bao Giờ Bị Thay Thế: Tư Duy Phát Triển Cho Developer

Cứ vài tháng, cộng đồng developer lại dậy sóng:

"AI sắp cướp việc của bạn rồi."
"Framework mới này khiến kỹ năng bạn lỗi thời."
"Công ty đang thay senior bằng junior rẻ hơn cộng thêm AI."

Và lần nào cũng vậy, tôi thấy mọi người chia thành hai phe. Phe thì cuống cuồng chạy theo trend mới nhất, hy vọng không bị tụt lại phía sau. Phe kia đứng im, tự hỏi liệu sự nghiệp mình có còn tương lai không.

Nhưng còn một nhóm thứ ba — những người hoàn toàn không hoảng. Họ đã trải qua những chu kỳ này trước đây. Họ thích ứng khi REST thay thế SOAP, khi container thay thế VM, khi cloud thay thế on-prem. Họ sẽ lại thích ứng thôi.

Điều khiến họ khác biệt không phải tài năng hay may mắn. Mà là những thói quen họ âm thầm xây dựng qua nhiều năm. Và tin tốt là ai cũng học được — nếu chịu bắt đầu.

Đây là năm thói quen đó.

1. Trân Trọng Công Việc Của Mình

Nghe thì ai cũng gật gù, nhưng làm được thì ít người lắm.

Không phải tăng ca hay gồng mình làm anh hùng. Mà là thật sự quan tâm đến chất lượng những gì mình deliver — lần nào cũng vậy, không ngoại lệ.

Khi bạn nhận một ticket, đừng chỉ làm cho nó "chạy được." Hãy tự hỏi:

Đây là giải pháp tốt nhất, hay chỉ là cái đầu tiên nảy ra trong đầu?
Người tiếp theo đọc code này có hiểu không?
Mình đã xử lý edge case chưa, hay mới chỉ cover happy path?
Có cách nào đơn giản hơn không?

Developer ship feature xong là coi như xong, không quan tâm nữa — người đó thay thế được. Developer ship feature xong, theo dõi nó, nhận ra khi có gì đó sai sai, rồi chủ động cải thiện — người đó thì không.

Xuất sắc không có nghĩa là hoàn hảo. Mà là luôn bận tâm. Là coi công việc như thứ phản ánh con người mình — vì nó đúng là vậy.

Khi bạn làm tốt, có hai thứ xảy ra. Một là người ta sẽ giao cho bạn task khó hơn/challenge hơn — vì tin bạn xử lý được. Hai là tên bạn bắt đầu được nhắc đến trong những cuộc họp dù bạn không có ở đó.

Bảo hiểm nghề nghiệp tốt nhất là khi mọi người nghĩ đến bạn khi có việc khó cần làm.

2. Yêu Lấy Những Thứ Nhàm Chán

Nói thật nhé: kiến thức có giá trị nhất trong ngành phần mềm lại chính là những thứ nhàm chán nhất.

Data structure. Algorithm. Networking. Operating system. SQL. Design pattern. HTTP thực sự hoạt động thế nào. Memory được quản lý ra sao. Database nên index như thế nào và khi nào cần index.

Chẳng có gì sexy cả. Không trend trên Twitter. Không ai làm video viral về TCP handshake hay B-tree indexing đâu.

Nhưng những kiến thức này không bao giờ hết hạn.

React có thể bị thay thế. Kubernetes có thể biến thành thứ khác. Ngôn ngữ hot nhất năm 2027 giờ có thể chưa tồn tại. Nhưng developer hiểu hash map chạy thế nào, tại sao connection pooling quan trọng, chuyện gì xảy ra khi process hết memory — người đó sẽ bắt kịp bất kỳ công nghệ mới nào trong vài tuần, chứ không phải vài tháng.

Cái Bẫy Framework

Tôi từng gặp developer thuộc lòng mọi hook và config option của một framework, nhưng đưa cho một networking issue cơ bản thì bó tay. Khi vấn đề nằm dưới lớp abstraction, họ không biết bắt đầu từ đâu.

Đó là vì họ học cái WHAT mà không học cái WHY.

Khi bạn hiểu nền tảng:

Framework mới không đáng sợ — nó chỉ là một wrapper khác quanh những concept bạn đã biết.
Debug nhanh hơn vì bạn hiểu/đoán được chuyện gì có thể đang xảy ra under the hood.
Đưa ra quyết định về Architecture rõ ràng hơn vì bạn hiểu trade-off ở tầng sâu hơn.

Làm sao học thứ nhàm chán mà không chết vì chán?

Gắn nó với vấn đề thực tế. Đừng học data structure trong chân không. Học khi bạn đang vật lộn với một performance issue. Lúc đó, hiểu time complexity (Big O Notation) không còn nhàm chán — nó là lối thoát cho vấn đề của bạn.
Giải thích lại cho người khác. Khi bạn phải giải thích một concept phức tạp cho đồng nghiệp, bạn buộc phải hiểu nó ở mức độ sâu hơn. Bạn sẽ tìm ra những lỗ hổng trong kiến thức của mình mà trước đó bạn không nhận ra.
Đi sâu hơn một tầng so với mức cần thiết. Khi bạn dùng một library, dành 30 phút đọc source code của nó hoặc tìm hiểu thêm how it works. Bạn sẽ học được nhiều hơn trong nửa tiếng đó so với cả tuần xem tutorial.

Framework đến rồi đi. Developer hiểu lớp bên dưới (Architecture, Design, Protocol, Pattern) không bao giờ lỗi mốt.

3. Kết Nối Việc Học Với Công Việc

Đây là thói quen tạo ra sự khác biệt giữa developer liên tục tiến bộ và người mãi giậm chân tại chỗ.

Ý tưởng rất đơn giản: tạo một vòng lặp phản hồi giữa những gì bạn học và những gì bạn làm.

Đa số mọi người coi học và làm là hai thứ riêng biệt. Đi làm thì hoàn thành task, về nhà thì xem khóa học hay đọc sách. Vấn đề là hai thứ này hiếm khi gặp nhau. Khóa học dạy những thứ không dùng. Công việc không đẩy họ ra khỏi vùng quen thuộc — không tạo ra cơ hội áp dụng kiến thức mới.

Cách khắc phục? Liên kết chúng lại một cách có chủ đích.

Từ công việc đến việc học

Khi bạn gặp problem ở công ty, đừng chỉ fix nó — hãy hiểu nó.

API chậm? Đừng chỉ thêm cache. Tìm hiểu tại sao nó chậm. Nghiên cứu query execution plan. Hiểu indexing hoạt động thế nào. Đọc về N+1 query problem.
Deploy fail? Đừng chỉ re-run pipeline. Tìm hiểu CI/CD system hoạt động ra sao. Hiểu container networking. Đọc error log như chúng đang kể cho bạn nghe một câu chuyện.
Senior review code và góp ý, PR bị reject? Đừng chỉ sửa cho xong. Hỏi tại sao reviewer suggest cách khác. Hiểu design principle đằng sau feedback đó.

Mỗi problem ở công ty là một bài học rất có giá trị. Developer coi problem là cơ hội học hỏi sẽ tích lũy kiến thức nhanh hơn bất kỳ ai chỉ ngồi xem course.

Từ việc học đến công việc

Khi bạn học được gì mới, áp dụng nó ngay lập tức.

Đọc về Strategy pattern? Nhìn codebase của bạn — có cái switch statement khổng lồ nào có thể apply nó không? Học về database normalization? Check schema xem có redundancy không. Nghiên cứu observability? Propose thêm structured logging vào service.

Khoảng cách giữa "biết" và "dùng được" chỉ có thể lấp đầy bằng thực hành. Và công việc hàng ngày là sân tập tốt nhất bạn có.

Hiệu ứng cộng dồn

Theo thời gian, vòng lặp này tăng tốc. Bạn solve problem khó hơn vì đã học nhiều hơn. Bạn học nhiều hơn vì đang solve problem khó hơn. Các vòng lặp sẽ ngày càng nhanh hơn, và kiến thức của bạn sẽ cộng dồn theo cấp số nhân chứ không phải tuyến tính.

Sau vài năm như vậy, khoảng cách giữa bạn và người học passive là khổng lồ — và nó chỉ tăng lên theo thời gian.

Những developer giỏi nhất không tách biệt học và làm. Họ biến chúng thành cùng một hoạt động.

4. Xin Được Làm Task Khó, Solve Problem Khó, Và Rời Khỏi Comfort Zone

Đa số mọi người làm ngược lại. Tìm được comfort zone rồi ở lì luôn. Cùng một loại task, cùng một góc codebase, cùng một bộ tech stack. An toàn. Thoải mái.

Và đây cũng là lý do tại sao nhiều người mãi giậm chân tại chỗ dù đã làm việc nhiều năm.

Tại sao comfort zone lại nguy hiểm

Khi bạn làm đi làm lại cùng một loại việc, bạn ngừng học. Bạn không phải đang có 10 năm kinh nghiệm — bạn chỉ đang có 1 năm kinh nghiệm lặp lại 10 lần. Bạn không phải là expert trong một lĩnh vực — bạn chỉ là người quen thuộc với một phần nhỏ của nó. Khi có công nghệ mới xuất hiện, bạn không biết bắt đầu từ đâu vì bạn chưa từng rời khỏi vùng an toàn để khám phá nó.

Cách thoát ra

Xung phong nhận việc không ai muốn làm. Migration không ai chịu nhận? Nhận. Hệ thống legacy ai cũng né? Nhảy vào. Dự án cross-team phải phối hợp với những người chưa từng làm cùng? Say YES.

Những việc khó nhằng này dạy bạn những thứ mà những task thoải mái/quen thuộc không bao giờ dạy được:

Breadth of knowledge. Làm xuyên suốt nhiều system giúp bạn có bản đồ tư duy về cách mọi thứ kết nối/integrate với nhau. Bạn bắt đầu nhìn ra pattern và dependency mà specialist không thấy.
Judgment. Hard problem buộc bạn ra quyết định khi thông tin chưa đủ. Đó chính là skill khiến senior engineer có giá trị.
Resilience. Khi đã sống sót qua một cuộc migration đau thương hay debug production incident lúc 2 giờ sáng, task bình thường chẳng còn gây stress nữa. Bạn sẽ thấy mình có thể handle bất kỳ thứ gì xảy ra trong hệ thống, và đó là cảm giác tuyệt vời.

T-shaped developer (Developer có kiến thức vừa sâu vừa rộng)

Mục tiêu không phải biết mỗi thứ một chút. Mà là T-Shaped: giỏi thật sự ở một hoặc hai thứ, nhưng hiểu rộng về nhiều thứ khác.

Giỏi sâu giúp bạn có giá trị. Hiểu rộng giúp bạn linh hoạt. Kết hợp cả hai thì rất khó thay thế.

Khi bạn nhìn được bức tranh toàn cảnh, bạn có thêm một lợi thế ít ai để ý: bạn biết mình đang đứng ở đâu. Skill nào đang lên, skill nào đang xuống, ngành đang đi về hướng nào. Biết được điều đó, bạn chủ động chọn hướng đi cho career thay vì bị cuốn theo.

Technical skill thôi chưa đủ — hãy học cả domain

Đây là thứ phần lớn developer bỏ qua: muốn không bị thay thế, bạn phải hiểu không chỉ code, mà cả domain mà code đó phục vụ.

Ví dụ bạn đang làm một hệ thống IoT lớn. Team bạn phụ trách Communication Layer — phần xử lý giao tiếp giữa thiết bị và cloud. Bạn thuộc lòng MQTT. Code chắc tay. Nhưng bạn có hiểu Dispatcher route message đến pipeline xử lý thế nào không? Device Management service quản lý provisioning và firmware update ra sao? Tại sao Data Ingestion layer lại được thiết kế như vậy?

Nếu bạn chỉ biết phần mình, bạn là một mắt xích. Nhưng nếu bạn hiểu toàn bộ hệ thống — data chảy từ sensor lên dashboard thế nào, command đi từ API call xuống thiết bị vật lý ra sao — bạn trở thành domain expert. Và domain expert thì gần như không thể thay thế.

Điều này đúng ở mọi lĩnh vực, không chỉ IoT. Làm fintech? Tìm hiểu payment settlement thực sự hoạt động thế nào. E-commerce? Hiểu inventory management và fulfillment logistics. Healthcare software? Nắm rõ compliance landscape.

Technical skill giúp bạn get hired. Domain knowledge biến bạn thành người mà ai cũng tìm đến khi cần build thứ gì complex — vì bạn hiểu không chỉ how to build, mà còn what to build và why.

Code chỉ là công cụ. Hiểu vấn đề mà nó giải quyết mới là chuyên môn thực sự.

Developer chỉ làm những gì quen thuộc rồi cuối cùng sẽ bị thay thế bởi người quen thuộc với nhiều thứ hơn (hoặc AI ^^).

5. Trở Nên Giỏi Hơn, Không Chỉ Có Thêm Experience

Thời gian trôi đi dù bạn có tiến bộ hay không. Câu hỏi là bạn có dùng thời gian đó một cách có chủ đích không.

Tôi từng làm với developer 15 năm kinh nghiệm mà giải thích không nổi những concept cơ bản trong chính lĩnh vực của mình. Cũng từng làm với developer mới 3 năm mà design system scale ngon lành. Khác biệt không phải do giỏi sẵn — mà là do có chủ đích trong việc phát triển bản thân.

Phát triển có chủ đích trông như thế nào

Nhìn lại sai lầm. Bug lọt lên production, chọn sai design, project mất gấp đôi thời gian — đừng vội bỏ qua. Ngồi lại với nó. Sai ở đâu? Làm lại thì sẽ làm khác thế nào? Viết ra. Bài học nằm ở việc nhìn lại, không phải ở bản thân sai lầm.
Chủ động xin feedback. Đừng đợi đến performance review. Hỏi đồng nghiệp: "Có điều gì mình nên cải thiện không?" Hỏi sếp: "Anh/Chị nghĩ em nên phát triển hướng nào?" Developer tiến bộ nhanh nhất là người không sợ câu trả lời thật.
Đặt mục tiêu cụ thể. "Tôi muốn giỏi hơn" không phải mục tiêu. Mà nó là "Tôi muốn hiểu distributed system đủ để design kiến trúc multi-region". Nó là "Tôi muốn giảm số lần review trên PR từ 3 vòng xuống 1". Mục tiêu cụ thể dẫn đến hành động cụ thể.
Review lại code của mình từ sáu tháng trước. Nếu bạn thấy ngượng — đó là dấu hiệu tốt, nghĩa là bạn đã tiến bộ. Nếu thấy ổn, hãy tự hỏi liệu bạn thật sự giỏi hơn hay chỉ không còn nhận ra vấn đề.

Sức mạnh của những cải thiện nhỏ

Không cần bước nhảy vĩ đại. Tiến bộ 1% mỗi tuần nghe chẳng là gì. Nhưng sau một năm, bạn giỏi hơn 68%. Sau hai năm, gần gấp ba so với điểm xuất phát.

Không tin à? Toán không biết nói dối: Result = 1.01^n (n = số tuần).
Sau 1 năm: 1.01^52 ≈ 1.68 → giỏi hơn 68%. Chưa giàu, nhưng đã nguy hiểm.
Sau 2 năm: 1.01^104 ≈ 2.82 → gần gấp 3× so với điểm xuất phát. Lúc này đồng nghiệp bắt đầu hỏi "ê mày học ở đâu vậy?"

Quan trọng là đều đặn, không phải dồn sức. Mỗi tuần đọc một bài viết. Refactor một đoạn code tốt hơn chút so với lúc tìm thấy nó. Nói chuyện thật sự với đồng nghiệp về một quyết định kỹ thuật. Đặt một câu hỏi trong meeting đẩy cuộc thảo luận sâu hơn.

Những hành động nhỏ này tích lũy thành một developer hoàn toàn khác theo thời gian.

Mục tiêu không phải là người thông minh nhất trong phòng. Mà là giỏi hơn đáng kể so với bản thân sáu tháng trước.

Kết Lại

Không thói quen nào ở đây hào nhoáng cả. Không chứng chỉ. Không huy hiệu LinkedIn. Bạn sẽ chẳng cảm nhận được tiến bộ từng ngày.

Nhưng đây là điều xảy ra theo thời gian:

Bạn làm việc xuất sắc → mọi người tin tưởng giao vấn đề lớn hơn
Bạn hiểu nền tảng → công nghệ mới không làm bạn sợ
Bạn kết nối học và làm → kiến thức tích lũy nhanh hơn đồng nghiệp
Bạn tìm kiếm thử thách → skill vừa sâu vừa rộng
Bạn cải thiện có chủ đích → khoảng cách với developer bình thường rộng ra mỗi năm

Những developer bị thay thế là những người sống theo quán tính. Làm mức tối thiểu, chỉ học khi bị ép, ở mãi trong comfort zone, và coi career là thứ xảy đến với mình thay vì thứ mình chủ động xây.

Những developer không bao giờ bị thay thế là những người coi mỗi ngày là cơ hội để tốt hơn một chút. Không kịch tính. Không anh hùng. Chỉ đều đặn, ngày qua ngày.

Bạn không trở nên không thể thay thế sau một đêm. Bạn trở nên không thể thay thế bằng cách tích lũy những cải thiện nhỏ qua nhiều năm — cho đến khi khoảng cách không ai đuổi kịp.

Bắt đầu hôm nay. Chọn một trong năm thói quen. Thực hành nó trong một tháng. Rồi thêm một cái nữa. Trong một năm, bạn sẽ không nhận ra developer mà mình từng là.

Và bạn sẽ không bao giờ lo bị thay thế nữa.