Lập trình là rất khó. Những người nói khác đều là những người có nhiều năm kinh nghiệm lập trình trong hồ sơ của họ. Nếu bạn bị choáng ngợp trong quá trình học cũng là chuyện bình thường! Có rất nhiều thứ phải học và có thể bạn sẽ quên đi những thứ đó rất nhanh sau khi bạn học chúng. Tin tôi đi: đó là chuyện bình thường.
Nhưng chỉ vì nó là bình thường không có nghĩa rằng nó không gây bực bội và nản lòng. Sự thật mà nói, học lập trình có thể cực kỳ căng thẳng nếu bạn không tiếp cận nó với những suy nghĩ và thái độ đúng đắn.
Bạn muốn học một ngôn ngữ, thư viện hoặc framework mới càng sớm càng tốt, phải không nào? Đó là điều dễ hiểu. May mắn thay, có một số bí quyết có thể giúp bạn ghi nhớ kiến thức tốt hơn, nếu không thì tất cả thông tin về lập trình sẽ đi vào tai này và ra ở tai kia của bạn.
Đừng học nhồi nhét thật nhiều kiến thức vào một lúc
Không ai muốn nghe điều đó, nhưng nhồi nhét là cách tồi tệ nhất để học lập trình. Nếu bạn có điểm gì đó giống tôi, nhồi nhét là cách làm việc của bạn suốt quãng thời gian học sinh lẫn thời sinh viên đại học. Đó là cách duy nhất bạn biết làm thế nào để học.
Nhưng bài học từ những sai lầm của tôi đó là: bạn càng cố nhồi nhét, thì bạn càng nhớ được ít đi. Đó là điều đúng cho bất kỳ chủ đề học vấn nào, nhưng nó đặc biệt đúng khi nói đến lập trình.
Cơ sở của nhận định này xuất phát từ một nghiên cứu vào năm 2008 của Đại học California, San Diego:
Sinh viên sẽ có kết quả tốt hơn khi họ chia buổi học của mình thành nhiều phiên hơn là khi họ cố gắng nhồi nhét mọi thứ vào bộ não của mình vào cùng một lúc.
Tại sao ư? Nhiều khả năng là do hiệu ứng vị trí nối tiếp (serial position effect):
Hiệu ứng vị trí nối tiếp (serial position effect) là xu hướng một người sẽ nhớ thành phần đầu tiên và cuối cùng trong một chuỗi tốt nhất, và các thành phần ở giữa là tồi nhất.
Nói cách khác: trong bất kỳ buổi học nào đó, bạn có nhiều khả năng nhớ rõ các thông tin mà bạn đã học được ở phần đầu và kết thúc buổi học và nhiều khả năng sẽ quên các thông tin ở giữa buổi.
Bạn muốn tối đa hóa số lượng của những giai đoạn bắt đầu và kết thúc. Đó là lý do tại sao sẽ là tốt hơn khi bạn chia nhỏ buổi học thành nhiều phiên ngắn, nó sẽ giúp cho bạn ghi nhớ và tiếp thu kiến thức mới được tốt hơn.
Lần tới khi bạn ngồi xuống để học lập trình, hãy chỉ học một chủ đề vào một thời điểm và có một vài phút nghỉ ngơi ngắn giữa mỗi chủ đề. (Chỉ cần chắc chắn khoảng thời gian nghỉ ngơi đó không làm bạn rơi vào trạng thái trì hoãn!)
Xem lại, xem lại, xem lại
Một lý do khác, học nhồi nhét không thể giúp bạn ghi nhớ được kiến thức lâu dài là bởi vì ký ức thường bị mờ nhạt theo thời gian. Điều này không phải lúc nào cũng đúng – tôi chắc là tất cả chúng ta đều có một vài kỷ niệm tuổi thơ còn nhớ mãi – nhưng nó có vẻ là trường hợp tổng quát cho những kỷ niệm mà không gắn với cảm xúc nào đó.
Có một số cuộc tranh luận về việc liệu trí nhớ có tự phân rã theo thời gian (lý thuyết decay) hoặc đơn giản là bị đẩy ra ngoài và thay thế bằng những ký ức mới theo thời gian (lý thuyết nhiễu). Cho dù bạn ủng hộ lý thuyết nào đi nữa, thì kết quả là những ký ức cũ có nhiều khả năng sẽ bị biến mất theo thời gian.
Đây chính là nơi mà việc xem lại (review) đóng vai trò quan trọng.
Hãy suy nghĩ về nó giống như bạn đang đi qua một khu rừng của ký ức. Mỗi khi bạn muốn truy cập vào một ký ức, bạn phải vạch ra một con đường trong trí não để tìm ra nó. Mỗi lần bạn lục lọi trong trí nhớ như vậy, thì con đường sẽ được hằn sâu hơn một chút – giống như cách một lối mòn hình thành khi người ta cứ đi lại mỗi ngày. Nếu bạn không còn đi trên con đường đó, nó có thể phai nhạt đi và ký ức đó bị thất lạc ở đâu đó trong khu rừng tri thức.
Gạt sang một bên tất cả các hiệu ứng về tâm lý, thông tin quan trọng nhất cần nhớ là: khi nói đến lập trình, sẽ là không đủ nếu bạn học một chủ đề chỉ một lần hoặc hai lần. Bạn phải xem lại nó hàng chục hoặc thậm chí hàng trăm lần. Mỗi lần xem lại như vậy sẽ làm khắc sâu chủ đề đó vào bộ não của bạn thêm một chút.
Tôi biết điều này khó có thể thực hiện được nếu bạn là một người có thói quen học nhồi nhét, nhưng bạn sẽ ngạc nhiên vì bạn sẽ bắt đầu lưu giữ được kiến thức lâu hơn thông qua những nỗ lực xem lại nó đều đặn.
Sử dụng nhiều nguồn tài nguyên khác nhau
Khía cạnh khó khăn nhất của lập trình – ít nhất là cho những lập trình viên mới vào nghề – đó là các chi tiết và sắc thái cần phải tiếp thu. Cho đến khi kiến thức được tiếp nhận, thì bạn sẽ rơi vào trạng thái vò đầu bứt tóc rất nhiều.
Tùy thuộc vào ngôn ngữ, bạn sẽ cần phải nhớ hàng trăm quy tắc cú pháp (ví dụ từ khóa, dấu chấm phẩy, khoảng trắng). Một số ngôn ngữ rất nghiêm ngặt, những ngôn ngữ khác ít hơn, còn có những ngôn ngữ có cách tiếp cận độc đáo của riêng nó mà cú pháp đó không sử dụng được ở bất cứ nơi nào khác. Tất cả điều này có thể gây nhầm lẫn nếu bạn chưa có kinh nghiệm lập trình trước đó.
Đó là chưa đề cập đến tất cả các thông tin về khái niệm vượt quá các ngôn ngữ riêng rẽ. Các chủ đề như lập trình hướng đối tượng, các hệ thống entity-component, và observer patterns thực sự có thể làm cho đầu của bạn quay mòng mòng khi lần đầu tiên bạn cố gắng học về chúng.
Tôi đã chia sẻ hình ảnh minh họa này trước đây, nhưng nó rất đáng để nhắc lại một lần nữa ở đây:
Giả sử một người nào đó đưa cho bạn một tấm hình của một bức tượng. Nó có thể cung cấp đủ các hình ảnh cho bạn để có được một ý nghĩa đầy đủ của bức tượng đó, nhưng bạn sẽ không nhận được toàn bộ hình ảnh. Nếu thu nhỏ tấm hình đó sẽ làm mất các chi tiết phức tạp, còn nếu phóng to tấm hình thì sẽ làm mất cái nhìn toàn cảnh về bức tượng đó.
Tuy nhiên, với mỗi bức ảnh bổ sung, bạn có thể thực sự bắt đầu nhìn thấy đầy đủ hình ảnh về bức tượng đó trong cả kết cấu, kích thước, chi tiết, từ trước ra sau, từ bên này sang bên kia, và từ trên xuống dưới.
Học lập trình có thể có những tùy ý đáng ngạc nhiên. Mọi người có thể đều ca ngợi tài liệu A như là cách tốt nhất để học ngôn ngữ X, nhưng có thể nó lại không có ý nghĩa đối với bạn. Có thể mọi người ghét tài liệu B nhưng khi bạn tham khảo nó thì thấy rất tuyệt vời! Đối với một số người khác, có thể họ không thu được gì nhiều khi nghiên cứu tài liệu A và B nhưng hưởng lợi rất nhiều từ nguồn tài liệu C.
Đó là lý do tại sao điều quan trọng là bạn có thể sẵn sàng học từ tất cả các loại nguồn tài nguyên hiện có. Mọi người đều học theo một cách khác nhau. Nếu bạn đang gặp rắc rối với một chủ đề cụ thể, hãy tìm kiếm thêm những nguồn tài nguyên khác. Có thể sẽ có một tài nguyên nào đó phù hợp với bạn. Có thể không.
Ngay cả khi bạn nghĩ rằng mình đã hiểu về các chủ đề nhất định nào đó, nhưng có thể là có nhiều thứ hơn để tìm hiểu thêm về nó. Nó cũng có thể là lời giải thích của người khác sẽ giúp củng cố thêm các khái niệm trong tâm trí của bạn trở nên tốt hơn. Bạn chẳng bao giờ biết được, vậy tại sao không sử dụng nhiều tài nguyên nhất bạn có thể?
Dạy lại những khái niệm sau khi bạn tìm hiểu chúng
Có một khái niệm đẹp trong lập trình được gọi là rubber duck debugging, đó là mô tả kỹ thuật giải thích từng dòng code một cho một con vịt cao su vô tri vô giác. Nó được sử dụng khi một đoạn code cụ thể bị hỏng, nhưng không có lý do rõ ràng cho nó.
Lạ lùng thay, hầu hết các lập trình viên đều có một khoảnh khắc thốt lên “Eureka! (tìm ra rồi)” ở khoảng giữa trong quá trình giải thích code đó, vì bất ngờ họ nhìn thấy nơi xảy ra lỗi logic lập trình. Chính việc giải thích đó kích thích lên môt khu vực khác của não bộ, buộc bạn nhìn vấn đề đó từ một góc độ mới.
Khái niệm này cũng có thể được sử dụng để giúp bạn học kiến thức mới. Bạn có thể đã đọc qua trích dẫn nổi tiếng sau đây, người ta cho rằng đó là của nhà bác học Albert Einstein:
Nếu bạn không thể giải thích vấn đề một cách đơn giản, thì nghĩa là bạn chưa thực sự hiểu rõ về nó.
Ngoại trừ một số lĩnh vực chủ yếu làm việc với kiến thức lý thuyết cao cấp, thì câu nói này là đúng. Bạn càng hiểu rõ một chủ đề, thì bạn càng được trang bị tốt hơn để giải thích nó theo cách sao cho một người không có kiến thức về chủ đề đó vẫn có thể hiểu được.
Điều ngược lại cũng đúng. Khi bạn cố gắng để dạy về một chủ đề, bạn sẽ đi qua một số khái niệm mà bạn dường như không thể giải thích một cách rõ ràng. Đây không chỉ là một cách tuyệt vời để chẩn đoán những điểm yếu trong kiến thức của bạn, quá trình thực tế của việc tìm kiếm lời giải thích hợp có thể giúp củng cố các khái niệm trong tâm trí của bạn.
Nó được gọi là học tập bằng cách giảng dạy và về cơ bản là một biến thể của kỹ thuật rubber duck debugging nói trên.
Lúc này, tôi không nói rằng bạn thực sự cần phải dạy cho người khác; thay vào đó, mỗi chủ đề lập trình mới mà bạn nghiên cứu, hãy cố gắng dạy nó cho một con vịt cao su (hoặc một người bạn vô hình). Lúc đầu thì việc này có thể cảm thấy hơi ngớ ngẩn, nhưng bạn sẽ nhận ra rằng nó vô cùng hiệu quả để ghi nhớ kiến thức.
Thực hành có chủ đích tạo ra sự hoàn hảo
Quan điểm về tài năng hiện nay hoàn toàn là sai lầm. Không ai vừa ra khỏi bụng mẹ đã trở thành một nghệ sĩ đàn dương cầm, đô vật, hoặc lập trình viên đẳng cấp thế giới cả. Chắc chắn, một số người có thể nghiêng nhiều hơn về một lĩnh vực nhất định, nhưng tài năng nếu không có kinh nghiệm là vô nghĩa. Tương tự như vậy, làm việc chăm chỉ luôn luôn có giá trị hơn tài năng.
Điều đáng nói là, không phải tất cả các hình thức của làm việc chăm chỉ đều giống nhau. Malcolm Gladwell đã nêu ra quy luật 10.000 Giờ rất nổi tiếng, trong đó nói rằng bạn phải đầu tư ít nhất 10.000 giờ vào một chủ đề để trở thành một bậc thầy trong lĩnh vực đó. Trong khi quy tắc này là đúng, nhưng nhiều người hiểu sai những gì ông muốn nói.
Thực ra, việc cam kết thực hành 10.000 giờ không thực sự đảm bảo bạn sẽ trở nên tinh thông. Chắc hẳn bạn đã biết câu nói: “Thực hành không tạo ra sự hoàn hảo. Thực hành hoàn hảo làm cho nó hoàn hảo.” Nói một cách dễ hiểu hơn thì thực hành phải có chủ đích. Sự tinh thông chỉ có thể đạt được thông qua 10.000 giờ luyện tập có chủ đích.
Cách bạn thực hành như thế nào quan trọng hơn nhiều so với lượng thời gian bạn dành cho việc thực hành.
Đọc sách là thụ động. Xem các video hướng dẫn trên YouTube cũng là thụ động. Lắng nghe các podcast cũng là thụ động. Là một lập trình viên newbie thì bạn có thể bị cám dỗ để nhảy hết từ hướng dẫn này sang hướng dẫn khác, ngâm cứu hết chủ đề này sang chủ đề khác nhưng không thực sự áp dụng bất kỳ những kiến thức đó một cách thiết thực. Hãy cưỡng lại sự cám dỗ này.
Nếu bạn muốn tăng tốc độ quá trình học tập của mình, thì bạn phải sẵn sàng học tập ở thế chủ động thay vì thụ động. Thực hành tích cực sẽ quyết định đến kết quả cuối cùng.
Thử nghiệm với các dự án cá nhân
Đối với tôi, bài tập về nhà là phần dở nhất của mô hình trường học. Nó có vẻ giống như một mánh khóe tinh vi để nhằm giết niềm vui và khiến cho sinh viên luôn bận rộn – nhưng công bằng mà nói, đôi khi nó cũng có giá trị. Nhưng giờ đây khi tôi nhìn lại, tầm quan trọng của bài tập về nhà cuối cùng cũng có một ý nghĩa gì đó. Nó buộc tôi phải áp dụng kiến thức mới một cách chủ động.
Nếu bạn đang theo học một lớp lập trình, đừng đánh giá thấp hiệu quả của bài tập về nhà. Hãy nghiêm túc, luôn luôn xem nó như một cơ hội để củng cố thêm những gì bạn đã học được vào trí nhớ của bạn về lâu về dài.
Nhưng nhiều khi, làm bài tập về nhà vẫn là chưa đủ. (Và nếu bạn đang tự học lập trình mà không có một người hướng dẫn thực sự, thì có thể bạn sẽ chẳng có bài tập về nhà nào để bắt đầu với nó cả.)
Vậy giải pháp ở đây là gì? Hãy tạo ra cho mình một vài dự án cá nhân!
Hãy nghĩ về một vài ý tưởng dự án mà bạn muốn thực hiện. Đối với người mới học lập trình, bạn có thể tạo ra một trò chơi kiểu Tic-Tac-Toe hoặc Hangman. Đối với các lập trình viên dày dạn thì cố gắng tìm hiểu một framework mới, hay thử lập trình một ứng dụng web hoặc trò game mobile đơn giản. Miễn là nó tạo ra hứng thú cho bạn, hãy thực hiện nó!
Với phương pháp này bạn sẽ thu được 2 lợi ích rất lớn.
Đầu tiên, nó sẽ giúp duy trì sự tập trung của bạn. Các nghiên cứu đã chỉ ra rằng sinh viên sẽ học tốt hơn khi họ có thể theo đuổi các chủ đề mà họ quan tâm. Đó là chính xác những gì một dự án cá nhân mang lại. Bạn có một mục tiêu cuối cùng mà bạn thực sự muốn đạt được, do đó bạn có nhiều khả năng để lưu giữ lại những thông tin và kiến thức đó.
Thứ hai, bạn không có áp lực bắt buộc phải thành công. Trong khi thành công thì rất tốt, nhưng nếu không xem trọng điều đó cho phép bạn được thử nghiệm và sáng tạo. Chắc chắn bạn sẽ gặp phải những vấn đề, nhưng nó giống như là bạn đang chơi trò xếp hình Lego hơn là bài tập về nhà. Nó mang lại nhiều niềm vui và không có sự căng thẳng.
Thư giãn & bookmark tất cả mọi thứ
Sự thật là không có lập trình viên nào nhớ được tất cả mọi thứ mà họ đã học được. Ngay cả sau khi bạn đã làm việc với một thư viện hoặc framework cụ thể trong một thời gian, thì cũng không phải là hiếm nếu bạn không thể nhớ hết các chức năng của nó trong tâm trí của mình.
Trong thực tế, việc cố gắng ghi nhớ tất cả mọi thứ chỉ sẽ chỉ tốn thời gian và công sức của bạn mà thôi. Các tài liệu tham khảo tồn tại là cũng bởi lý do này. Tại sao lại phải nhồi nhét toàn bộ kiến thức bách khoa toàn thư vào bộ nhớ khi bạn có thể lật mở nó ra bất cứ khi nào bạn cần nó? Điều này cũng đúng cho các thư viện lập trình ứng dụng API.
Vậy thì khi nào nên ghi nhớ và khi nào nên tham khảo?
Đối với các khái niệm thì bạn nên ghi nhớ về chúng.
Đối với tất cả những thứ khác – chẳng hạn như tên gọi cụ thể các function, danh sách tham số, v.v… – tôi sẽ không lo lắng để nhớ về chúng. Hãy lưu giữ chúng trong các tài liệu tham khảo. Đôi khi bạn sẽ tham khảo một cái gì đó vào lúc bạn đã quên về nó. Nếu điều đó xảy ra, cũng không sao cả. Nếu không, điều đó là rất tốt.
Cá nhân tôi có hàng trăm các bookmark lưu các API, hướng dẫn, và tutorial khác nhau. Nếu tôi cần phải thực hiện một số loại thuật toán tìm đường, tôi có thể tham khảo một hướng dẫn để giúp mình có được phần code đó trước khi tôi lại quên về nó một lần nữa. Nó giúp hiểu các khái niệm cơ bản, nhưng tôi cố gắng không phải băn khoăn về các chi tiết thực hiện.
Kết luận
Tôi sẽ lặp đi lặp lại một triệu lần rằng: lập trình là rất khó và sẽ là chuyện bình thường nếu bạn phải vật lộn với nó. Tôi đã lập trình như là một sở thích trong hơn một thập kỷ và tôi vẫn thấy mình cảm thấy khá khó khăn khi cần phải học thêm những khái niệm mới.
Đừng dằn vặt chính mình lên nếu bạn không thể nhớ tất cả mọi thứ ngay lập tức. Các lời khuyên trên đây hy vọng sẽ có ích cho bạn, và thậm chí nếu không thì bạn luôn luôn có thể dựa vào các tài liệu tham khảo đã được bookmark như một phương sách cuối cùng.
Techtalk via Vinacode
