Một dev hơn 5 năm full-stack - lần đầu đặt chân vào Fintech
28/04/2026
146
views
4
#3 on leaderboard of challenge:
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ếu
5 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 code
Mộ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 code
Lầ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.
