Cùng 12 bug cần fix. Developer A mất 14 phút mỗi bug và tạo thêm 11 bug mới trong quá trình sửa. Developer B mất 5 phút mỗi bug, không tạo thêm bug nào.
Hai người cùng thâm niên. Khác biệt duy nhất: cách họ đã học lập trình từ đầu.
Vòng lặp không ai nói với bạn
Rất nhiều developer rơi vào vòng lặp này: xem tutorial → làm theo → chạy được → quên. Tuần sau lại xem tutorial khác.
Vấn đề không phải bạn lười hay kém thông minh. Vấn đề là bạn đang học cú pháp trong khi kỹ năng thực sự cần học là xây dựng mental model — đây chính là lý do thật sự khiến nhiều dev không tiến bộ sau 2 năm code.
Đọc code không giống viết code. Làm theo tutorial không giống giải quyết vấn đề thật. Hai việc đó kích hoạt hai phần khác nhau của não.
Học Lập Trình Đúng Cách: Não Hoạt Động Như Thế Nào?
Nghiên cứu trên lập trình viên (dựa trên mô hình chunking của Chase và Simon) cho thấy: sự khác biệt giữa expert và novice không phải trí thông minh, mà là knowledge structure — cấu trúc kiến thức trong não.
Expert nhớ code tốt hơn không phải vì não họ to hơn. Mà vì code có nghĩa với họ — nó khớp với các pattern đã có sẵn trong đầu.
Khi bạn chỉ học cú pháp: não dùng working memory để parse từng dòng một — như đọc từng chữ thay vì đọc cả câu. Cognitive load cao, tiến độ chậm.
Khi bạn xây knowledge structure: não chunk nhiều thứ lại thành một khái niệm. Thay vì nghĩ “con trỏ dịch chuyển qua linked list”, bạn chỉ nghĩ “append”. Còn lại bộ nhớ cho vấn đề thật sự.
Đây cũng là lý do tại sao khi code bị xáo trộn ngẫu nhiên, expert mất hẳn lợi thế ghi nhớ. Họ không nhớ từng token — họ nhớ ý nghĩa.
Hai developer, cùng một bug
Một ứng dụng có operation chạy chậm đến mức team coi đó là “giới hạn tự nhiên của công nghệ” — không ai nghĩ có thể fix được.
Developer A — học theo tutorial: Thử thay < thành <=. Thử đổi thứ tự vòng lặp. Random tweak code mà không hiểu tại sao. Code khó đọc hơn, vẫn không nhanh hơn.
Developer B — hiểu hệ thống: Không sửa application code. Nhìn vào database. Phát hiện bảng được query nhiều nhất không có index.
Thêm một index. Operation nhanh hơn 30 lần.
Không phải vì B thông minh hơn. Mà vì B hiểu tại sao hệ thống chậm — không chỉ chỗ nào bị lỗi.
Bẫy lớn nhất: “Code chạy được là xong”
Đây là misconception nguy hiểm nhất, và hầu hết beginner đều tin vào nó.
“Code chạy được” là điểm bắt đầu của vấn đề, không phải điểm kết thúc. Một chương trình chạy đúng hôm nay nhưng không ai hiểu cách nó hoạt động sẽ trở thành gánh nặng khi requirements thay đổi. Và requirements luôn thay đổi.
Tactical programmer — tập trung “làm cho nó chạy”: ship nhanh, tạo complexity, để người khác dọn.
Strategic programmer — tập trung “làm cho nó đúng”: mất thêm thời gian upfront, nhưng codebase vẫn maintainable sau 1 năm.
Debugging data nói rõ: tactical approach mất 13 lần lâu hơn để đạt trạng thái ổn định. Và trong cùng một study với 12 defects, developer tệ nhất tạo thêm 11 bug mới khi cố fix 8 bug ban đầu.
3 thay đổi nhỏ — bắt đầu từ ngày mai
1. Sau khi code chạy — hỏi “tại sao nó chạy?”
Không dừng ở “chạy được rồi”. Tự giải thích cơ chế. Nếu không giải thích được → bạn chưa hiểu.
2. Khi gặp bug — đọc error message trước khi Google.
Dành 5 phút hiểu lỗi đang nói gì. Đây là lúc bạn xây knowledge structure, không phải lúc copy-paste.
3. Mỗi tuần — tự viết lại 1 thứ từ đầu, không nhìn bản gốc.
Feynman Technique ở dạng đơn giản nhất. Nếu không viết lại được → bạn chưa thật sự học được nó.
Kết
Bạn không kém. Bạn chỉ đang dùng công cụ sai.
Tutorial dạy bạn làm gì. Còn để giỏi, bạn cần hiểu tại sao. Hai thứ đó khác nhau hoàn toàn — và chỉ một trong số đó thật sự xây dựng skill.
Ba tháng áp dụng đúng cách sẽ tạo ra khoảng cách lớn hơn bạn nghĩ.
Gửi phản hồi