Tech-away

Chào anh em, dạo gần đây lướt các group tuyển dụng IT hoặc trò chuyện trà đá, chúng ta rất dễ bắt gặp những câu hỏi kiểu: "Bây giờ học Go hay Rust để lương cao hơn?", "Java lỗi thời rồi, chuyển sang Node.js lương có khá hơn không?", hay "Có phải cứ biết Python, AI là auto ngàn đô?"...Tôi từng là một kẻ tin sái cổ vào cái "truyền thuyết" ấy. Tôi từng nghĩ đơn giản: Tech stack càng hot, càng ít người làm được thì lương càng cao.Nhưng sau gần 8 năm lăn lộn từ Outsourcing đến Product, từ các công ty startup quy mô 5 người cho đến tập đoàn lớn, tôi nhận ra: Tech stack chỉ là "bề nổi của tảng băng chìm". Nó có thể quyết định mức lương khởi điểm của bạn ở một công ty mới, nhưng KHÔNG quyết định được trần thu nhập (salary ceiling) của bạn.Dưới đây là câu chuyện xương máu của tôi về một lần "nhảy stack" vì tiền và những bài học đắt giá tôi đúc kết được.1. Cú ngã "trần trụi" khi chạy theo tiếng gọi của "Stack Hot"Cách đây 4 năm, khi làn sóng Blockchain và Web3 bùng nổ, đi đâu tôi cũng nghe thấy những con số giật mình: "Developer viết Rust/Solidity lương 4000 - 5000 USD/tháng". Lúc đó, tôi đang là một Web Developer cứng cựa với Node.js và React, mức lương khá ổn định nhưng nhìn con số kia thì không khỏi lung lay.Nghĩ là làm, tôi lao vào "vibe coding" ngày đêm. Tôi học cú pháp Rust, clone các repo ví mẫu, viết vài cái smart contract cơ bản. Sau 2 tháng học cấp tốc, tôi tự tin apply vào một dự án Web3 của nước ngoài với mức lương deal cao hơn 50% mức cũ.Và... quả đắng xuất hiện ngay từ tháng thử việc thứ hai.Khi dự án bước vào giai đoạn scale up, đòi hỏi tối ưu hóa bộ nhớ, xử lý concurrency cực đoan và bảo mật smart contract để tránh bị hack (vốn là chuyện cơm bữa trong Web3), tôi bắt đầu đuối sức. Tôi chỉ biết viết code cho chạy được, chứ hoàn toàn rỗng tuếch về:Cách hoạt động sâu bên dưới của Memory Management (đặc biệt là cơ chế Borrow Checker cực kỳ nghiêm ngặt của Rust).Kiến thức về cryptography (mã hóa) và bảo mật hệ thống phân tán.Tư duy giải quyết bài toán tài chính phức tạp của hệ thống DeFi.Kết quả là hệ thống liên tục gặp bug nghẽn mạng, code của tôi liên tục bị Senior từ chối merge. Áp lực kinh khủng khiến tôi mất ngủ triền miên. Cuối cùng, tôi chủ động xin dừng lại vì nhận ra mình đang giữ một chiếc áo quá rộng. Tôi chọn đổi stack vì tiền, nhưng năng lực thực tế của tôi chỉ nằm ở mức "biết cú pháp" chứ chưa làm chủ được công nghệ đó.2. Thấu hiểu bản chất: Điều gì thực sự quyết định mức lương IT?Sau thất bại đó, tôi quay lại làm việc với Node.js và hệ sinh thái Web truyền thống nhưng với một tâm thế hoàn toàn khác. Thay vì chạy theo ngôn ngữ mới, tôi tập trung đào sâu những thứ "bất biến" trong công nghệ.Tôi nhận ra mức lương của một Developer được cấu thành từ 3 yếu tố cốt lõi (Tỷ lệ 20-50-30):Tech Stack (20%): Chỉ là công cụ truyền tải giải pháp. Biết Rust hay Java không quan trọng bằng việc bạn biết dùng nó để giải quyết vấn đề gì.Domain Knowledge - Kiến thức nghiệp vụ (50%): Đây mới là thứ hái ra tiền. Một Node.js Dev thông thường lương có thể là $1,500. Nhưng một Node.js Dev hiểu sâu về hệ thống thanh toán điện tử (Payment Gateway), biết cách xử lý đối soát, chống gian lận tài chính và đạt chứng chỉ bảo mật PCI-DSS thì mức lương hoàn toàn có thể là $3,500+. Họ trả tiền cho sự am hiểu ngành nghề của bạn, không phải trả tiền cho số dòng code bạn gõ.Problem Solving & Soft Skills (30%): Khả năng đàm phán, quản lý rủi ro, tối ưu hóa chi phí cloud và trình bày giải pháp kỹ thuật cho những người không làm kỹ thuật hiểu.3. Bài học xương máu: Cách định vị bản thân để bứt phá thu nhậpNếu nhìn lại, tôi không hối hận vì đã thử học Rust, nhưng tôi sẽ thay đổi cách tiếp cận. Thay vì nhảy stack bạt mạng vì trào lưu, tôi khuyên anh em nên áp dụng chiến lược T-Shape Developer:Trục ngang (Biết rộng): Hiểu nguyên lý hoạt động của các stack khác nhau để khi cần có thể phối hợp hoặc chuyển đổi nhanh chóng.Trục dọc (Sâu sắc): Chọn một stack cốt lõi và biến mình thành chuyên gia trong lĩnh vực đó. Trở thành người "không thể thay thế" ở một mảng thay vì việc gì cũng biết nhưng chỉ ở mức hời hợt.Tập trung vào "Bài toán khó" thay vì "Ngôn ngữ mới": Nếu công ty bạn đang gặp vấn đề về lag database, hãy chủ động đứng ra giải quyết (bằng cách tối ưu index, query, caching...). Việc bạn giải quyết được "nỗi đau" của doanh nghiệp sẽ trực tiếp giúp bạn có vị thế cực lớn khi đàm phán lương (Performance Review), bất kể bạn đang dùng PHP, Java hay Go.Lời kết cho anh em: Đừng thần thánh hóa bất kỳ tech stack nào. Ngôn ngữ lập trình suy cho cùng chỉ là những chiếc tuốc-nơ-vít khác nhau trong hộp đồ nghề của bạn. Người thợ giỏi được trả lương cao không phải vì họ sở hữu chiếc tuốc-nơ-vít đắt tiền nhất, mà vì họ biết cách sửa những cỗ máy phức tạp nhất.Chúc anh em tìm được trục dọc của đời mình và bứt phá thu nhập trong kỳ review sắp tới!

Thuật ngữ "Vibe coding" dạo gần đây hot rần rần. Cái cảm giác nửa đêm ngồi thả hồn theo prompt, đưa ý tưởng cho AI rồi xem nó "vẽ" ra một ứng dụng hoàn chỉnh trong vài tiếng đồng hồ nó... sướng tê người. Là một solo builder, tôi từng nghiện cái cảm giác đó. Tốc độ là lẽ sống. Ship sản phẩm nhanh là chân lý.Nhưng, cái "vibe" đó thường chỉ kéo dài cho đến khi bạn nhận được email đầu tiên từ một người dùng lạ hoắc, báo rằng họ vừa tìm thấy một lỗ hổng có thể đọc được database của toàn bộ hệ thống.Đó là câu chuyện thật của tôi, và là lúc tôi nhận ra: Vibe coding rất vui, cho đến khi security tìm tới gõ cửa.1. Giai đoạn "Điếc không sợ súng" và cú tát từ thực tếKhi bắt đầu dự án SaaS cá nhân đầu tiên, tôi đặt mục tiêu: MVP (Minimum Viable Product) phải lên sóng trong 2 tuần.Để đạt được tốc độ đó, tôi phó mặc rất nhiều thứ cho AI và các boilerplate có sẵn. Tôi chỉ tập trung vào UI/UX, tính năng cốt lõi và luồng thanh toán. Còn bảo mật? Tôi tự nhủ: "Thôi kệ, app đã có ai dùng đâu mà hack, để sau tính!"Tôi đã làm những điều mà bây giờ nghĩ lại phải rùng mình:Để nguyên các thiết lập CORS (Cross-Origin Resource Sharing) dạng * cho tiện test.Cơ chế phân quyền (Authorization) lỏng lẻo, chỉ check ở Client-side mà bỏ quên Validation kỹ càng ở Backend.Sử dụng API key trực tiếp trong code thay vì cấu hình biến môi trường (Environment Variables) cẩn thận, suýt chút nữa là commit thẳng lên GitHub public.Sản phẩm may mắn được đón nhận, user tăng trưởng nhanh ngoài mong đợi. Và chuyện gì đến cũng đến. Một ngày đẹp trời, một cậu bạn là Sec-engineer vào dùng thử app và nhắn tin riêng cho tôi: "Ông ơi, tui vừa bypass qua cái middleware của ông bằng cách sửa ID trên URL này. Fix gấp đi không lộ hết data khách hàng."Mồ hôi hột tôi tuôn ra. Lúc đó tôi mới thấm câu nói: Nợ kỹ thuật (Technical Debt) về tính năng thì trả bằng thời gian, nhưng nợ về bảo mật thì phải trả bằng uy tín và cả tiền bạc.2. Bài toán dung hòa: Tốc độ vs An toànSau cú sụp tim đó, tôi buộc phải dừng việc build tính năng mới trong 2 tuần chỉ để rà soát và vá lỗ hổng. Quy trình build nhanh, làm gọn trước đó bị xáo trộn hoàn toàn.Là solo builder, chúng ta không có một team Security riêng biệt để audit code. Nhưng nếu để bảo mật sang một bên, bạn đang tự đặt một quả bom hẹn giờ dưới chân mình. Vậy tôi đã dung hòa hai yếu tố này thế nào trong những dự án sau?Tôi chuyển từ "Vibe coding bạt mạng" sang "Smart Vibe Coding" với quy tắc: Chậm lại 5% ở những chỗ chí mạng.Cái gì hiệu quả?Chốt chặn ở Backend, thả lỏng ở Frontend: Bạn có thể dùng AI để sinh code UI nhanh, lỗi một chút cũng không sao. Nhưng riêng logic liên quan đến Authentication, Authorization và Database Validation ở Backend, tôi luôn tự tay review, không "phó mặc hoàn toàn" cho AI nữa.Tận dụng công cụ quét tự động (DevSecOps cho Solo Builder): Tôi tích hợp Snyk và GitHub Dependabot vào repo. Cứ mỗi lần push code, công cụ sẽ tự động check xem thư viện nào có lỗ hổng (CVE) hay không. Việc này mất thêm 1-2 phút setup ban đầu nhưng cứu mạng tôi vô số lần về sau.Tư duy "Zero Trust" ngay từ đầu: Hãy coi mọi dữ liệu gửi lên từ Client đều là "độc hại" cho đến khi được chứng minh ngược lại.Cái gì chưa hiệu quả?Cố gắng áp dụng các tiêu chuẩn bảo mật quá khắt khe của doanh nghiệp lớn (như Pentest chuyên sâu, Compliance phức tạp) vào giai đoạn MVP. Việc này làm thui chột tốc độ và khiến dự án chết yểu trước khi kịp ra thị trường. Hãy nhớ: Bảo mật vừa đủ với quy mô của app.3. Nếu nhìn lại, tôi có thay đổi cách build của mình?Chắc chắn là CÓ. Nếu quay lại vạch xuất phát, tôi vẫn chọn Vibe coding để giữ ngọn lửa đam mê và tốc độ, nhưng tôi sẽ đổi cách tiếp cận sang Security-by-Design ở mức tối giản (Minimal Viable Security).Thay vì đợi app lớn rồi mới sửa (refactor) – việc mà tôi cam đoan là cực kỳ đau khổ vì code lúc đó đã rối như tơ vò – tôi chọn cách xây dựng một "khung xương" an toàn ngay từ ngày đầu tiên:Chốt format bảo mật chuẩn từ Day 1: Thiết lập JWT, Hash password, phân quyền rõ ràng ngay từ route đầu tiên.Environment Variables là bất di bất dịch: Tuyệt đối không hardcode bất kỳ secret key nào, dù là dự án test.Lời kết & Bài học cho các Solo BuilderGửi các anh em solo builder đang ngày đêm "vibe" cùng AI: Tốc độ giúp bạn sống sót trên thị trường, nhưng bảo mật mới là thứ giúp bạn giữ được sự sống đó.Đừng đợi đến khi data người dùng bị đem rao bán trên các diễn đàn rồi mới ngồi khóc vạch lối sửa sai. Hãy biến bảo mật thành một phần của "vibe". Khi bạn tạo một component mới, hãy dành ra đúng 30 giây để tự hỏi: "Nếu user truyền data bậy vào đây, hệ thống có sập không?". Chỉ cần bấy nhiêu thôi, bạn đã đi trước 80% các sản phẩm chắp vá ngoài kia rồi.Chúc anh em ship app nhanh, mượt và... ngủ ngon giấc mỗi đêm!Bạn đã từng phải trả giá cho một tính năng build quá nhanh chưa? Hãy để lại bình luận chia sẻ câu chuyện "chữa cháy" của bạn nhé!

Yes, you are making it happen!  Đặt câu hỏi nhé: Sáng nay bạn trả tiền ăn sáng bằng gì ? Nếu câu trả lời là Apple Pay, Google Pay, Wallet hay QR Code... Thì bạn đang góp phần thúc đẩy fintech tại Việt Nam và Đông Nam Á này đâý nhé. Thực tế là "Ví số" đã thay Ví da! Ít năm trước, trả tiền bằng thẻ tín dụng rất là "Tây", người Việt mình thì cứ móc tiền mặt cho nhanh... Nay thì app đặt xe, momo, thanh toán QR  — mọi thứ được thực hiện trên điện thoại đã thành quen rồi. Và Việt Nam không chỉ bắt kịp, mà đang dẫn đầu khu vực trong tỷ lệ tiếp nhận thanh toán số ở ĐNA này. Disruptive technology tìm thấy thị phần lớn ở đây không phải vì người Việt dễ dãi, mà vì chúng ta nhanh nhạy với mọi giải pháp thực sự mang lại giá trị so với các nước khác trong khu vực. Trạm kế tiếp chính là: Thanh Toán Bằng QRNapas VietQR, AliPay, và nhiều player khác đang tăng tốc trong việc tạo ra các giải pháp ở Vietnam. Khi các tổ chức Chuyển Mạch Switching, Payment Rails và Regional Payment Network mở cửa cho người dùng Việt, QR Pay là điểm đến tất yếu. Có lẽ sau Trung Quốc, Vietnam ta đang dẫn đầu rồi. Tất nhiên, dân làm sản phẩm, đặc biệt là Technical product sẽ luôn ở tuyến đầu, kiến tạo, xây dựng nên trải nghiệm. Nhưng product giỏi đến mấy cũng vô nghĩa nếu thị trường không phản hồi. Và thị trường Việt Nam, người dân Việt Nam đã là nhân tố lớn nhất  đóng góp cho sự chuyển dịch trong Fintech này. Ngay lúc chạm màn hình thanh toán bữa sáng nay, chúng ta đã thay đổi cách mà bankings và financial system vận hành rồi.