Game dạy mình code tốt hơn bất kỳ khóa học nào

Mình biết nghe có vẻ kỳ lạ, nhưng thật ra một phần lớn tư duy engineering của mình được hình thành không phải từ sách giáo khoa hay tutorial trên YouTube, mà từ những buổi tối ngồi cày game đến 2-3 giờ sáng hồi còn sinh viên.

Không phải mình đang cố justify thói quen lười biếng đâu nhé. Mình thực sự nhận ra có một sự tương đồng rất sâu giữa cách game được thiết kế để dạy người chơi và cách chúng ta nên tiếp cận việc học kỹ thuật.

Fail fast, fail often game làm điều này tốt hơn bất kỳ bootcamp nào

Nhớ lại hồi chơi Dark Souls không? Hay thậm chí mấy cái platformer đơn giản hồi xưa. Bạn chết. Bạn respawn. Bạn thử lại. Không ai ngồi giải thích cho bạn tại sao bạn chết, bạn tự figure out từ feedback trực tiếp của game.

Theo kinh nghiệm của mình, đây chính xác là cách học code hiệu quả nhất. Đừng đọc docs 3 tiếng đồng hồ trước khi viết một dòng code. Cứ viết, cứ break, cứ đọc error message, rồi fix. Cái loop đó write → break → understand → fix nó gần như giống hệt gameplay loop của một game hay.

Vấn đề là môi trường làm việc thực tế đôi khi không cho phép mình "chết" thoải mái như vậy. Mình sợ merge PR mà chưa chắc chắn 100%, sợ deploy feature mới lên production. Nhưng game đã dạy mình rằng cái sợ đó chính là barrier ngăn mình tiến bộ.

Solution? Local environment, staging server, feature flag đây chính là "save point" trong thế giới thực. Bạn có thể fail thoải mái mà không ảnh hưởng đến production.

Onboarding experience và tại sao documentation của bạn đang làm người đọc nản lòng

Game AAA hiện đại đầu tư cực kỳ nhiều vào tutorial. Không phải cái tutorial kiểu "nhấn W để đi về phía trước" nhàm chán, mà là contextual learning bạn học mechanic mới đúng lúc bạn cần dùng nó.

Mình thấy cái này hay ở chỗ: game không dump toàn bộ manual vào mặt bạn ở màn hình đầu tiên. Nó introduce từng concept một, theo đúng thứ tự bạn cần biết, trong đúng context bạn đang gặp phải.

Nhìn lại README của project mình đang làm... yeah, mình guilty. Đống docs dài 500 dòng với đủ thứ từ architecture overview đến từng environment variable không có thứ tự ưu tiên, không có "bạn đang ở đây", không có progressive disclosure.

Một số nguyên tắc từ game design mình đã bắt đầu áp dụng vào viết docs:

Nếu bạn đang maintain một open source project hay internal tool, thử nhìn nó qua lăng kính của một game designer xem. Người dùng mới của bạn có đang bị overwhelmed không? Họ có biết "bước tiếp theo" là gì không?

Grind và flow state hai thứ tưởng mâu thuẫn nhưng lại cần nhau

Ai chơi RPG cũng biết cái cảm giác grind làm đi làm lại một việc để level up, farm resource. Nghe membosankan, nhưng khi được design tốt, nó lại tạo ra flow state cực kỳ productive.

Trong coding cũng vậy. Có những task mình gọi là "grind tốt": refactor một module cũ, viết test coverage, clean up technical debt. Đơn điệu, không glamorous, nhưng sau khi xong bạn cảm thấy character của mình đã lên level thật sự.

Vấn đề là phân biệt grind có ý nghĩa và busywork vô nghĩa. Trong game, bạn grind vì có mục tiêu rõ ràng con boss cuối cần level 50, bạn đang level 43. Trong công việc, nếu bạn đang làm một việc lặp đi lặp lại mà không biết nó dẫn đến đâu, đó là dấu hiệu cần dừng lại và hỏi.

Mình có một rule: nếu mình làm cùng một việc thủ công hơn 3 lần, lần thứ 4 mình sẽ automate nó. Đây không phải từ sách engineering, mà từ cái cảm giác chán ngắt khi grind quá lâu trong game và tự hỏi "tại sao không có cách nào nhanh hơn không?"

Side quest và tầm quan trọng của việc đi lạc có chủ đích

Mình để ý một pattern khá thú vị: những lần mình học được nhiều nhất không phải khi follow một tutorial có cấu trúc, mà khi mình đang cố fix một bug kỳ lạ và bị kéo vào rabbit hole.

Bắt đầu debug một memory leak trong Node.js, cuối cùng hiểu sâu hơn về event loop. Đang config Nginx, tình cờ học được về reverse proxy và load balancing. Cái "side quest" đó không nằm trong sprint plan, không có trong roadmap, nhưng lại là những thứ stick trong đầu lâu nhất.

Game open world dạy mình rằng đôi khi cứ đi theo hướng mình tò mò, không nhất thiết phải theo main quest. Dĩ nhiên trong môi trường công ty có deadline, bạn không thể 100% tự do như vậy. Nhưng dành 20% thời gian để explore đọc source code của một library bạn đang dùng, thử một approach khác dù cái cũ đang work đó là investment vào growth dài hạn.

Anh em lưu ý: cái này khác với procrastination nhé. Side quest có chủ đích là bạn biết mình đang explore cái gì và tại sao. Procrastination là bạn scroll Twitter vì sợ đối mặt với task khó.

Khi nào nên đọc walkthrough và khi nào thì đừng

Có một cuộc tranh luận muôn thuở trong gaming community: có nên đọc guide/walkthrough không? Một bên nói không, phải tự khám phá. Bên kia nói life is short, cứ google đi.

Trong dev, mình nghĩ câu trả lời phụ thuộc vào bạn đang cố đạt được gì:

• Muốn hiểu sâu? Tự vật lộn trước, chỉ tìm kiếm khi thực sự stuck. Cái hiểu sau khi tự tìm ra sẽ khác hoàn toàn với cái copy-paste từ Stack Overflow.
• Đang trong deadline? Copy-paste đi, nhưng bookmark lại để đọc hiểu sau. Đừng để technical debt về mặt kiến thức tích lũy quá nhiều.
• Đây là domain hoàn toàn mới? Đọc overview trước để có mental model, rồi mới dive in. Không ai chơi một game RPG phức tạp mà không đọc qua mechanic cơ bản.

Mình thấy nhiều junior dev rơi vào một trong hai extreme: hoặc tự mình vật lộn quá lâu với thứ có thể giải quyết trong 5 phút bằng cách hỏi, hoặc copy-paste mà không hiểu gì cả. Game thực ra dạy bạn cân bằng điều này khá tốt bạn tự explore, nhưng khi bị stuck quá lâu bạn sẽ tự nhiên tìm kiếm hint.

Cái mà game làm được mà hầu hết công ty tech không làm được

Game tốt luôn cho bạn biết bạn đang tiến bộ. Experience bar, achievement, skill tree unlock tất cả đều là visual feedback về growth của bạn.

Trong môi trường dev, cái này thường rất mờ nhạt. Bạn có đang giỏi hơn không? Khó nói. Review cycle 6 tháng một lần không đủ granular. Mình đã thử áp dụng một số cơ chế tương tự:

• Giữ một "learning log" ghi lại mỗi ngày mình học được gì, dù nhỏ
• Track số lượng PR review mình comment có ích (không phải chỉ số lượng)
• Định kỳ quay lại code mình viết 6 tháng trước và đánh giá xem nó tệ như thế nào nếu bạn thấy nó tệ, nghĩa là bạn đã tiến bộ

Cái cuối cùng đó mình học từ game: khi bạn quay lại early game area sau khi đã level up cao, bạn nhận ra mình đã mạnh hơn bao nhiêu. Với code cũng vậy đừng xấu hổ về code cũ, hãy dùng nó như một benchmark để thấy mình đã đi được bao xa.

Nói cho cùng, cả gaming lẫn engineering đều là về việc giải quyết vấn đề trong một hệ thống có rules và constraints. Bộ não bạn không phân biệt được nhiều đâu. Cái mindset bạn mang vào game kiên nhẫn, tò mò, sẵn sàng fail và thử lại đó chính xác là mindset bạn cần khi debug một production issue lúc 11 giờ đêm.