12/08/2018, 15:31

Học cách học: kỹ năng quan trọng nhất của lập trình viên

Bài viết được dịch từ bài Learning How to Learn: The Most Important Developer Skill của tác giả Preethi Kasireddy Là một người học có hiệu quả quan trọng tương đương với việc là một coder hiệu quả. Khi bạn là một lập trình viên, công việc yêu cầu bạn học hỏi mỗi ngày - dù cho có sự cám dỗ liên ...

Bài viết được dịch từ bài Learning How to Learn: The Most Important Developer Skill của tác giả Preethi Kasireddy

Là một người học có hiệu quả quan trọng tương đương với việc là một coder hiệu quả.

Khi bạn là một lập trình viên, công việc yêu cầu bạn học hỏi mỗi ngày - dù cho có sự cám dỗ liên tục từ các trang Hacker News, Twitter, Reddit và Facebook.

Bạn luôn gặp những code base và thách thức kỹ thuật mới trong công việc. Ở nhà cũng không khá hơn, khi bạn xử lý các repo nguồn mở và các dự án cá nhân, mỗi thứ đều có các quy trình và thách thức cần giải quyết.

Thế giới công nghệ thay đổi nhanh chóng, và có thể cảm nhận rằng một công việc toàn thời gian chỉ là bắt kịp với các công cụ, ngôn ngữ, framework mới nhất.

Nói tóm lại: việc học rất khó khăn. Tuy nhiên chúng ta cần phải học nhanh và hiệu quả để phát triển.

Trong năm trước, tôi từ việc không biết cách dùng trình gỡ lỗi của Chrome đã trở thành một kỹ sư phần mềm củ một công ty cryptocurrency hàng đầu. Trong quá trình đó, tôi đã nhanh chóng học một kỹ năng mới (viết code).

Phải nói là, việc học đó không dễ dàng đối với tôi.

Thành thật mà mói, mọi khái niệm mới đều rất khó nắm bắt. Có quá nhiều thứ không biết và quá nhiều thứ không chắc chắn.

"Làm thế nào mà thế giới này bền vững được nhỉ?", tôi tự hỏi.

"Nếu việc học code đều cho cảm giác như thế này mỗi ngày, tôi sẽ rất khổ sở. Liệu đây có thật sự là niềm đam mê của tôi?"

"Liệu việc này có trở nên dễ dàng nếu nó là niềm đam mê của tôi? Liệu các nghệ sỹ có đấu tranh để tạo ra các tác phẩm? Liệu các nhà văn có đấu tranh để viết nên những cuốn sách tuyệt vời? Liệu các vận động viên có đấu tranh để có thể thi đấu tốt? Và liệu chúng ta có phải đấu tranh khi theo đuổi đam mê của mình?"

"Tôi có nên tìm niềm vui trong việc này hay không?"

Có chứ. Một năm trước, việc nắm bắt những khái niệm lập trình mới đối với tôi vẫn rất khó khăn theo nghĩa nó cần kỷ luật và chăm chỉ.

Nhưng nó cũng trở thành một quá trình thú vị, hơn là một quá trình áp lực.

Chuyện gì đã xảy ra năm trước mà khiến cho tôi có thể thay đổi?

Đơn giản là: tôi thay đổi quan điểm của mình về việc học. Điều tôi từng nghĩ là "khó khăn" đã trở nên "hấp dẫn".

Trong phần còn lại của bài viết, tôi sẽ giải thích cách mà việc thay đổi này đã diễn ra.

Việc học code khó khăn nhất ở giai đoạn đầu.

Ví dụ, hãy nghĩ về ngôn ngữ lập trình đầu tiên mà bạn học. Bạn muốn học những thứ nhỏ như cú pháp và phong cách viết. Nhưng trước hết, bạn phải hiểu các khái niệm cốt lõi khó nhằn trước như giá trị, kiểu, toán tử, luồng điều khiển, hàm, độ ưu tiên của hàm, scope, closure, đệ quy và rất nhiều thứ khác nữa.

Cảm giác giống như học tung hứng, nhưng bắt đầu với mười tám quả bóng thay vì hai.

Khi lần đầu tiên tôi học về closure, tôi mất nhiều tuần để có thể thực sự hiểu khái niệm đó. Tôi đã nghĩ là tôi hiểu nó khi tôi đọc về nó. Nhưng khi tôi cố xác định và sử dụng closure trong thực tế, tôi cảm thấy bối rối.

Điều đó không hề bất thường. Tôi đã từng chứng kiến quá trình này như một giáo viên: các khái niệm mới thường không rõ ràng khi dùng lần đầu tiên. Hay lần thứ hai. Hay thậm chí là lần thứ mười.

Nhưng đối với những người đồng hành cùng nó đủ lâu, sẽ có một "điểm nhấn" mà ở đó mọi thứ đột nhiên trở nên có ý nghĩa. Trong ví dụ của tôi, tôi đọc, theo nghĩa đen, mọi bài blog, bài viết trên Stack Overflow và đặc tả trên mạng về closure.

Mọi thứ tôi đọc và trải nghiệm đã cho tôi một góc nhìn mới, đến cuối cùng, tôi đã có một bức tranh toàn cảnh về cách closure hoạt động. Closure "đã rõ ràng".

Đến được thời điểm mà tôi cảm thấy cảm giác hiểu closure là cực kỳ quan trọng, vì nó đền đáp và khuyến khích tôi tiếp tục - bao gồm cả việc viết bài blog của mình nhằm giải thích khái niệm closure.

Nếu chúng ta coi việc học là thứ gì đó chúng ta "phải" làm, chúng ta sẽ vội vã làm cho xong để có thể dành phần thời gian còn lại để làm những thứ "vui" hơn - thứ gì đó chúng ta "muốn" làm.

Vấn đề là chúng ta không thể biết tất cả mọi thứ của bất cứ thứ gì, nên coi việc học như là một cuộc đua sẽ dấn tới kiệt sức và thất vọng.

Thay vào đó, nếu bạn coi việc học như một quá trình, bạn sẽ đánh giá cao những thành tựu và hiểu biết nho nhỏ trong quá trình này. Điều này sẽ khiến bạn tiếp tục tiến bước.

Bạn có thể so sánh việc này với việc tập thể dục. Tập luyện gây ra đau đớn, và cơn đau kết thúc khi việc tập luyện của bạn kết thúc. Nhưng nó sẽ không biến mất. Nó sẽ chờ đến lần tiếp theo bạn tập luyện. Ngoại trừ việc cơn đau sẽ trở nên ít thấm hơn. Bạn đã học cách đối phó với nó. Bạn trở nên quen với cơn đau, và nó trở thành một thứ thường nhật. Bạn được thưởng với sức khỏe và vóc dáng tốt hơn và được khuyến khích tiếp tục.

Việc tập thể dục tạo ra một vòng lặp phản hồi tích cực

Điều tương tự cũng đúng với việc học tập.

Tưởng tượng rằng bạn đang xây dựng một ứng dụng web đầu tiên của mình.

Trước hết, tất cả những gì bạn có là một chương trình soạn thảo trống rỗng. Nhiệm vụ xây dựng ứng dụng có vẻ không thực hiện nổi. Bạn không biết gì và có quá nhiều thứ cần phải học trước khi bạn biến ứng dụng của bạn thành hiện thực.

May mắn là bạn vẫn quyết định làm.

Từ đó trở đi, bạn tập trung chủ yếu vào thực hiện từng bước nhỏ một.

Đầu tiên, bạn tạo ý tưởng. Bạn sẽ xây dựng website gì? Người dùng của bạn là ai? Bạn sẽ gặp khó khăn gì?

Thứ hai, bạn phác thảo ra những thiết kế thô cho những thứ bạn muốn làm. Bạn hỏi ý kiến bạn của mình hay internet để lấy phản hồi và lặp lại để làm cho nó tốt hơn.

Thứ ba, bạn nghiên cứu ngôn ngữ, công cụ và framework mà hoạt động tốt với các yêu cầu của mình.

Từng bước một bạn ép tâm trí của mình dồn tất cả năng lượng của nó vào từng mục tiêu.

Có lúc bạn viết code.

Bạn thường xuyên bị đình trệ vì bug.

Có lúc bạn quá mệt mỏi không thể làm gì nữa, nên bạn nghỉ một lát.

Những lúc khác, bạn cảm thấy không muốn code. Điều đó ổn. Bạn dành thời gian nghiên cứu hay đọc các chủ đề liên quan đến dự án của mình.

Cuối cùng, sau một vài tuần làm việc vất vả, bạn đã xây dựng nên một nền tảng có thể giúp xử lý ý tưởng lớn của bạn. Đột nhiên, làm việc với ứng dụng của bạn không còn khiến bạn cảm thấy khó chịu nữa. Bạn thấy được phần thưởng của công việc khó khăn ban đầu, và giờ bạn chỉ cần viết thêm một ít code hay tái cấu trúc một chút - những thứ mà bạn đã làm 100 lần trước đó, không vấn đề gì.

Bạn biến những hoạt động từng khó khăn hoặc đáng sợ thành những thứ phức tạp và hấp dẫn.

Đó là cách chúng ta phát triển. Đó là cách chúng ta trở nên tốt hơn. Cho dù đó là lập trình, nhảy múa, chạy hay đọc sách: việc đó không dễ dàng, và sẽ không có một lúc hay một nơi nào đó mà bạn đã "hoàn thành" việc học.

Thay vào đó, tận hưởng quá trình tiêu tốn năng lượng của bạn vào thứ gì đó, và tận hưởng nỗi khổ đi kèm với nó. Bạn sẽ bắt đầu nhận thấy rằng bạn không coi nó như là "đau khổ" - bởi thứ từng là sự đau khổ đã trở thành biểu tượng cho những thứ theo sau nó: một cảm giác hoàn thiện bản thân và tự mãn.

Nói cách khác, sự đấu tranh và tận hưởng sẽ bắt đầu trở thành một. Hãy nhớ lại vòng lặp:

Để tôi nói cho bạn biết một chút về cách học tập mà tôi theo đuổi. Đây không phải là cách học đúng đắn cho mọi trường hợp, nên nếu có cách nào khác đúng với bạn, xin hãy chia sẻ nó ở dưới phần bình luận.

Hãy lấy cách học thư viện React.js làm một ví dụ.

Động lực nào khiến chúng ta học thứ này?

Bước đầu tiên: tôi sẽ tìm kiếm trên Google về tài liệu của React.js và đọc một chút về nền tảng và lý do sử dụng thư viện này.

Biết được "lý do" đằng sau bất cứ chủ đề gì là điều vô cùng hữu ích để dựng nên cách học tập. Lý do đó sẽ trả lời những câu hỏi như:

  • Nó khác như thế nào so với những giải pháp khác?
  • Nó sẽ giúp ích gì cho tôi?
  • Giải pháp này hướng tới giải quyết những vấn đề gì?
  • Liệu công cụ mới này sẽ chỉ có ích trong vòng vài tháng hay nó sẽ thay đổi căn bản cách tôi suy nghĩ và code?

Đọc và hiểu các khái niệm cốt lõi

Thứ hai, tôi đọc qua bất cứ các bài viết giới thiệu hay các ví dụ được cung cấp trong tài liệu.

Chú ý là tôi chưa chạm gì vào code. Đọc và chìm trong các khái niệm cốt lõi trước khi thực hành. Việc này vô cùng quan trọng vì nó sẽ đặt nền tảng cho phần còn lại của việc học của tôi.

Dù tôi có thể bỏ qua và nhắm mắt dùng React.js mà không học các khái niệm cốt lõi, nhưng cuối cùng tôi sẽ nhận hậu quả khi gặp lỗi.

Viết code lần đầu

Sau khi dành thời gian cho các bước trên, tôi bắt đầu thấy được ý nghĩa của những thứ đang diễn ra, hay thậm chí cảm thấy mình hoàn toàn hiểu nó. Đó là lúc bắt tay vào viết code.

Thông thường tôi sẽ cố gắng xây dựng thứ gì đó thật nhỏ với bất cứ công cụ mới nào bằng cách làm theo một video hướng dẫn (ví dụ như trên trang egghead.io) hay một bài viết hướng dẫn trước khi thực hành trong một dự án.

Khi bạn mắc kẹt

... và rồi, chắc chắn là, tôi mắc kẹt.

Đọc tài liệu rất dễ dàng, nhưng thực sự áp dụng nó trong thực tế làm tôi nhận ra là tôi không biết chuyện gì đang diễn ra.

Đây là lúc tôi bắt đầu cảm thấy cảm giác "muốn từ bỏ". Nhưng thay vì trốn chạy khi mọi thứ trở nên khó khăn, tôi tự nhắc mình rằng đau khổ == thành quả. Quay đầu là hèn nhát.

Đây là những thứ tôi làm thay vào đó:

  1. Đầu tiên tôi thu hẹp phạm vi và tìm ra tại sao tôi bị mắc kẹt - tức là xác định vấn đề. Sau đó tôi đưa ra giả thuyết về những gì tôi cho là nguyên nhân gốc rễ hay nguyên nhân của vấn đề. Cho dù tôi không biết, tôi vẫn đoán.

  2. Sau đó tôi bỏ vấn đề và máy tính của tôi qua một bên và làm thứ gì đó giúp tôi thư giãn. Rất khó để làm điều này khi tôi buồn về vấn đề tôi gặp phải, nhưng việc rời bỏ vấn đề này rất hữu ích. (Bạn có nhận thấy các ý tưởng lớn thường xuất hiện trong phòng tắm không?)

  3. Giờ tôi cố gắng debug với giả thuyết của mình trong đầu. Tôi cố gắng tìm hiểu nhiều nhất có thể với giả thuyết của mình mà không tìm kiếm các câu trả lời trên mạng - có thứ tuyệt vời sẽ xảy ra khi bạn cố gắng giải quyết vấn đề bằng cách tự mình thực sự suy nghĩ sâu về nó trước. Cho dù bạn có nhầm đường, bạn cũng đã tự dạy cho mình rất nhiều và bạn sẽ nhớ vấn đề tốt hơn khi bạn gặp nó lần tới.

  4. Nếu giả thuyết của tôi dẫn đến câu trả lời, hu ra! Tôi đã làm được. Nếu không, tôi google tài liệu, bài blog hay các câu hỏi trên Stack Overflow mà có thể giúp tôi đến gần câu trả lời hơn.

  5. Khi đọc, tôi ghi lại bất cứ phần thông tin nào có thể có ích.

  6. Vẫn không có giải pháp? Không sao. Tôi chắc chắn đã học được thứ gì đó giá trị bằng cách đọc qua tất cả những thứ đó, cho dù chúng không trực tiếp giúp tôi giải quyết được vấn đề. Biết đâu những kiến thức này có thể giúp ích lần sau.

  7. Lúc này, nếu tôi thực sự mắc kẹt, tôi sẽ đăng câu hỏi lên Stack Overflow hay hỏi đồng nghiệp hoặc lập trình viên mà tôi biết.

  8. Mặt khác, tôi từ bỏ giả thuyết và lặp lại cho đến khi tôi đến gần với giải pháp cuối cùng hơn. Tại thời điểm nào đó, câu trả lời sẽ luôn xuất hiện.

Có lúc quá trình này tốn vài giây, có lúc nó tốn hàng giờ (hay nhiều ngày). Dù thế nào, quá trình này cũng rất hữu ích cho tập kỹ năng của một lập trình viên.

Cảm giác mắc kẹt với một bug cũng như sẩy chân vào một đường hầm tối om và tìm lấy một tia sáng. Cuối cùng bạn sẽ tìm thấy nó, nhưng trên đường tìm kiếm bạn sẽ khám phá ra nhiều thứ về đường hầm đó - và kiến thức về "đường hầm" sẽ khiến bạn trở nên mạnh hơn.

Hãy coi việc debug là cơ hội để khám phá hơn là một đường vòng tới mục tiêu của bạn, và nó sẽ trở nên thú vị hơn nhiều.

Từ bỏ và lặp lại

Đến thời điểm này của quá trình học, tôi đã xây dựng được thứ gì đó nhỏ nhỏ và giải quyết một số trở ngại nhỏ trong quá trình. Như bạn thấy, đó là một cuộc đấu tranh - rõ ràng là tôi cần thực hành thêm với công cụ mới.

Vậy là, tôi lại thử xây dựng thứ gì đó một lần nữa. Thay vì lao thẳng vào một dự án lớn, tôi tìm kiếm một repo để xây dựng ứng dụng của mình dựa trên đó.

Ví dụ, nếu có một ví dụ online về CRUD todo (dĩ nhiên) sử dụng React.js, có thể tôi sẽ xây dựng một ứng dụng CRUD khác. Khác biệt đủ để tôi bận bịu với việc xây dựng nó, nhưng không quá khác để khiến tôi chán nản nếu có gì đó sai xảy ra.

Làm chủ

Làm chủ cần sự tực hành lặp đi lặp lại, vậy nên tôi tiếp tục xây dựng nhiều dự án nhỏ nữa cho đến khi tôi cảm thấy tôi đã nắm được các khái niệm cốt lõi.

Cuối cùng, tôi bắt đầu có thể tự mình lắp ghép các thứ với nhau mà không phải đọc tài liệu hay xem ví dụ thường xuyên nữa. Chỉ sau đó tôi mới bắt đầu xây dựng thứ gì đó từ đầu bằng chính sức của mình.

Trong suốt quá trình này, tôi cố gằng làm cho quá trình trở nên vui vẻ và hấp dẫn. Tôi thường ép mình làm những thứ khó hơn khả năng hiện tại của mình, nhưng không đẩy mình vào những thứ quá khó mà khiến tôi chán nản và không bao giờ hoàn thành.

Cuối cùng, tôi sẽ bỏ ngay khi tôi thấy mình quá thất vọng để có thể tiếp tục làm.

Với một chút nỗ lực và phương pháp, việc học lập trình sẽ trở nên vô cùng vui vẻ. Ban đầu nó sẽ rất phức tạp, và theo cá nhân tôi đó là lý do mà rất nhiều người sợ nó - không phải vì nó "nhàm chán", mà vì nó "khó".

Sau khi bạn thực hiện quá trình học tập này một vài lần, xử lý những thông tìn mới sẽ trở thành một bài luyện tập trí nhớ. Bạn không thực sự nghĩ về nó. Bạn chỉ học cách cưỡi cơn sóng nỗi khổ và tìm thấy niềm vui trong phần thưởng.

Một cách ma thuật, việc học trở nên "dễ dàng hơn".

0