Có một số mẹo và thủ thuật giúp tối đa hóa tốc độ học tập bền vững của bạn. Các lập trình viên biết những điều này có ích, nhưng chúng ta vẫn cứng đầu bỏ qua chúng mãi.
Nhưng phòng khi bạn muốn học nhanh hơn, đây là một vài điều có tác dụng với một số người. Không đảm bảo gì cả; mỗi người mỗi khác, và bạn có thể có con đường riêng hiệu quả hơn.
Âm nhạc là một trong những điều như vậy. Có người thề rằng sự im lặng hoặc tiếng ồn trắng, hồng, hay nâu mới hiệu quả. Có người nghe nhạc cổ điển, electronica, hay metal. Hãy làm điều gì phù hợp với bạn.
Flow30 là một trạng thái tinh thần mà bạn đạt được khi tập trung cao độ và các ý tưởng kết nối tự do với nhau. Không có gì làm gián đoạn.
Các lập trình viên thích đạt trạng thái flow để tối đa hóa năng suất.
Dưới đây là những đặc điểm của trạng thái đó, lấy thẳng từ Wikipedia:
Có lẽ bạn đã từng trải qua điều này trong một khía cạnh nào đó của cuộc sống. Hãy nhớ rằng nó có thể rất có lợi cho các lập trình viên.
Tôi biết khi còn là sinh viên, nếu có bài gì nộp vào Chủ nhật, tôi thường đọc lần đầu tiên vào đúng Chủ nhật. Ai khác cũng vậy không? Ừ thì vậy.
Nhưng đây là một ý tưởng khác: đọc bài tập ngay khi bạn nhận được nó. Có thể bạn chưa biết đủ để hiểu hết, nhưng không sao. Cứ đọc qua thôi, thậm chí không cần đọc kỹ.
Và một ý tưởng khác: đọc bài tập khi bạn đã làm xong một số phần đọc và nghe giảng khác, nhưng là trước vài ngày so với lúc bạn định bắt đầu làm. Lại cứ đọc qua thôi, không cần lo giải quyết ngay. Có thể đọc ngay và đọc lại giữa tuần!
Điều này giúp kích hoạt não của bạn với thông tin đó. Bạn sẽ không ghi nhớ hết hay hiểu hết, nhưng não sẽ bắt đầu nghiền ngẫm nó ở hậu trường và giúp bạn dễ xử lý bài hơn khi cuối cùng bạn bắt tay vào lúc 9 giờ tối Chủ nhật.
Và khi bạn bắt đầu quy trình giải quyết vấn đề bốn giai đoạn, tài liệu sẽ có vẻ quen thuộc hơn và dễ tiếp cận hơn.
Một biến thể mạnh mẽ của điều này là hoàn thành giai đoạn Hiểu sớm. Chưa cần Lên kế hoạch hay Viết code vội.
Bạn cần giải một bài toán, và nhìn kìa trên mạng! Có giải pháp sẵn rồi! Đến lúc mang kỹ năng CTRL-c/CTRL-v ra dùng!
Trước đây người ta thường tìm thấy giải pháp trên trang lập trình Stack Overflow31. Và vẫn còn dùng. Nhưng ngày nay họ có xu hướng nhờ AI hơn.
Người mới học lập trình không nên làm vậy. Hãy nhớ mục tiêu chính: phát triển kỹ năng giải quyết vấn đề xuất sắc. Copy-paste code không hề giúp ích gì cho mục tiêu này.
Một ngoại lệ cho quy tắc này là nếu bạn đã vật lộn với bài toán một thời gian, như đề cập trong phần Quy tắc 30 phút bên dưới. Nhưng ngay cả khi đó, bạn phải hiểu 100% hoàn toàn đoạn code bạn đang copy trước khi dùng nó.
Nếu bạn đã bí 30 phút và thực sự đã cố tấn công vấn đề từ nhiều hướng khác nhau mà vẫn không ra, đã đến lúc tìm kiếm sự trợ giúp.
Vâng, bạn có thể làm lâu hơn 30 phút mà không cần giúp đỡ (ai cũng làm vậy), nhưng 30 phút là sự cân bằng tốt giữa việc cố gắng chăm chỉ và sử dụng hiệu quả thời gian học tập hạn chế của bạn.
Đây là một câu chuyện. Một trong những cuốn sách yêu thích của tôi để học lập trình có tên là Cấu trúc và Diễn giải Chương trình Máy tính32, hay SICP viết tắt. (Tôi đặc biệt thích phiên bản Scheme — thực sự giúp bạn học đệ quy.)
Các bài toán lập trình trong cuốn sách đó có thể rất thử thách. Nhưng tôi tự đặt giới hạn thời gian sáu giờ cho mỗi bài. (Tôi thường không làm cả sáu giờ liền một lúc.) Sau khi hết giờ, tôi xem đáp án.
Và đây là lý do tại sao điều đó có tác dụng và tại sao nó quan trọng: trong khi bạn nỗ lực với một bài toán, bạn đang bận xây dựng một khung tư duy xung quanh nó, cố gắng hỗ trợ nó. Và nếu bạn tìm được đáp án, tuyệt! Nhưng dù không tìm được, bạn vẫn đã xây dựng được khung tư duy đó.
Vì vậy, khi bạn từ bỏ sau giới hạn thời gian, rất thường xuyên giải pháp bạn đọc khớp gọn vào khung tư duy bạn đã xây. Chỉ là một bước nhỏ từ khung tư duy của bạn đến giải pháp, và việc bước được bước nhỏ đó dễ hơn nhiều so với việc cố grok33 toàn bộ từ đầu.
So sánh với việc bạn chỉ tìm đáp án ngay lập tức mà không xây dựng khung tư duy. Giải pháp không có chỗ để “đặt” trong não bạn, và không kết nối với bất cứ điều gì khác. Và đó là bước dài hơn nhiều để đạt được sự hiểu biết.
Sự vật lộn rất quan trọng! Đừng bỏ qua sự vật lộn! Nhưng đồng thời, đừng kéo dài mãi. Khi hết thời gian, hãy xin giúp đỡ từ bạn học, gia sư, giảng viên, hoặc (nếu được phép) AI.
Ngoài ra, sau đó có thể đi dạo một chút.
Vâng, tôi nói thật. Bạn đang bí, không có gì có vẻ hoạt động, và không có thêm hướng tấn công nào nảy ra trong đầu. Bạn làm gì?
Đi dạo.
Khi bạn thử các cách tiếp cận khác nhau cho một bài toán, nó giống như bạn đang để lại những rãnh mòn trên đường, và não bạn có xu hướng tập trung vào những rãnh hiện có thay vì thử điều gì mới. Bạn bị khóa chặt vào những cách tiếp cận đã thử nhưng không hiệu quả. “Giá mà tôi chỉ có thể tinh chỉnh cái gần đúng này…” nhưng bạn không thấy cách nào.
Đứng dậy và đi bộ. Có thể bạn đang ở nơi làm việc và điều này chỉ có nghĩa là bạn đi vòng quanh hành lang. Hoặc có thể bạn có thể ra ngoài ban công, ra trước cửa, hoặc lên mái nhà.
Điều này giải phóng tâm trí bạn khỏi những rãnh mòn đó và khám phá các cách tiếp cận mới.
Đã có những lần tôi quyết định đi dạo và mới bước ra cửa được hai bước thì một cách tiếp cận mới cho bài toán đã nảy ra trong đầu.
Phương pháp thoát khỏi bế tắc này đã được kiểm chứng và đáng tin.
Hãy nói chuyện với ai đó về vấn đề. Đây là một kỹ thuật hiệu quả đến nỗi nó thậm chí hoạt động khi bạn đang nói chuyện với một con vịt cao su vô tri, từ đó có tên gọi rubber ducking (nói chuyện với vịt cao su).
Ý tưởng cơ bản là bạn sẽ dẫn dắt người kia qua các bước giải quyết vấn đề, thực chất là dạy họ. Giúp họ hiểu vấn đề và nhờ họ giúp lên kế hoạch.
Điều thực sự tuyệt vời về kỹ thuật này là: nó hoạt động ngay cả khi người kia (hoặc con vịt) không có chuyên môn kỹ thuật.
Một trong những lý do là để hiểu một vấn đề và đưa ra kế hoạch, bạn thực sự không cần biết gì về lập trình. Họ vẫn có thể giúp được.
Và đây là điều thực sự tuyệt vời: họ thậm chí không cần nói gì cả. Chỉ hành động dạy ai đó về vấn đề thôi thường đã đủ để bạn tự tìm ra câu trả lời. Có thể là một phần hiểu biết bạn bị bỏ lỡ, hoặc có một lỗ hổng không rõ ràng trong kế hoạch của bạn. Nói chuyện qua có thể giúp bạn tìm ra những điều đó.
Có một lần, kết hợp giữa đi dạo và rubber ducking, một đồng nghiệp của tôi bước đến chỗ tôi làm, giơ tay lên như muốn hỏi, dừng lại một nhịp, rồi nói, “Thôi không cần, tôi tự tìm ra rồi.” Chỉ vậy thôi là đủ.
Khi nghiền ngẫm mô tả bài toán hoặc học một công cụ hay ngôn ngữ, về cơ bản có hai loại câu hỏi nảy sinh.
Câu hỏi chặn tiến độ là những câu hỏi bạn cần được trả lời ngay vì chúng đang chặn tiến độ của bạn. Bạn không thể làm gì khác cho đến khi có câu trả lời.
Câu hỏi không chặn tiến độ là những điều nảy sinh trong quá trình phát triển, thú vị, nhưng bạn có thể tiếp tục mà không cần biết câu trả lời ngay.
Tôi thích ghi lại các câu hỏi không chặn tiến độ và tìm câu trả lời sau. Những thứ như, “Ngôn ngữ này có hỗ trợ destructuring assignments không?” hay “Thư viện có thể cung cấp số ngẫu nhiên trong khoảng số nguyên không?” hay “Những giao thức mạng nào khác được tích hợp sẵn trong thư viện chuẩn?”
Đó là những thứ tôi tò mò, nhưng không cần biết câu trả lời ngay.
Quay lại và tìm câu trả lời sau có thể giúp xây dựng bức tranh đầy đủ hơn về các hệ thống bạn đang làm việc và giúp bạn trở thành lập trình viên hiệu quả hơn.
Đây là nơi mọi thứ hội tụ lại.
Khi bạn mới bắt đầu lập trình, bạn đang đứng giữa thế giới kiến thức bao la chưa được khám phá. Bạn đã học cách in Hello, world! ra màn hình, nhưng đó là tất cả.
Vì vậy bạn bắt đầu lập bản đồ. Bạn thấy có các hàm, biến, thao tác I/O và bạn thấy chúng kết nối với nhau như thế nào. Và bạn học về mạng máy tính, thấy nó kết nối với hệ thống I/O của OS, và bạn nối chúng trên bản đồ.
Khi bản đồ lớn dần, bạn vẽ các kết nối giữa nhiều thứ bạn đã học, và dần dần bạn thấy rằng thế giới phát triển phần mềm kết nối với nhau nhiều hơn là tách rời. Nhiều bài toán rất giống nhau với nhiều bài toán khác.
Và khi bạn biết nhiều bài toán như vậy, đó là rất nhiều sức mạnh bạn có thể mang vào các thử thách mới. “Ồ, bài toán x này nhắc tôi nhớ đến bài toán y. Có thể tôi giải nó theo cách tương tự.”
Bạn có một nhóm 10 người được đánh số từ 0 đến 9 và họ đều đang xếp hàng tại cửa sổ ngân hàng. Mô phỏng của bạn cần họ theo thứ tự ngẫu nhiên không có trùng lặp trong thời gian \(O(n)\). Bạn code thế nào?
Có thể trước đó bạn đã viết chương trình xáo trộn bộ bài sử dụng thuật toán nổi tiếng Fisher-Yates34… đợi đã! Tất cả những gì bạn cần làm là tạo danh sách người được đánh số từ
0đến9theo thứ tự, rồi xáo trộn danh sách như xáo bài!Đây là cùng một bài toán!
Người mới học lập trình giải các bài toán lập trình thuần túy bằng logic và lý luận.
Các lập trình viên có kinh nghiệm cũng dùng logic và lý luận, nhưng họ chủ yếu dựa nhiều vào nhận dạng mẫu. Mẫu code nào tôi biết giải tốt nhất loại bài toán tôi đang gặp?
Tóm lại, họ dựa vào tấm thảm kiến thức liên kết chặt chẽ mà họ đã xây dựng qua nhiều năm lập trình.
Khi học code, hãy tìm cách mà thứ bạn đang học hiện tại kết nối với phần còn lại của thế giới lập trình bạn đã khám phá. Tạo ra những kết nối đó để bạn có thể khai thác chúng sau.
Việc đưa code của bạn ra ngoài và nhờ ai đó tư vấn cách cải thiện có thể rất khó. Dễ bị coi là công kích cá nhân.
Nhưng hãy chống lại cái thôi thúc đó, và coi mỗi code review bạn nhận như một món quà. Có người sẵn lòng bỏ thời gian giúp bạn trở thành lập trình viên tốt hơn, thường là không tốn gì của bạn.
Hãy cư xử tử tế trong code review dù bạn là người được review hay người review. Hãy hỗ trợ trong phản hồi của mình, khiêm tốn, và đừng coi phản hồi tiêu cực là chuyện cá nhân.
Và nếu không tìm được người để giúp, hãy đưa code vào AI chatbot và nhờ nó review.
Ngay cả khi bạn không thành thạo về chủ đề đó, điều đó không nên ngăn bạn thực hiện code review khi có thể. Chỉ đọc code của người khác thôi cũng giúp bạn tiếp xúc với các phong cách code và mẫu thuật toán khác nhau mà bạn có thể chưa biết đến.
Nhưng hãy nhớ luôn có chính kiến về phản hồi bạn nhận được, và dùng sự phán xét phê phán khi quyết định có áp dụng hay không.
Lập trình về mặt lịch sử và nhìn chung là hoạt động cá nhân — ít nhất là phần bạn ngồi gõ phím. Và ngay cả trong các giai đoạn Hiểu và Lên kế hoạch cũng có thể hấp dẫn khi làm việc một mình.
Tham gia một nhóm người có cùng chí hướng nơi bạn có thể trao đổi ý tưởng (hoặc chỉ xả hơi) có thể thực sự giúp não bạn thoát khỏi những rãnh mòn và giúp bạn tiếp cận bài toán theo những cách bạn chưa nghĩ đến hoặc thậm chí chưa biết đến.
Nó cũng tốt cho networking, và nhiều câu lạc bộ có những buổi thuyết trình thú vị bạn có thể tham dự. Hay thậm chí tốt hơn, hãy thuyết trình tại đó!
Câu lạc bộ có thể làm cho cuộc chiến cảm giác ít cô đơn hơn nhiều. Chúng ta đều cùng chung hành trình này.
Bạn (cá nhân) làm gì để đạt trạng thái flow?
Những lợi thế của việc đọc bài tập sớm hơn rất nhiều so với lúc bạn định làm là gì?
Những bất lợi của việc làm một bài toán quá ít thời gian trước khi nhờ giúp đỡ là gì?
Những bất lợi của việc làm một bài toán quá lâu trước khi nhờ giúp đỡ là gì?
Khi nào thì copy-paste code được chấp nhận? Điều gì xảy ra nếu bạn dùng nó không đúng cách?
Tại sao đi dạo là ý tưởng hay khi bị bế tắc?
Một con vịt cao su vô tri có thể là người bạn đồng hành lập trình tốt như thế nào?
Tác giả muốn nói gì về tấm thảm kiến thức và nó liên quan đến kỹ năng của bạn với tư cách là lập trình viên như thế nào?
Bạn thu được gì khi nhận code review? Bạn thu được gì khi cho code review?