Career Hack

Hai startup, hai kết cụcStartup A ra mắt MVP trong 6 tuần. Auth bằng JWT tự viết, password hash bằng MD5 vì "nhanh hơn bcrypt", session không có expiry, API endpoint không check authorization — chỉ check authentication. Họ lý luận: "Chưa có user thật, chưa cần lo security."Tháng thứ 4, họ có 8,000 user. Tháng thứ 5, có người tìm ra IDOR (Insecure Direct Object Reference) trong API — chỉ cần đổi user_id trong request là đọc được data của bất kỳ ai. Toàn bộ database 8,000 user bị scrape trong một đêm. Email, số điện thoại, lịch sử giao dịch.Họ mất 3 tháng và gần như toàn bộ runway để xử lý hậu quả — thông báo user, rewrite auth layer, audit lại toàn bộ API. Một co-founder rời đi. Họ không bao giờ recover được trust từ những early adopter quan trọng nhất.Startup B cũng làm nhanh. Nhưng trước khi viết dòng code đầu tiên, họ dành 2 giờ để trả lời một câu hỏi: "Nếu hệ thống của chúng ta bị tấn công, thứ tệ nhất có thể xảy ra là gì?" Từ đó, họ xác định 4 security invariants — những property bắt buộc phải đúng từ đầu — và xây mọi thứ xung quanh đó. Phần còn lại, họ iterate như bình thường.Startup B vẫn ship nhanh. Nhưng họ không bao giờ phải dừng lại để rebuild nền móng.Sự khác biệt không phải là bao nhiêu thời gian họ dành cho security. Sự khác biệt là họ hiểu cái gì không thể sửa sau.Technical Debt — Khái Niệm Bạn Biết Nhưng Chưa Hiểu ĐủWard Cunningham — người đặt ra thuật ngữ "technical debt" — mô tả nó như một khoản vay: bạn viết code chưa hoàn hảo hôm nay để ship nhanh hơn, với ý định sẽ "trả nợ" sau bằng cách refactor.Metaphor này có hai phần quan trọng mà developer hay bỏ qua:Một là: nợ có lãi suất. Code xấu không chỉ là code xấu — nó là code ngày càng khó sửa hơn khi codebase lớn dần, khi có thêm người join, khi có thêm feature build trên nền đó. Lãi suất của technical debt tăng theo thời gian.Hai là: có những khoản nợ không thể trả. Bạn có thể refactor một function xấu. Bạn có thể đổi tên biến, tách class, viết lại module. Nhưng có một số quyết định kiến trúc — một khi đã đi theo hướng đó và build đủ nhiều thứ lên trên — thì chi phí để quay lại gần như tương đương với việc rewrite từ đầu.Security debt thuộc loại thứ hai.Security Debt Khác Technical Debt Thông Thường Ở Điểm GìĐây là điểm mấu chốt mà hầu hết bài viết về chủ đề này bỏ qua.Technical debt thông thường ảnh hưởng đến tốc độ của bạn. Codebase càng nhiều nợ, bạn develop càng chậm, bug xuất hiện càng nhiều, onboarding engineer mới càng mất thời gian. Đau, nhưng là đau từ từ, có thể dự báo được.Security debt ảnh hưởng đến sự tồn tại của bạn. Và nó hoạt động theo cơ chế hoàn toàn khác:Cơ chế 1: Rủi ro không tuyến tínhTechnical debt tích lũy đều đặn — 10 bad function hôm nay, 20 bad function tuần sau. Security debt không hoạt động theo cách đó. Một lỗ hổng duy nhất, dù hệ thống của bạn có 99 thứ khác hoàn hảo, vẫn có thể là điểm vào để toàn bộ hệ thống sụp đổ.Attacker không cần phá vỡ mọi thứ. Họ chỉ cần tìm đúng một điểm yếu.Cơ chế 2: Chi phí tăng theo cấp số nhân theo thời gian phát hiệnIBM Cost of a Data Breach Report (2023) đưa ra con số cụ thể: trung bình một data breach tốn $4.45 triệu USD để xử lý — bao gồm investigation, remediation, notification, legal liability, và reputational damage.Nhưng con số quan trọng hơn là thời gian phát hiện: những breach được phát hiện trong vòng 200 ngày có chi phí trung bình thấp hơn 23% so với những breach phát hiện sau 200 ngày. Lỗ hổng càng tồn tại lâu, thiệt hại càng nhân lên.Với startup giai đoạn đầu, bạn không có $4.45 triệu để xử lý hậu quả. Một breach nghiêm trọng ở scale vài nghìn user đã đủ để:Mất toàn bộ early adopterVi phạm quy định bảo vệ dữ liệu (PDPA tại Việt Nam, GDPR nếu có user EU)Mất khả năng raise funding — không investor nào muốn đổ tiền vào startup vừa bị hackMất nhân sự — engineer giỏi không muốn làm việc với codebase mà họ biết là thiếu an toànCơ chế 3: Trust collapse không có đường quay lạiTechnical debt không ai nhìn thấy từ bên ngoài. Security incident thì ngược lại — nó là public event. Một khi user đã bị breach, họ không quên. Và trong thời đại social media, câu chuyện lan rất nhanh.Đây là thứ không thể mua lại bằng tiền hay refactor bằng code.Barry Boehm và Cái Giá Của Việc Sửa MuộnNăm 1981, nhà khoa học máy tính Barry Boehm công bố một nghiên cứu mà kết quả của nó vẫn còn nguyên giá trị đến hôm nay: chi phí để sửa một lỗi tăng theo hàm mũ theo thời gian phát hiện trong vòng đời phát triển phần mềm.Cụ thể:Sửa lỗi trong giai đoạn requirements/design: chi phí cơ sở = 1xSửa trong giai đoạn coding: 6xSửa trong giai đoạn testing: 15xSửa sau khi đã release: 100xBoehm gọi đây là Cost of Change Curve — và nó là lý do cơ bản nhất tại sao "làm đúng từ đầu" không phải là chủ nghĩa hoàn hảo, mà là kinh tế học thuần túy.Với security, curve này còn dốc hơn. Vì sửa security không chỉ là sửa code — đó là sửa kiến trúc, migrate data, thay đổi cách hệ thống xử lý mọi request, retest toàn bộ, và đôi khi thông báo cho tất cả user về việc thay đổi.Lấy ví dụ cụ thể: Row-Level Security (RLS).Nếu bạn thiết kế database từ đầu với RLS — mỗi query tự động filter theo user_id của người đang đăng nhập — đó là vài dòng config trong PostgreSQL và một số convention trong ORM layer. Chi phí: gần bằng 0.Nếu bạn đã có 50 model, 200 API endpoint, và data của nhiều user đã pha trộn trong cùng table mà không có isolation rõ ràng, việc retrofit RLS là một dự án riêng kéo dài vài tuần, với rủi ro cao là bỏ sót edge case nào đó trong quá trình migration.Đây không phải lý thuyết — đây là câu chuyện xảy ra ở hầu hết mọi startup khi họ bắt đầu nghĩ nghiêm túc về multi-tenancy hoặc data isolation.Ba Quyết Định Kiến Trúc Mà Solo Builder Thường Làm SaiKhông phải mọi security decision đều quan trọng như nhau ở giai đoạn đầu. Nhưng có ba quyết định mà nếu làm sai, chi phí để sửa sau này là không tỷ lệ với công sức làm đúng ngay từ đầu.Quyết định 1: Authentication & Session ManagementĐây là nơi nhiều solo builder tự viết thay vì dùng thư viện đã được kiểm chứng — vì nghĩ là "đơn giản thôi."Auth không đơn giản. Auth là một trong những domain có nhiều edge case và subtle vulnerability nhất trong toàn bộ application security. Chỉ riêng JWT đã có hàng chục cách implement sai: alg: none attack, weak secret, missing expiry, improper invalidation sau logout, không rotate refresh token.Làm đúng từ đầu trông như thế nào:Dùng thư viện auth đã được audit: NextAuth, Passport.js, Auth.js, hoặc managed service như Clerk, Supabase AuthPassword phải hash bằng bcrypt/argon2 — không phải MD5, SHA1, hay SHA256 thuần túySession token phải có expiry hợp lý và phải invalidate được server-side khi logoutImplement rate limiting trên login endpoint từ ngày đầu — brute force là attack cơ bản nhấtChi phí để làm đúng: thêm 2-3 giờ setup ban đầu.Chi phí để fix sau khi đã có user và đang dùng auth sai: migration toàn bộ password hash (buộc user reset password), rewrite session management, audit toàn bộ flow liên quan. Tính bằng tuần.Quyết định 2: Authorization Model — Ai Được Xem GìAuthentication hỏi: "Bạn là ai?" Authorization hỏi: "Bạn được phép làm gì?"Hầu hết solo builder implement authentication tương đối ổn. Authorization thì thường bị bỏ qua hoặc làm không nhất quán.Pattern nguy hiểm phổ biến nhất: check authentication nhưng không check authorization.// ❌ Pattern sai — chỉ check user đã login app.get('/api/documents/:id', requireAuth, async (req, res) => { const doc = await Document.findById(req.params.id) return res.json(doc) }) // ✅ Pattern đúng — check user có quyền với resource cụ thể app.get('/api/documents/:id', requireAuth, async (req, res) => { const doc = await Document.findOne({ _id: req.params.id, owner: req.user.id // Chỉ trả về nếu document thuộc về user này }) if (!doc) return res.status(404).json({ error: 'Not found' }) return res.json(doc) })Lỗi này có tên trong OWASP Top 10: Broken Object Level Authorization (BOLA) — hay còn gọi là IDOR (Insecure Direct Object Reference). Đây là vulnerability phổ biến nhất trong API hiện đại, và là thứ đã hạ gục Startup A trong câu chuyện mở đầu.Làm đúng từ đầu: Mọi query lấy data đều phải có điều kiện filter theo owner/tenant. Đây là convention — một khi đã là convention trong codebase, mọi developer (kể cả bạn trong tương lai) sẽ tự nhiên follow.Fix sau: Audit lại 200 API endpoint, tìm chỗ nào còn thiếu authorization check, test từng cái. Và bạn sẽ không bao giờ chắc chắn 100% mình đã tìm hết.Quyết định 3: Secret ManagementSecrets — API key, database password, JWT secret, third-party credentials — là mục tiêu số một của automated scanner trên GitHub. Có những tool chạy 24/7 scan mọi public repository mới để tìm credentials bị commit nhầm.Pattern sai phổ biến:# .env file bị commit vào git DATABASE_URL=postgresql://admin:supersecret@localhost/prod JWT_SECRET=myverysecretkey123 STRIPE_SECRET_KEY=sk_live_xxxxxHoặc hardcode trong code:const stripe = new Stripe('sk_live_xxxxx') // ❌Làm đúng từ đầu:.env phải có trong .gitignore từ commit đầu tiên — không phải "sẽ thêm sau"Dùng environment variables hoặc secret manager (AWS Secrets Manager, Doppler, Vault)Rotate tất cả credentials nếu bạn không chắc chắn 100% chưa bao giờ commitChi phí để làm đúng: 30 phút setup .gitignore và .env.example đúng cách.Chi phí khi bị lộ: rotate toàn bộ credential, audit xem secret đó đã bị dùng chưa, thông báo cho các bên liên quan. Stripe key bị lộ có thể dẫn đến charge fraudulent hàng nghìn đô trước khi bạn kịp nhận ra.Security Invariants — Khái Niệm Bạn Cần BiếtĐây là framework tôi thấy hữu ích nhất để solo builder tiếp cận security mà không bị overwhelm.Security invariant là một property của hệ thống phải luôn đúng, bất kể codebase phát triển theo hướng nào.Ví dụ:"Không có user nào có thể đọc data của user khác trừ khi được explicit grant.""Mọi input từ bên ngoài đều phải được validate trước khi xử lý.""Không có credential nào được hardcode trong source code.""Mọi action thay đổi data phải được log với timestamp và actor."Điểm mạnh của cách tiếp cận này: thay vì cố gắng implement một checklist security dài vô tận, bạn xác định 4-5 invariant quan trọng nhất với domain của mình, rồi đảm bảo mọi quyết định thiết kế không vi phạm chúng.Và khi onboard người mới hoặc review PR, câu hỏi không phải là "code này có secure không?" (quá mơ hồ) mà là "code này có vi phạm invariant nào không?" (có thể kiểm tra được).Quy trình xác định security invariants cho solo builder:Hỏi: "Data nhạy cảm nhất trong app của tôi là gì?" (PII, payment info, private content)Hỏi: "Thứ tệ nhất có thể xảy ra nếu data đó bị lộ?"Hỏi: "Điều gì phải luôn đúng để điều đó không xảy ra?"Viết ra 4-5 câu khẳng định — đó là invariants của bạnReview lại chúng mỗi khi thêm feature mới có ảnh hưởng đến data modelVibe Coding + Security Debt — Nhân Tố NhânMột yếu tố mới cần nhắc đến trong năm 2025: AI-assisted development đang làm cho security debt tích lũy nhanh hơn bao giờ hết.Lý do không phải AI tạo ra code xấu (dù điều đó cũng xảy ra — nghiên cứu của NYU/Stanford năm 2022 cho thấy ~40% code do Copilot generate trong security-sensitive context chứa lỗ hổng). Lý do sâu hơn là velocity tăng nhưng comprehension không tăng tương ứng.Khi bạn tự viết code, bạn hiểu từng dòng. Khi bạn vibe code với AI, bạn có thể review và hiểu — nhưng dưới áp lực deadline, review trở thành "đọc lướt thấy trông ổn thì ship."Với business logic, đó là acceptable risk — bug có thể fix bằng hotfix.Với security, một authorization check bị bỏ sót, một input validation thiếu, một secret bị log — những thứ này có thể nằm im trong production nhiều tháng trước khi được exploit.Nguyên tắc thực tế: Với mọi code liên quan đến auth, authorization, input handling, hoặc data access — dù do AI hay bạn viết — hãy dành thêm 5 phút để hỏi: "Code này có vi phạm security invariant nào của mình không?"Năm phút đó là khoản đầu tư tốt nhất bạn có thể làm.Minimal Security Baseline Cho Solo BuilderKhông ai expect bạn implement zero-trust architecture hay ISO 27001 từ ngày đầu. Nhưng đây là baseline tối thiểu mà chi phí implement thấp hơn rất nhiều so với chi phí bỏ qua:Trước khi viết dòng code đầu tiên (2 giờ):Xác định 4-5 security invariants cho domain của bạnSetup .gitignore đúng cách, không bao giờ commit .envChọn managed auth solution thay vì tự viếtKhi build data layer:Mọi query lấy data đều filter theo owner — đây là convention, không phải optionDùng ORM với parameterized query — không bao giờ string concatenation trong SQLThiết kế data model với tư duy "ai được phép xem table này?"Khi build API layer:Authentication + Authorization tách biệt và nhất quánValidate input ở layer nhận — không tin tưởng bất kỳ thứ gì từ clientRate limiting trên mọi endpoint public, đặc biệt auth endpointTrước khi go live với user thực:Chạy OWASP ZAP hoặc tương đương để scan một lầnReview tất cả environment variable — không có gì hardcodeCó kế hoạch "nếu bị breach, tôi làm gì trong 24 giờ đầu?"Câu Hỏi Đúng Không Phải Là "Khi Nào Làm Security"Câu hỏi sai: "Nên làm security ở giai đoạn nào?"Câu hỏi đúng: "Quyết định nào hôm nay sẽ không thể sửa lại sau mà không phải trả giá rất đắt?"Với technical debt thông thường — code xấu, thiếu test, architecture chưa tốt — câu trả lời thường là "ship trước, refactor sau." Và đó là quyết định hợp lý trong nhiều trường hợp.Với security debt — auth sai, authorization thiếu, secret bị lộ, data không được isolate — câu trả lời là khác. Vì những thứ này không chỉ làm bạn chậm. Chúng có thể kết thúc mọi thứ bạn đang xây dựng.Solo builder giỏi không phải là người làm security hoàn hảo từ đầu. Mà là người biết phân biệt được: thứ gì có thể sửa sau, và thứ gì không.Đó là tư duy của người build để tồn tại — không chỉ build để ship.

Một sáng thứ Hai bình thường của năm 2026Bạn mở máy lên. Trước mặt là một task: viết API endpoint xử lý upload file, validate định dạng, lưu vào S3, trả về presigned URL.Năm 2020, task này mất của bạn nửa buổi sáng — tra docs, viết boilerplate, debug edge case.Năm 2025, bạn mở Claude Code, gõ một đoạn mô tả ngắn, nhận lại code hoàn chỉnh trong 40 giây. Review qua, chỉnh vài dòng business logic, done.Câu hỏi đặt ra không phải là "AI có thay thế developer không?" — câu đó đã được tranh luận quá nhiều và quá nhàm. Câu hỏi thực sự là:Khi phần "code" trong công việc của bạn ngày càng được AI hỗ trợ nhiều hơn, thứ gì còn lại mới thực sự là giá trị của bạn? "Code Giỏi" Từng Có Nghĩa Là GìHãy thành thật với nhau một chút.Trong suốt hai thập kỷ trước, "code giỏi" đồng nghĩa với một tập hợp kỹ năng rất cụ thể:Thuộc lòng syntax của ngôn ngữViết algorithm nhanh, sạch, ít bugDebug được những lỗi khó hiểuNhớ được API của các thư viện phổ biếnTối ưu performance theo bản năngNhững kỹ năng này có giá trị thật. Và chúng được thị trường trả giá tốt — vì chúng khan hiếm, vì không phải ai cũng bỏ công học được.Nhưng "khan hiếm" là từ khóa quan trọng ở đây.Giá trị của một kỹ năng gắn liền với mức độ khan hiếm của nó. Và trong năm 2025, khả năng viết code thuần túy — đặc biệt là code có tính chất boilerplate, lặp đi lặp lại, theo pattern — đang dần trở nên kém khan hiếm hơn. Không phải vì developer giỏi hơn. Mà vì AI đang làm được phần đó.AI Đang Làm Tốt Chính Xác Những GìĐể không rơi vào cực đoan — hoặc "AI thay thế tất cả" hoặc "AI chỉ là công cụ đơn giản" — hãy nhìn thẳng vào thực tế.Những gì AI làm tốt (và đang ngày càng tốt hơn):Viết code theo pattern đã biết. CRUD endpoint, form validation, database query cơ bản, unit test, boilerplate config — đây là địa phận AI thống trị. Nếu task của bạn có thể mô tả bằng một paragraph rõ ràng và có câu trả lời "đúng" tương đối xác định, AI làm được.Debug lỗi phổ biến. Stack trace rõ ràng? Error message có nghĩa? AI đọc và giải thích nhanh hơn hầu hết junior developer.Chuyển đổi format và refactor cơ học. Đổi từ callback sang async/await. Migrate từ class component sang hook. Format lại JSON. Viết regex. Những task mà trước đây mất hàng giờ vì nhàm chán và cần sự tỉ mỉ — AI làm trong giây lát.Tra cứu và tổng hợp tài liệu. Thay vì đọc 5 trang docs để hiểu một API, bạn hỏi AI và nhận lại đúng phần mình cần, kèm ví dụ.Và đây là con số đáng chú ý:Theo khảo sát của Stack Overflow Developer Survey 2024, hơn 76% developer đang sử dụng hoặc có kế hoạch sử dụng AI tools trong workflow. GitHub Copilot báo cáo developer viết code nhanh hơn 55% khi dùng tool của họ.55% nhanh hơn. Nghĩa là công việc mà trước đây bạn làm trong 2 giờ, giờ mất 1 giờ 20 phút. Thời gian còn lại bạn làm gì?Đây chính là câu hỏi quan trọng nhất.Vùng AI Chưa Chạm Tới — Và Có Lẽ Không Bao Giờ Chạm Tới Hoàn ToànĐây là phần nhiều người bỏ qua khi tranh luận về AI và developer.AI rất giỏi trả lời câu hỏi. Nhưng AI không tự đặt ra câu hỏi đúng.1. Hiểu Business Context để Đặt Vấn Đề ĐúngMột khách hàng đến gặp bạn và nói: "Tôi cần một cái form để người dùng submit yêu cầu."Developer bình thường sẽ hỏi: form cần những field gì, validate thế nào, lưu vào đâu.Developer giỏi sẽ hỏi: "Submit yêu cầu xong thì chuyện gì xảy ra? Ai review? Có SLA không? Người dùng cần track status không? Volume dự kiến bao nhiêu submission/ngày?"Và sau khi nghe câu trả lời, developer giỏi có thể nói: "Thực ra cái bạn cần không phải là một form. Bạn cần một mini workflow engine."AI không làm được điều này — không phải vì thiếu thông minh, mà vì AI không có skin in the game. AI không biết rằng cái form đó sẽ ảnh hưởng đến 500 nhân viên kế toán. AI không cảm nhận được sự căng thẳng trong giọng khách hàng khi nhắc đến deadline cuối quý.Đặt câu hỏi đúng — không phải trả lời đúng — là kỹ năng phân biệt người xây hệ thống với người thực thi task.2. Phán Đoán Trade-off Trong Bất ĐịnhMọi quyết định kỹ thuật thực sự đều là trade-off:Dùng microservice hay monolith cho startup 5 người?Cache aggressive để tăng tốc độ, hay chấp nhận stale data một phần?Viết abstraction layer đẹp, hay ship nhanh rồi refactor sau?Thuê thêm người hay dùng serverless để scale?Không có câu trả lời "đúng" tuyệt đối cho những câu hỏi này. Câu trả lời phụ thuộc vào: team size hiện tại, runway của công ty, technical debt có thể chịu được, ưu tiên của business tuần này.AI có thể liệt kê pros/cons của mỗi lựa chọn. Nhưng AI không thể chịu trách nhiệm cho quyết định. Và chính sự chịu trách nhiệm đó — khả năng nói "tôi chọn cái này, vì lý do này, và tôi đứng sau quyết định đó" — là thứ tạo ra trust trong team.3. Giao Tiếp Với Người Không Phải DeveloperMột trong những kỹ năng được underrate nhất trong ngành IT: giải thích kỹ thuật cho người không kỹ thuật.Không phải giải thích theo kiểu "à thực ra cái này đơn giản lắm..." rồi tiếp tục dùng jargon. Mà là thực sự dịch được vấn đề kỹ thuật sang ngôn ngữ của business: rủi ro, chi phí, thời gian, impact."Nếu chúng ta không refactor cái module này bây giờ, mỗi feature mới sẽ tốn thêm 30% thời gian develop. Trong 6 tháng tới với roadmap hiện tại, điều đó nghĩa là chúng ta chậm khoảng 3 tuần so với kế hoạch."Câu đó có giá trị hơn nhiều so với: "Technical debt đang tăng và codebase khó maintain."AI có thể giúp bạn soạn câu đó. Nhưng AI không biết roadmap 6 tháng tới của công ty bạn. Không biết sếp của bạn quan tâm đến metric nào nhất. Không biết rằng 3 tuần chậm là ngưỡng mà sếp sẽ bắt đầu lo lắng thật sự.4. Ownership — Thứ Không Thể OutsourceOwnership là gì?Ownership không phải là "tôi viết code cho feature này." Ownership là "feature này có chạy đúng không là trách nhiệm của tôi — từ lúc bắt đầu thiết kế đến lúc user không còn complain nữa."Developer có ownership sẽ:Hỏi lại requirement khi thấy ambiguous, không làm theo hiểu sai rồi đổ lỗi sauProactive monitor sau khi deploy, không chờ bị báo bugNghĩ đến edge case mà không ai yêu cầu phải nghĩKhi có vấn đề, đến với giải pháp thay vì chỉ đến với vấn đềĐây là thứ mà không AI nào làm thay được. Và đây cũng là thứ phân biệt rõ nhất những người được thăng tiến với những người không được.Vậy "Code Giỏi" Năm 2026 Có Nghĩa Là GìĐây là luận điểm cốt lõi của bài này.Định nghĩa của "code giỏi" không biến mất. Nó đang được nâng tầm.Trước đây: Code giỏi = viết được code chạy đúng, nhanh, ít bug.Bây giờ: Code giỏi = dùng AI nhân lên năng lực của mình để tạo ra impact lớn hơn nhiều lần.Đây là sự khác biệt:Developer thời cũDeveloper thời AITự viết mọi thứ từ đầu | Biết cái gì nên tự viết, cái gì để AI làmGiá trị = số dòng code | Giá trị = chất lượng quyết địnhNgại dùng tool vì "mất đi cảm giác coding" | Xem AI là force multiplierDeep expert trong một stack | T-shaped: deep + broadCode là đích đến | Code là phương tiệnNói cách khác: developer giỏi năm 2025 không phải là người code nhiều nhất. Mà là người tạo ra kết quả tốt nhất với nguồn lực ít nhất — và AI là một trong những nguồn lực đó.Ba Kỹ Năng Bạn Cần Đầu Tư Ngay Bây GiờNói lý thuyết đủ rồi. Cụ thể bạn cần làm gì?Kỹ năng 1: System Thinking — Tư Duy Hệ ThốngHọc cách nhìn vấn đề ở nhiều tầng cùng lúc:Tầng code: cái này implement thế nàoTầng system: cái này ảnh hưởng đến các component khác thế nàoTầng business: cái này giải quyết được vấn đề gì của người dùng cuốiDeveloper hay bị mắc kẹt ở tầng code. Để lên senior và xa hơn, bạn phải di chuyển được giữa cả ba tầng một cách tự nhiên.Cách luyện: Khi nhận một task, trước khi code, hãy tự hỏi: "Task này tồn tại vì business reason gì? Nếu tôi làm sai, điều tệ nhất có thể xảy ra là gì?"Kỹ năng 2: Communication — Không Phải Nói Hay, Mà Là Nói ĐúngHọc cách viết rõ ràng: ticket, PR description, comment trong code, email update cho stakeholder.Học cách đặt câu hỏi thay vì đưa ra giải pháp ngay. Câu hỏi tốt thường có giá trị hơn câu trả lời tốt.Học cách nói "không" — hoặc đúng hơn là "có, nhưng" — khi deadline không thực tế hoặc requirement mâu thuẫn nhau.Cách luyện: Viết. Mọi thứ. PR description đầy đủ thay vì "fix bug". Comment giải thích tại sao thay vì cái gì. Retrospective note sau mỗi sprint.Kỹ năng 3: Prompt Engineering + Critical Review — Cộng Sinh Với AIĐây là kỹ năng mới nhất nhưng đang trở thành yêu cầu bắt buộc.Biết cách prompt AI để ra output có ích. Không phải hỏi "viết cho tôi một cái API" mà là: "Tôi cần một REST endpoint với những constraints này, edge cases này, phải tương thích với codebase đang dùng pattern này..."Nhưng quan trọng hơn: biết review code AI tạo ra một cách phê phán. AI không sai hoàn toàn, nhưng AI hay:Bỏ sót edge case trong domain cụ thểDùng pattern cũ hoặc không phù hợp với contextViết code chạy được nhưng không maintainableTự tin quá mức vào giải pháp không tối ưuDeveloper giỏi dùng AI như một junior developer rất nhanh — cần review kỹ, cần hướng dẫn rõ, nhưng có thể delegate những task routine để tập trung vào việc quan trọng hơn.Một Cảnh Báo Quan TrọngCó một bẫy mà nhiều developer đang rơi vào khi tiếp cận AI: dùng AI để tránh né sự khó chịu của việc tư duy.Khi gặp vấn đề khó, reflex tự nhiên là hỏi AI ngay. AI trả lời. Bạn copy-paste. Done.Nhưng bằng cách đó, bạn đã bỏ lỡ đúng cái phần quan trọng nhất: quá trình vật lộn với vấn đề, hiểu tại sao nó khó, và xây dựng mental model để lần sau gặp vấn đề tương tự bạn tư duy được mà không cần công cụ.AI nên là công cụ để nhân lên năng lực sau khi bạn đã hiểu vấn đề — không phải công cụ để né tránh việc hiểu vấn đề.Nếu bạn không hiểu tại sao đoạn code AI viết ra lại đúng, bạn đang tích lũy nợ kiến thức. Và nợ đó sẽ đến hạn vào đúng lúc bạn không muốn nhất.Câu Hỏi Bạn Nên Tự Hỏi Mỗi TuầnKhông phải: "Tôi đã viết bao nhiêu dòng code tuần này?"Mà là: "Tuần này tôi đã ra được những quyết định nào? Tôi đã giải quyết được vấn đề gì mà nếu không có tôi thì sẽ không được giải quyết — hoặc giải quyết kém hơn?"Đó là thứ tạo ra giá trị thực sự. Và đó là thứ — cho dù AI có tiến bộ đến đâu — vẫn cần đến bạn.Code giỏi không còn là đích đến. Nó là ngưỡng cửa.Câu hỏi là: sau khi bước qua ngưỡng cửa đó, bạn mang theo gì?

Tôi vào nghề với một niềm tin giản dị: code tốt là đủ. Viết clean code, close ticket đúng deadline, không để bug lên production — vậy là một dev giỏi. Hơn năm năm đi làm, tôi dần trở thành người được giao task khó nhất team. Rồi đến lúc tôi nhảy vào một dự án Fintech.Tuần đầu tiên tưởng bình thường. CRUD vẫn là CRUD. API vẫn là API. Nhưng rồi có một buổi chiều, PM hỏi: "Nếu hệ thống xử lý sai số tiền của người dùng, chuyện gì xảy ra?"Tôi định trả lời theo kiểu dev: "Thì mình log lỗi rồi rollback." Nhưng nhìn khuôn mặt mọi người trong phòng — tôi hiểu câu hỏi đó không phải về technical.Trong Fintech, bug không phải là lỗi phần mềm. Bug là ai đó mất tiền thật.Từ "viết code chạy được" đến "viết code đáng tin"Dev 5 năm dạy tôi nhiều thứ: clean architecture, performance, CI/CD pipeline. Nhưng có một thứ tôi chưa từng nghĩ tới — chi phí của sự sai lầm.Trong các project trước, nếu UI hiển thị sai giá sản phẩm, user reload lại là xong. Còn khi số dư tài khoản hiển thị sai vì một race condition không ai kiểm tra — không có chuyện "reload lại là xong".Tôi bắt đầu đọc lại codebase không phải để hiểu logic làm gì, mà để hỏi: cái này sai được không? Nếu sai, sai đến đâu?Ba câu hỏi tôi học được cách đặt ra mỗi ngày:Nếu request này chạy 2 lần cùng lúc thì sao? — Idempotency không còn là khái niệm học thuật, đó là thứ phải code mỗi ngày.Khi nào transaction thực sự "xong"? — Eventual consistency đẹp trên giấy. Trong Fintech, bạn phải biết chính xác moment nào tiền "an toàn".Ai có thể xem dữ liệu này? — Authorization không chỉ là middleware. Đó là kiến trúc, là audit log, là compliance.Cái tôi tưởng là thừa, hoá ra là thiếu5 năm làm full-stack, tôi quen move fast. Nhưng Fintech dạy tôi một bài học kỳ lạ: đôi khi đi chậm mới là tạo ra value thật.Có lần tôi propose một feature tưởng là "quick win" — cho phép user xem lịch sử giao dịch real-time. Tôi tự tin lắm: websocket, 2 ngày là xong.Nhưng senior trong team hỏi: Audit log ở đâu? Nếu user dispute giao dịch, mình chứng minh bằng gì? Hệ thống fraud detection có nhận được event này không?Tôi ngồi im. Hai ngày của tôi hóa thành hai tuần — và feature đó tốt hơn rất nhiều."Làm nhiều hơn task" không phải là code thêm tính năng. Đó là hiểu tại sao task đó tồn tại — rồi làm cho mục đích đó được phục vụ thật sự.Khi dev học nói chuyện với người không biết codeMột trong những thay đổi lớn nhất không liên quan đến keyboard. Đó là học cách giải thích.Trong Fintech, quyết định kỹ thuật ảnh hưởng đến compliance, đến risk, đến tiền thật. Bạn không thể chỉ nói "tôi dùng optimistic locking để handle concurrent write" rồi kết thúc. Bạn phải nói được: "Nếu không có cơ chế này, hai người có thể rút cùng một số tiền lúc 3 giờ sáng và cả hai đều thành công."Kỹ năng dịch technical sang business impact — không ai dạy trong trường. Tôi học được từ những buổi họp awkward, từ những lần bị hỏi ngược mà không trả lời được.Công thức tôi đang tập dùng: [Quyết định kỹ thuật] giúp/ngăn chặn [điều gì xảy ra với người dùng], điều mà nếu không có sẽ gây ra [hậu quả cụ thể].Dấu ấn không nằm ở số dòng codeLần đầu tiên tôi cảm thấy mình thật sự tạo ra giá trị — không phải khi ship một feature phức tạp. Mà là lúc tôi ngồi cùng đội fraud analyst, lắng nghe họ mô tả workflow thủ công làm mỗi buổi sáng, rồi nói: "Mình có thể tự động hoá bước này."Feature đó chỉ tốn 3 ngày code. Nhưng để biết cần làm gì, tôi mất 2 tuần ngồi hiểu bài toán. Đó là thứ 5 năm trước tôi sẽ không làm — vì "đó không phải task của tôi".Fintech không cần thêm người viết code. Fintech cần người hiểu rằng code là phương tiện, không phải đích đến.Hành trình từ "dev hoàn thành task" đến "người tạo ra dấu ấn" bắt đầu bằng một câu hỏi rất đơn giản: Tại sao cái này quan trọng?Khi bạn có câu trả lời cho câu hỏi đó — mọi dòng code bạn viết ra đều có trọng lượng hơn.

"Mình xuất phát trễ hơn mọi người 4 năm.", đó là suy nghĩ của mình kể từ khi bắt đầu sự nghiệp. Với background từ dân Cơ điện tử (Mechatronics) rẽ hướng sang làm Firmware/Embedded, mình đã phải tự học, viết và debug từng dòng code.Khởi đầu một thứ mới đâu phải là chuyện giản đơn, và khởi đầu một skill set mới chưa bao giờ là điều dễ làm. Nhưng khi bản thân vừa bắt đầu quen với nhịp độ của ngành nhúng, một làn sóng lớn lại ập đến: Kỷ nguyên AI.Khi thấy các công cụ AI có thể gen ra những đoạn code C chuẩn mực hay tìm ra lỗi logic chỉ trong vài giây – những thứ từng ngốn của mình cả buổi trời – mình thực sự khựng lại. Nếu AI viết code nhanh và ít bug như thế, một người xuất phát chậm như mình lấy gì để cạnh tranh?Câu trả lời mình tìm được là: "Biết gõ code" không còn là phao cứu sinh duy nhất. Để tồn tại và phát triển, mình bắt buộc phải xây dựng một "new-normal" skill set. Nó không nằm ở tốc độ code, mà nằm ở Tư duy Hệ thống (System Thinking) và Kiến trúc Phần mềm (Software Architecture). AI có thể viết một hàm xử lý cực giỏi, nhưng nó chưa thể tự thiết kế một hệ thống mạng Mesh tối ưu, hay xử lý trọn vẹn các giao thức giao tiếp RF trong một môi trường nhiễu sóng thực tế.Thay vì cắm đầu vào code ngay lập tức, mình dành nhiều thời gian hơn để vẽ architecture, phân tích luồng dữ liệu (data flow) và thiết kế cách các task giao tiếp trong hệ điều hành thời gian thực (RTOS). Khi kiến trúc (Architecture) đã rành mạch, việc implement code hay nhờ AI hỗ trợ sẽ trở nên cực kỳ sắc bén. Mình học cách làm "Kiến trúc sư" trước khi làm "Thợ xây".Xuất phát từ Cơ điện tử hóa ra lại là một điểm cộng. Trong Embedded C, phần mềm và phần cứng luôn dính chặt lấy nhau. AI chỉ sống trong thế giới digital. Nó không thể tự tay cắm dây mạch, không thể cầm máy hiện sóng (oscilloscope) đo tín hiệu để xem tại sao phần cứng lại bị nhiễu điện từ. Nắm vững nền tảng cốt lõi ở tầng Low-level, hiểu rõ thanh ghi (registers) và cách tối ưu hóa bộ nhớ chính là mỏ neo giữ vững giá trị của một Firmware Engineer.Thay vì sợ hãi, mình dùng AI làm đòn bẩy. Mình nhờ AI tóm tắt những cuốn datasheet hàng ngàn trang khô khan, tạo các đoạn boilerplate code cơ bản, hay giải thích các concept thuật toán phức tạp. Nhờ đó, mình tiết kiệm được rất nhiều thời gian ở "phần ngọn" để dồn sức đào sâu vào "phần gốc" của bài toán.Bất kể công nghệ thay đổi chóng mặt ra sao, sự bền bỉ vẫn là vũ khí mạnh nhất. Việc duy trì nhịp độ học tập kỷ luật mỗi ngày – từ việc đọc spec, nghiên cứu công nghệ mới, đến tự tay cày cuốc các project cá nhân – giúp mình giữ được sự nhạy bén.Xuất phát trễ 4 năm không đáng sợ bằng việc đứng im. Kỷ nguyên AI không lấy đi cơ hội, nó chỉ đang ép chúng ta phải chơi một ván game ở level cao hơn. Và ở ván game này, người có tư duy kiến trúc và nền tảng vững chắc sẽ là người chiến thắng.

1. FunemploymentFunemployment = fun + unemploymentCó lẽ các bạn cũng sẽ nghĩ như mình: "thất nghiệp mà vui sao nổi".Đúng vậy, vừa mất kế sinh nhai cho bản thân và gia đình vừa chẳng tài nào vui được.Dù trước mắt ta không thể thay đổi điều đó, mà không vui quá 1 phút 30 giây đó chả được gì.Trái đất vẫn xoay và ta có thể lập trình lại bản thân.Hãy vui mừng đi! Vì mình được thoát khỏi những ngày vội vã, cật lực và chuẩn bị cho cơ hội sắp đến.2. Khi nào thất nghiệp trở thành funemployment?Nếu ta vẫn thấy mất mát và chưa sẵn sàng để nghĩ về cơ hội thì việc đơn giản nhất có lẽ là làm một giấc ngủ cho đã đời.Còn gì mà vương vấn? Vất hết hôm nay để ngày mai đầy pin mà tính tiếp.Vui ở đây có lẽ là cảm giác nhận ra giai đoạn này có ý nghĩa.Cần một động cơ cụ thể là xác định được việc cần làm, kiến thức cần học và nâng tầm giá trị bản thân.3. Làm gì để biến giai đoạn này thành tiến bộ?Một mai qua cơn mê, đây là cơ hội vàng để điều chỉnh lại trạng thái và làm những điều mình chưa có giờ thử.Chăm chút bản thân và gia đình.Cập nhật CV.Luyện tập phỏng vấn, kỹ năng mềm và ngoại ngữ.Rải CV.Bổ sung kiến thức còn thiếu từ JD hoặc thị trường.Nhìn nhận lại quy trình làm việc của bản thân.Tạo chứng minh thư cho kỹ năng của mình bằng những bản demo, bài nghiên cứu hoặc đóng góp cho cộng đồng.Gặp gỡ bạn bè trong ngành, mở rộng mối quan hệ.Có thể lúc này không có ai giúp mình nhưng có AI giúp mìnhNhìn lại thì ta thấy có cả tá việc làm muốn không xuể. Mỗi việc nhỏ đều là bước tiến, không phải thất bại.4. Thông điệp gửi đến "ta" đang lo lắngCảm giác lo âu là bình thường.Đó cũng là động lực để ta tìm kiếm và hoạch định những bước tiến tiếp theo.Bước ra khỏi phòng tắm hơi đó trước khi xỉu nhé!Thất nghiệp không định nghĩa giá trị của bạn.Đây là chương “chuyển tiếp” chứ không phải “kết thúc”.Còn thở là còn gỡ.Hãy coi đây là cơ hội để chuẩn bị cho bước tiếp theo.5. Kết luậnfunemployment là cách nhìn tích cực về thất nghiệp.Thất nghiệp có thể là khoảng thời gian để học hỏi, phát triển và tìm lại chính mình.“Bạn không hề đứng yên, bạn đang chuẩn bị cho cú nhảy tiếp theo.”Kết luận cá nhân: Đây là bước đóng góp cho cộng đồng hiếm hoi trong sự nghiệp của mình. Dù hành văn có hơi phóng túng nhưng hy vọng bà con cô bác anh chị em vui và sớm gặt hái thành công như ý nhé!Chúc mừng năm mới!