Công nghệ không phải là giải quyết vấn đề. Mà là chọn cái giá phải trả.

Xin chào mọi người,

Gần đây mình chuyển sang một môi trường mới và có cơ hội được training trực tiếp bởi một CTO. Ban đầu mình nghĩ:

“Chắc lại lý thuyết suông thôi, nghe cho biết.”

Nhưng bất ngờ thay, người học được nhiều nhất buổi đó lại là mình. Thứ mình học được không phải công nghệ mới, cũng chẳng phải pattern gì cao siêu. Mà là một thứ nghe rất quen:

Trade-off.

Trước đó mình cũng “biết” trade-off. Kiểu: “Ừ thì cái gì cũng có giá của nó.” Nhưng chỉ dừng ở mức biết thôi.

Sau lần đó thì khác. Mình bắt đầu nghĩ thế này:

Mọi quyết định đều là trade-off.

Và bạn buộc phải chọn — kể cả khi bạn không muốn.

Một ví dụ đơn giản

Xây một sản phẩm từ đầu. Có 2 hướng:

Hướng 1 — Làm “đúng bài”

• Thiết kế sạch sẽ
• Tách service
• Tối ưu performance → Mất vài tháng

Hướng 2 — Làm nhanh

• Gom logic lại
• Chưa cần scale
• Chạy được là được → Mất 2 tuần

Câu hỏi thực sự là: Bạn chọn cái nào?

Nếu chọn Hướng 1: → Hệ thống đẹp, scale được. → Nhưng có khi… chẳng bao giờ có user để mà scale.

Nếu chọn Hướng 2: → Ra sản phẩm nhanh. → Nhưng sau này chắc chắn phải trả nợ.

Không cái nào “đúng” cả. Chỉ có: Ở thời điểm này, bạn đang ưu tiên cái gì?

AI không giải quyết được chuyện này

Nhiều người giờ nghĩ: “Có AI rồi, không cần nghĩ trade-off nữa. Cứ generate code là xong.”

Nhưng đó là cái bẫy. AI giúp bạn code nhanh gấp 10 lần. → Nghĩa là bạn cũng tạo ra rác kỹ thuật nhanh gấp 10 lần.

AI giống như siêu xe. Nếu bạn không biết mình đang ở:

• Đường cao tốc (cần tốc độ), hay
• Ngõ hẻm (cần kiểm soát) …thì nó chỉ giúp bạn đâm tường nhanh hơn thôi.

Ví dụ nhỏ hơn, nhưng xảy ra mỗi ngày

Mình từng hỏi: “Ở đây có thật sự cần Repository không? Hay mình chỉ đang làm vì ‘người ta bảo nên làm’?”

Theo lý thuyết: → Repository giúp tách DB, sau dễ đổi.

Nhưng thực tế:

• Project nhỏ.
• DB gần như không bao giờ đổi. → Thêm Repository chỉ làm code phức tạp hơn.

Lúc đó mình nhận ra: Nhiều khi chúng ta không giải quyết vấn đề. Chúng ta chỉ đang chạy theo chuẩn — mà không biết nó có cần thiết không.

Và cái giá phải trả là:

• Nhiều code hơn.
• Khó đọc hơn.
• Debug mệt hơn. …chỉ để đổi lấy thứ mà… có khi chẳng bao giờ dùng đến.

Và có thứ còn khó chịu hơn

Sau một thời gian, mình nhận ra thêm: Nhiều khi mình tưởng mình đang “được chọn”. Nhưng thực ra… mình không có nhiều lựa chọn như mình nghĩ.

• Deadline đang dí.
• Team nhỏ.
• Sản phẩm chưa có user. → Bạn không có quyền làm đẹp.

Ngược lại:

• Có user.
• Có traffic.
• Có team maintain. → Bạn không được phép làm ẩu nữa.

Một quyết định ngu có thể trả giá bằng:

• Downtime.
• Mất user.
• Mất tiền.

Nghĩa là: Không phải lúc nào bạn cũng được chọn trade-off. Hoàn cảnh chọn trước cho bạn rồi.

Cách mình nghĩ bây giờ

Trước mình hay hỏi: “Cách này có tốt không?” Giờ mình hỏi:

• Khi nào nên hack?
• Khi nào phải làm “đàng hoàng”?
• Và dấu hiệu nào cho thấy mình đang chọn sai?

Ví dụ rất thẳng:

• Chưa có user → Ưu tiên tốc độ.
• Đã có user → Ưu tiên ổn định.
• Code một mình → Có thể liều.
• Code với team → Không còn quyền ích kỷ.

Kết

Cuối cùng, mình nhận ra một điều rất đơn giản: Trade-off không phải là bạn thích cái nào. Mà là hoàn cảnh cho phép bạn trả cái giá nào.

Và sâu hơn một chút:

Bạn không giải quyết vấn đề. Bạn chỉ chọn vấn đề nào để chấp nhận.