11/08/2018, 20:58

Tự học lập trình trong 10 năm

Đây là bản dịch bài viết Teach Yourself Programming in Ten Years của Peter Norvig thực hiện bởi Nguyễn Đức Giang. Tại sao mọi người đều vội vã như vậy? Bước vào một cửa hàng sách bất kì, bạn sẽ thấy làm thế nào để Tự học Java trong 24 giờ (Teach Yourself Java in 24 Hours) bên cạnh vô số ...

Đây là bản dịch bài viết Teach Yourself Programming in Ten Years của Peter Norvig thực hiện bởi Nguyễn Đức Giang.

Tại sao mọi người đều vội vã như vậy?

Bước vào một cửa hàng sách bất kì, bạn sẽ thấy làm thế nào để Tự học Java trong 24 giờ (Teach Yourself Java in 24 Hours) bên cạnh vô số những cuốn tương tự về tự học C, SQL, Ruby, thuật toán trong vài ngày, thậm chí vài giờ. Tìm kiếm nâng cao trên Amazon với [tiêu đề: teach, yourself, hours, since: 2000] trả về 512 cuốn sách dạng này. Trong số 10 cuốn hàng đầu, 9 cuốn là sách về lập trình (cuốn còn lại là về công việc sổ sách, kế toán). Các kết quả tương tự cũng được tìm thấy khi thay "teach yourself" (tự học) với "learn" (học) hoặc "hours" (giờ) với "days" (ngày).

Như vậy, hoặc là mọi người đang rất vội vã trong việc học lập trình, hoặc lập trình có vẻ như là một lĩnh vực vô cùng dễ học hơn bất cứ lĩnh vực nào khác. Felleisen và những cộng sự đã đề cập tới xu hướng này trong cuốn sách How to Design Programs khi cho rằng "Lập trình dở thì rất dễ. Những thằng ngốc có thể học nó trong 21 ngày ngay cả khi chưa biết gì (về lập trình)". Abstruse Goose cũng vẽ tranh biếm họa về việc này.

Hãy cùng phân tích một tiêu đề sách như Tự học C++ trong 24 giờ (Teach Yourself C++ in 24 Hours) có ý nghĩa thế nào:

  • Tự học (Teach yourself): Trong 24 giờ, bạn sẽ không có thời gian để viết một vài chương trình đáng kể và học từ những thành công cũng như thất bại trong quá trình xây dựng các chương trình đó. Bạn sẽ không có đủ thời gian để làm việc cùng một lập trình viên có kinh nghiệm và trải nghiệm thế giới của C++. Tóm lại, bạn không có nhiều thời gian để học. Vì thế cuốn sách chỉ tập trung vào các vấn đề chung chung một cách hời hợt thay vì hướng đến những hiểu biết sâu sắc. Như Alexander Pope nói: học ít (không phải ít học - ND) là một việc nguy hiểm.

  • C++: Trong 24 giờ bạn có thể học một vài cú pháp của C++ (nếu bạn đã biết một ngôn ngữ khác), nhưng bạn không thể học nhiều về cách sử dụng ngôn ngữ này. Nói một cách ngắn gọn: giả sử bạn là một lập trình viên Basic, bạn có thể học cách viết chương trình với phong cách Basic sử dụng cú pháp C++, nhưng bạn không thể biết thế mạnh (và điểm yếu) thực sự của C++. Điều này có ý nghĩa gì? Alan Perlis từng nói: "Một ngôn ngữ không ảnh hưởng đến suy nghĩ của bạn về lập trình thì không đáng để biết". Có thể bạn phải học một chút về C++ (hoặc thường thấy hơn JavaScript hay Processing) bởi vì bạn cần tiếp xúc với một công cụ có sẵn để hoàn thành một việc cụ thể. Nhưng khi đó bạn không học về lập trình, bạn đang học để giải quyết công việc đó.

  • Trong 24 giờ: rất tiếc, chỉ thế này là không đủ, câu trả lời nằm trong phần kế tiếp.

Tự học lập trình trong 10 năm

Các nhà nghiên cứu (Bloom(1985), Bryan & Harter (1899), Hayes (1989), Simmon & Chase (1973)) chỉ ra rằng cần khoảng 10 năm để xây dựng kĩ năng và hiểu biết ở mức độ chuyên gia về bất kì một lĩnh vực nào trong một danh sách các lĩnh vực bao gồm chơi cờ vua, soạn nhạc, vận hành điện tín, hội họa, chơi dương cầm, bơi lội, tennis, và nghiên cứu về neuropsychology hay topo học. Điểm quan trọng nhất là thực hành một cách có chủ đích: không đơn thuần là làm những việc lặp đi lặp lại mà thử thách bản thân với những vấn đề vượt qua năng lực hiện tại của mình, thử giải quyết nó và phân tích hiệu suất của mình trong và sau khi làm và sửa chữa các sai sót. Lặp lại quá trình này. Tiếp tục lặp lại. Không có đường tắt: ngay cả Mozart, thần đồng âm nhạc từ lúc 4 tuổi, nhưng phải 13 năm sau mới cho ra đời các tác phẩm âm nhạc có giá trị ở tầm thế giới. Ở một dòng nhạc khác, nhóm nhạc Beatles dường như đột ngột xuất hiện với một chuỗi các bản hit #1 và có mặt trong chương trình Ed Sullivan năm 1964. Tuy nhiên họ đã chơi nhạc từ trước đó rất lâu trong những câu lạc bộ nhỏ ở Liverpool và Hamburg từ năm 1957, và mặc dù thu hút đại chúng từ sớm, thành công lớn quan trọng đầu tiên của họ, Sgt. Peppers, được phát hành vào năm 1967. Malcolm Gladwell đã phổ biến ý tưởng này nhưng tập trung vào con số 10.000 giờ hơn là 10 năm.

Có thể con số kì diệu là 10.000 giờ, không phải 10 năm. Hoặc có thể là một số liệu khác; Henri Cartier-Bresson (1908-2004) từng nói "10.000 tấm ảnh đầu tiên bạn chụp là tệ nhất". Kĩ năng và hiểu biết ở mức độ chuyên gia một cách chân chính có thể mất cả đời để xây dựng: Samuel Johnson (1709-1784) nói "Sự xuất sắc trong bất kì lĩnh vực nào chỉ có thể đạt được bằng sự lao động của cả đời người, không thể đạt được với cái giá rẻ hơn." và Chaucer (1340-1400) phàn nàn "đời người quá ngắn, việc học thì lại rất dài.". Hippocrates (c. 400BC) được biết tới với đoạn trích "ars longa, vita brevis", là một đoạn trong "Ars longa, vita brevis, occasio praeceps, experimentum periculosum, iudicium difficile" có thể được diễn dịch như sau "Cuộc đời thì ngắn, việc học thì dài, những cơ hội đang lướt qua, những trải nghiệm đầy nguy cơ, những phán đoán nhiều trắc trở.". Dĩ nhiên, không có một con số cụ thể nào là câu trả lời cho tất cả: cho rằng mỗi một kĩ năng như lập trình, chơi cờ vua, chơi cờ đam hay soạn nhạc yêu cầu một số lượng thời gian như nhau để nắm vững là không hợp lý. Việc cho rằng tất cả mọi người cũng cần một khoảng thời gian như nhau cũng vậy.

Bạn muốn trở thành lập trình viên?

Đây là công thức thành công của tôi cho việc lập trình:

  • Yêu thích lập trình và làm bởi vì nó thú vị. Hãy chắc rằng công việc lập trình luôn luôn đủ thú vị để bạn có thể sẵn sàng bỏ 10 năm/10.000 giờ vào.

  • Lập trình Cách tốt nhất để học là thực hành (vừa học vừa làm). Cụ thể hơn, "hiệu suất tối đa cho các cá nhân trong một lĩnh vực cụ thể không được xác định như là một phần của việc nhiều kinh nghiệm, mà mức độ hiệu suất này có thể được nâng lên ngay cả bởi các cá nhân giàu kinh nghiệm như là kết quả của những nỗ lực có chủ đích." (tr. 336) và "cách học tập hiệu quả nhất yêu cầu một tác vụ rõ ràng với độ khó phù hợp cho cá nhân được giao, phản hồi hữu ích, và cơ hội để lặp lại và sửa chữa lỗi." (tr. 20-21) Cuốn sách Cognition in Practice: Mind, Mathematics, and Culture in Everyday Life là tài liệu tham khảo khá thú vị cho quan điểm này.

  • Trò chuyện với các lập trình viên khác; đọc mã nguồn các chương trình khác. Điều này quan trọng hơn bất cứ cuốn sách hay khóa học nào.

  • Nếu bạn muốn, hãy bỏ ra 4 năm học đại học (hoặc hơn ở trường cao học). Việc này sẽ tạo điều kiện cho bạn đến với các công việc yêu cầu bằng cấp cũng như các hiểu biết sâu sắc hơn về lĩnh vực bạn theo học. Nhưng nếu không thích học, bạn có thể (với một chút tâm huyết) giành được những trải nghiệm tương tự một cách tự thân hoặc từ công việc. Trong mọi trường hợp, chỉ học từ sách không là không đủ. "Việc đào tạo khoa học máy tính không thể khiến bất cứ ai trở thành một chuyên gia lập trình, nó cũng tương tự như việc học về bút lông và thuốc màu không thể làm bạn trở thành họa sĩ được" - Eric Raymond, tác giả The New Hacker's Dictionary. Một trong những lập trình viên tốt nhất tôi từng thuê chỉ tốt nghiệp cấp III; cậu ấy đã tạo ra rất nhiều phần mềm tuyệt vời, có nhóm hâm mộ, và kiếm đủ tiền từ cổ phiếu để mua hộp đêm cho mình.

  • Làm việc trong các dự án với các lập trình viên khác. Hãy là lập trình viên xuất sắc nhất trong một số dự án; hãy là lập trình viên dở nhất trong một số dự án khác. Khi bạn là người xuất sắc nhất, bạn có dịp kiểm tra khả năng dẫn dắt dự án cũng như truyền cảm hứng cho những người khác với tầm nhìn của mình. Khi bạn là người dở nhất, bạn học được cách các chuyên gia làm việc, và những gì họ không muốn làm (vì họ sẽ yêu cầu bạn làm những việc đấy cho họ).

  • Làm việc trên các dự án kế thừa từ các lập trình viên khác. Hiểu các chương trình được viết bởi lập trình viên khác. Tìm hiểu xem cần những gì để hiểu và làm việc với chương trình đó khi các lập trình viên tạo ra nó không có mặt. Suy nghĩ về việc thiết kế chương trình để công việc bảo trì của những người kế thừa (chương trình) từ bạn dễ dàng hơn.

  • Học ít nhất nửa tá ngôn ngữ lập trình. Bao gồm 1 ngôn ngữ chú trọng vào lớp-trừu-tượng (class abstractions) (như Java hay C++), 1 ngôn ngữ chú trọng hàm-trừu-tượng (functional abstraction) (như Lisp hay ML hay Haskell), 1 ngôn ngữ hỗ trợ cú-pháp-trừu-tượng (như Lisp), 1 ngôn ngữ khai báo (như Prolog hay C++ templates), và 1 ngôn ngữ chú trọng tính song song (như Clojure hoặc Go).

  • Hãy nhớ rằng có "máy tính" trong cụm từ "khoa học máy tính". Biết rõ máy tính của mình - thực hiện một chỉ dẫn, tìm nạp một từ từ bộ nhớ (khi có hoặc không có cache miss), đọc các từ liên tiếp từ đĩa hay tìm một đia chỉ mới trên đĩa - hết bao lâu. Đáp án

  • Tham gia vào nỗ lực tiêu chuẩn hóa ngôn ngữ. Có thể là ủy ban ANSI C++, hoặc là việc quyết định xem phong cách viết mã ở khu vực của bạn nên dùng 2 hay 4 khoảng trắng cho việc lùi đầu dòng (indentation). Trong cả hai trường hợp, bạn sẽ biết được những người khác thích gì ở một ngôn ngữ, cảm nhận của họ sâu sắc thế nào, và có thể một chút về lí do học cảm thấy như vậy.

  • Có ý thức về việc thoát khỏi nỗ lực tiêu chuẩn hóa ngôn ngữ càng nhanh càng tốt.

Cân nhắc tất cả các điểm trên, việc bạn có thể đi bao xa khi chỉ học từ sách còn là một nghi vấn. Trước khi đứa con đầu tiên chào đời, tôi đã đọc hết những cuốn sách Làm thế nào để ..., và vẫn cảm thấy như một kẻ mới vào nghề mù tịt. Nhiều tháng sau đó, khi đứa con thứ hai ra đời, liệu tôi có quay lại đọc những cuốn sách kia để ôn lại? Không. Thay vào đó tôi dựa vào những kinh nghiệm cá nhân, mà hóa ra lại hữu ích và làm tôi yên tâm hơn rất nhiều so với hàng ngàn trang sách được viết bởi các chuyên gia.

Fred Brooks, trong tiểu luận No Silver Bullet (Không có viên đạn bạc nào cả) của mình đã đưa ra một kế hoạch gồm 3 bước để tìm kiếm các nhà thiết kế phần mềm xuất sắc:

  1. Nhận diện một cách có hệ thống những nhà thiết kế hàng đầu càng sớm càng tốt.

  2. Phân công một cố vấn nghề nghiệp chịu trách nhiệm cho sự phát triển của những nhà thiết kế tiềm năng và lưu giữ cẩn thận hồ sơ sự nghiệp.

  3. Tạo cơ hội cho những nhà thiết kế đang phát triển này giao lưu và thúc đẩy lẫn nhau.

Những điều này dựa trên giả định rằng một số người có sẵn đủ những phẩm chất cần thiết để trở thành một nhà thiết kế xuất sắc; công việc là để cho họ đi đúng hướng. Alan Perlis trình bày súc tích hơn: "Mọi người đều có thể được dạy để điêu khắc: còn Michelangelo phải được dạy làm thể nào để không (điêu khắc). Với các lập trình viên xuất sắc cũng vậy". Perlis cho rằng những người xuất sắc có sẵn một vài tố chất vượt qua những thứ được đào tạo. Nhưng những tố chất đó đến từ đâu? Là do bẩm sinh? Hay do họ tích lũy qua sự chuyên cần? Như Auguste Gusteau (nhân vật đầu bếp giả tưởng trong phim hoạt hình Ratatouille) khẳng định "bất cứ ai cũng có thể nấu ăn, nhưng chỉ những người gan dạ mới có thể trở thành (đầu bếp) tuyệt vời." Tôi cho rằng đó sự sẵn sàng dành trọn một phần lớn của cuộc đời để thực hành. Nhưng có thể gan dạ là một cách để môt tả điều đó. Hoặc như người phê bình Gusteau, Anton Ego, nói: "Không phải ai cũng có thể trở thành nghệ sĩ xuất sắc, nhưng nghệ sĩ xuất sắc thì có thể xuất hiện ở bất cứ đâu."

Vì thế, đi mua những cuốn sách (tự học) Java/Ruby/JavaScript/PHP, bạn có thể thấy chút hữu dụng. Nhưng bạn không thể thay đổi cuộc đời mình, cũng như trình độ lập trình thực tế của bạn trong 24 giờ hay 21 ngày. Thế nếu nỗ lực chăm chỉ trong 24 tháng thì sao? Đến đây, bạn đã có thể bắt đầu hành trình của mình đến một nơi nào đó...

0