Não Bạn Có 2 CPU — Và Cái Nhanh Thì Toàn Sai
Não bạn có 2 CPU. Một cái xử lý nhanh như Redis, tự động, không cần bạn cho phép. Một cái chậm như cái query chưa đánh index, phải chủ động gọi mới chịu chạy. Và tin buồn là: cái nhanh gần như điều khiển cuộc đời bạn — kể cả những lúc bạn tưởng mình đang “suy nghĩ kỹ”.
CPU 1 — Bộ Xử Lý Cache
Đây là cái CPU chạy mặc định. Nó nhanh, tự động, gần như không tốn năng lượng. Nó xử lý mọi thứ bằng pattern matching — giống kiểu “à, đã gặp cái tương tự rồi, áp đáp án cũ vào luôn”.
- Bạn nhìn đoạn code và “cảm giác” nó có bug — chưa đọc kỹ, nhưng linh tính bảo sai.
- Bạn gặp người lạ và trong 3 giây đã có ấn tượng “tin được” hay “không tin được”.
- Bạn nghe tiếng notification và tay tự động mở điện thoại — não thậm chí chưa kịp xử lý.
CPU 1 là lý do bạn lái xe về nhà mà không cần nghĩ đường đi. Nó giỏi, nó nhanh, nó cần thiết.
CPU 2 — Bộ Xử Lý Deep Processing
Đây là cái CPU bạn phải chủ động bật. Nó chậm, tốn năng lượng, và não bạn rất ghét dùng nó — giống dev ghét viết documentation vậy.
- Khi bạn ngồi debug từng dòng, trace logic, vẽ diagram trước khi code.
- Khi bạn cân nhắc 3 cái offer và liệt kê ưu nhược điểm từng cái ra giấy.
- Khi bạn đọc một bài toán khó và phải dừng lại, tắt nhạc, tập trung hoàn toàn.
CPU 2 cho ra kết quả chính xác hơn hẳn. Nhưng vấn đề là: nó lười. Nó chỉ bật khi bị ép. Và CPU 1 luôn chạy trước, luôn đưa ra “đáp án” trước — nên đa số lúc, CPU 2 thấy “ừ có đáp án rồi, nghỉ thôi” và tiếp tục ngủ.
“Thay Câu Hỏi” — Não Tự Động Rewrite Cái Bạn Đang Nghĩ
Đây là bug nguy hiểm nhất mà ít ai nhận ra.
Khi gặp một câu hỏi khó, não bạn không giải nó. Não bạn lặng lẽ thay bằng một câu hỏi dễ hơn — rồi giải câu đó và trả lại cho bạn, mà bạn tưởng mình đã trả lời đúng câu hỏi gốc.
| Câu hỏi thật | Câu hỏi não thay vào |
|---|---|
| “Công nghệ nào phù hợp với dự án này?” | “Công nghệ nào đang hot trên Twitter?” |
| “Mình có nên nhận công việc này không?” | “Văn phòng công ty này có đẹp không?” |
| “Bài toán này có cách giải tối ưu hơn?” | “Cách đầu tiên mình nghĩ ra có chạy được không?” |
| “Người này có đáng tin không?” | “Người này có dễ thương không?” |
Não bạn giống cái middleware tự ý rewrite request trước khi nó đến server thật. Bạn gửi GET /best-technology, nhưng middleware đổi thành GET /trending-technology — và bạn không hay biết.
Đây là lý do nhiều sinh viên chọn ngành, chọn công ty, chọn công nghệ — dựa trên những tiêu chí hoàn toàn không liên quan đến câu hỏi thật sự cần trả lời. Không phải vì ngu — mà vì não đã “giúp” bạn đơn giản hóa mà không xin phép.
Mỗi khi ra quyết định quan trọng, viết ra giấy: “Câu hỏi mình đang thật sự cần trả lời là gì?” Rồi kiểm tra: cái mình đang dùng để đánh giá có đúng là tiêu chí cho câu hỏi này không? Đa số lúc — bạn sẽ phát hiện mình đang trả lời nhầm câu 🙂
“Tự Tin Quá Mức” — Bug Mà Ai Cũng Có Nhưng Không Ai Thừa Nhận
Bạn có bao giờ estimate task mất 2 ngày — rồi thực tế mất 2 tuần không?
Bạn có bao giờ nghĩ “môn này dễ, tuần sau thi ôn cũng kịp” — rồi rớt không?
Bạn có bao giờ chắc chắn code mình đúng, quyết định không viết test — rồi production crash vào lúc 2 giờ sáng không?
Chào mừng bạn đến với bug kinh điển nhất trong lịch sử loài người: quá tự tin vào chính mình.
Cái này không phải kiêu ngạo. Đây là lỗi mặc định của não. Khi bạn biết một chút về cái gì đó, não tự động khuếch đại cái “một chút” đó lên thành “biết đủ rồi”. Bạn đọc 1 bài blog về Kubernetes, não bạn file nó vào mục “đã hiểu Kubernetes”. Bạn giải được 1 bài LeetCode medium, não bạn file vào mục “thuật toán ổn rồi”.
Và cái nguy hiểm nhất: người càng biết ít thì càng tự tin. Vì họ không biết đủ để biết mình không biết. Người mới học code 2 tháng dám nói “React dễ lắm”. Người code 10 năm nói “React phức tạp hơn mình tưởng”. Không phải vì người 10 năm kém hơn — mà vì họ đã thấy đủ edge case để biết mình chưa biết hết.
Mỗi khi bạn cảm thấy “chắc chắn” về điều gì đó — hãy coi đó là tín hiệu để kiểm tra lại. Đặc biệt khi estimate thời gian: lấy con số bạn nghĩ trong đầu, nhân 2, rồi cộng thêm buffer. Nghe bi quan — nhưng đó mới là realistic.
“Dễ Nhớ = Phổ Biến” — Khi Não Đánh Giá Xác Suất Bằng Cảm Xúc
Mình hỏi bạn: ngành IT có đang “chết” không?
Nếu tuần vừa rồi bạn đọc 5 bài về layoff trên LinkedIn, câu trả lời trong đầu bạn có lẽ là “có, đang xuống lắm”. Nhưng nếu tuần vừa rồi bạn thấy 3 bài về startup gọi vốn thành công, câu trả lời sẽ là “không, vẫn đang hot”.
Cùng một thực tế. Khác nhau ở chỗ bạn đọc gì gần đây.
Não bạn không đánh giá xác suất bằng dữ liệu — nó đánh giá bằng cái gì dễ nhớ nhất. Cái gì xuất hiện nhiều trên newsfeed, cái gì có tiêu đề giật gân, cái gì gắn với cảm xúc mạnh — não sẽ đánh giá nó là “phổ biến” và “có khả năng cao xảy ra”.
Cái này giống như bạn chỉ đọc log ERROR mà không đọc log INFO — rồi kết luận hệ thống sắp sập. Trong khi thực tế 99% request vẫn thành công, nhưng bạn không thấy vì chúng không “nổi bật”.
Khi bạn có một nhận định mạnh về xu hướng nào đó — hãy hỏi: “Mình biết điều này vì dữ liệu thật, hay vì mình vừa đọc mấy bài trên mạng?” Nếu nguồn tin chỉ là newsfeed và cảm giác — thì đó không phải dữ liệu, đó là tiếng ồn.
“Khung Nhìn” — Cùng Một Sự Thật, Nói Khác Là Cảm Khác
Mình cho bạn hai câu:
Cùng một sự thật. Nhưng đọc câu A bạn thấy ổn, đọc câu B bạn thấy lo. Đúng không?
Đây là bug “khung nhìn” — cách một thông tin được đóng gói ảnh hưởng cách bạn phản ứng với nó, dù nội dung bên trong giống hệt nhau.
Khung nhìn không chỉ ảnh hưởng người nghe — nó ảnh hưởng cả chính bạn. Nếu bạn frame bản thân là “người mới, chưa biết gì” — bạn sẽ hành xử rụt rè. Nếu bạn frame bản thân là “người đang học, đang phát triển” — bạn sẽ chủ động hơn, dù trình độ y chang.
Bạn không thể kiểm soát sự thật — nhưng bạn có thể chọn khung nhìn. Khi tự nói chuyện với bản thân, khi viết CV, khi trình bày ý tưởng — hãy chọn cái frame trung thực nhưng có lợi nhất. Đó không phải nói dối — đó là kỹ năng giao tiếp với chính mình.
“Cái Gì Đến Trước Thì Thắng” — Mỏ Neo Thông Tin
Bạn đang xem một khóa học online. Giá gốc 2.000.000đ, đang giảm còn 399.000đ. Rẻ quá, mua liền.
Nhưng khoan — bạn có biết khóa đó có đáng 399k không? Có khi chất lượng chỉ đáng 200k. Nhưng bạn không đánh giá 399k theo giá trị thật — bạn đánh giá nó so với 2 triệu. Và so với 2 triệu thì 399k tất nhiên “hời”.
Cái con số 2 triệu đó chính là “mỏ neo”. Não bạn nhìn thấy nó đầu tiên, và mọi đánh giá sau đó đều xoay quanh nó — dù nó có thể hoàn toàn vô nghĩa.
Bạn xem video ai đó giải bài LeetCode hard trong 10 phút. Cái “10 phút” đó neo vào đầu bạn. Bạn ngồi 2 tiếng chưa xong và tự thấy mình ngu. Nhưng bạn quên: video đó đã cắt edit, người đó đã giải bài này 5 lần trước khi quay.
Bạn thấy bạn bè đăng ảnh đi du lịch, mua xe, lương cao. Những hình ảnh đó neo vào đầu bạn. Bạn nhìn lại bản thân và thấy thiếu. Nhưng bạn đang so cuộc đời thật của mình với phần highlight reel đã được chọn lọc kỹ của người khác.
Mỗi khi đánh giá điều gì, tự hỏi: “Có con số nào, hình ảnh nào đang ảnh hưởng cách mình nhìn không?” Nếu có — tạm gạt nó ra, đánh giá lại từ đầu. Giống như reset biến trước khi chạy hàm mới — đừng để giá trị cũ làm nhiễu kết quả.
“Nhìn Đâu Cũng Thấy Pattern” — Não Kể Chuyện Giỏi Hơn Phân Tích
Bạn gặp 3 người học CNTT ra làm content creator thành công. Não bạn ngay lập tức dệt thành câu chuyện: “Dân IT chuyển sang làm content là xu hướng.” Nhưng thực tế: 3 người trên tổng số hàng trăm nghìn sinh viên IT — đó là tiếng ồn, không phải tín hiệu.
Bạn thi rớt 2 môn liên tiếp. Não bạn dệt thành: “Mình không hợp với ngành này.” Nhưng thực tế: có thể chỉ là phương pháp học sai, hoặc đơn giản là 2 môn đó khó hơn bạn nghĩ.
Bug này đặc biệt nguy hiểm vì câu chuyện nghe rất logic. Nó có nhân vật, có nguyên nhân, có kết quả. Nhưng logic của câu chuyện không bằng logic của thực tế. Chỉ vì bạn giải thích được TẠI SAO một chuyện xảy ra — không có nghĩa bạn dự đoán được nó SẼ xảy ra.
Khi bạn thấy mình đang rút ra bài học từ 2-3 ví dụ — hãy dừng lại. Hỏi: “Mình có đang bịa ra pattern từ dữ liệu quá ít không?” Não bạn muốn câu chuyện — nhưng thực tế cần sample size lớn hơn 3 🙂
“Cảm Xúc Là Filter Mặc Định” — Bạn Không Đánh Giá, Bạn Đang Cảm Nhận
Bạn đang vui → đọc CV ứng viên thấy “tiềm năng”. Bạn đang mệt → cùng CV đó thấy “thiếu kinh nghiệm”.
Bạn vừa ăn ngon → ngồi code thấy project thú vị. Bạn vừa cãi nhau với ai đó → cùng project đó thấy “chán, không muốn làm”.
Cái nguy hiểm là: bạn không nhận ra cảm xúc đang ảnh hưởng vào lúc nó đang ảnh hưởng. Bạn nghĩ mình đang đánh giá khách quan, nhưng thực ra cảm xúc đã chạy trước và filter toàn bộ thông tin trước khi nó đến CPU 2.
Giống middleware chèn header vào request: dữ liệu đến server trông vẫn bình thường, nhưng đã bị sửa rồi.
Ứng dụng thực tế cực kỳ quan trọng:
Đừng bao giờ reply email quan trọng khi đang tức. Viết ra, lưu draft, ngủ 1 giấc, đọc lại sáng hôm sau.
Đừng quyết định chuyển việc khi đang trong giai đoạn burnout. Có thể bạn không ghét công việc — bạn chỉ đang cần nghỉ ngơi.
Đừng đánh giá bản thân lúc 11 giờ đêm sau một ngày dài. Lúc đó não bạn thấy cái gì cũng tệ — kể cả bản thân.
Với quyết định quan trọng, luôn tự hỏi: “Mình đang ở trạng thái cảm xúc gì?” Nếu đang ở cực — trì hoãn quyết định. Đợi khi cảm xúc về mức trung tính rồi hãy quyết. Không gấp đâu — mấy quyết định thay đổi cuộc đời hiếm khi cần trả lời trong 5 phút.
Vậy Thì — Sống Sao Với 2 CPU?
Bạn không cần fix hết. CPU 1 không phải kẻ thù — nó giúp bạn sống sót hàng ngày. Cuộc sống không thể chạy hoàn toàn trên CPU 2 — bạn sẽ kiệt sức trong 2 tiếng.
Cái bạn cần là: biết khi nào nên ép CPU 2 bật dậy. Những quyết định nhỏ — cứ để CPU 1. Những quyết định lớn — chọn nghề, chọn công ty, chọn stack — hãy dừng lại, viết ra giấy, phân tích, và đừng tin cái “cảm giác” đầu tiên.
Và quan trọng nhất: hãy nghi ngờ sự tự tin của chính mình. Không phải để bi quan — mà để tỉnh táo.
Nếu bạn đọc đến đây và nhận ra ít nhất 2 bug mình đang dính — chúc mừng, CPU 2 của bạn vừa thức dậy. Giờ đi code đi. 🙂
PHẦN 2 → 1% Mỗi Ngày — Cách Build Thói Quen Mà Không Cần Ý Chí
