Là một lập trình viên mới, đây là cách tôi đọc tutorial mà bạn (lập trình viên) viết cho tôi

 (anniemueller.com)
5 điểm bởi GN⁺ 2025-09-23 | 1 bình luận | Chia sẻ qua WhatsApp
  • Bài viết mô tả một cách hài hước sự bối rối và những rào cản mà người mới gặp phải khi đọc các tutorial kỹ thuật do lập trình viên viết
  • Những thuật ngữ chuyên môn và chữ viết tắt mà lập trình viên thường dùng nghe với người mới như một thứ ‘ngôn ngữ người ngoài hành tinh’ hoàn toàn không có ngữ cảnh
  • Các bước cài đặt, đường dẫn tệp, lệnh terminal trong tutorial thường quá phức tạp hoặc bị lược bỏ, khiến việc hiểu nội dung trở nên khó khăn
  • Tác giả chỉ ra rằng những giải thích vốn được xem là hiển nhiên từ góc nhìn của lập trình viên lại trở thành chướng ngại khiến người mới phải mất hàng giờ tìm kiếm và thử sai
  • Bài viết nhắc các lập trình viên viết tutorial rằng họ cần giải thích thân thiện và rõ ràng hơn từ góc nhìn của người mới bắt đầu

Bối cảnh bài viết và vấn đề được đặt ra

  • Tác giả kể lại trải nghiệm của mình với tư cách là một người mới không phải lập trình viên khi đọc các tutorial do lập trình viên viết
  • Bài viết châm biếm tình huống người đọc hoàn toàn không thể hình dung nổi các thuật ngữ kỹ thuật và tên công cụ xuất hiện trong tutorial thực sự có nghĩa là gì
  • Ví dụ: dùng các tên công nghệ hư cấu như Hoobijag, Snarfus, Shamrock portal để nhấn mạnh rằng trong mắt người mới, mọi thứ đều trông rối rắm và phức tạp

Bản dịch nguyên văn

“Xin chào! Tôi là một lập trình viên. Kinh nghiệm liên quan của tôi như sau: tôi code bằng Hoobijag và thỉnh thoảng cũng dùng jabbernocks, tất nhiên còn có cả ABCDE++++ nữa (nhưng tuyệt đối không bao giờ là ABCDE+/^+, cái đó thật vớ vẩn đúng không? haha!) và tôi thích làm việc với Shoobababoo, đôi khi còn xử lý cả kleptomitrons. Tôi đã làm code liên quan đến Shoobaboo ở Company[1], và điều đó dẫn tôi đến với Snarfus. Nào, bắt đầu thôi!

Về tutorial này

Ban đầu tôi dùng Snarfus để làm một thứ cực kỳ đơn giản[2], nhưng càng dùng tôi càng thấy tiềm năng của nó! chromus có hơi rối một chút, nhưng thật ra nó rất đa dụng. Thế là tôi bắt đầu argyling pintafore bằng quagmire thay vì hoobastank! Tôi biết, điên thật. Nhưng nó cũng hoạt động phần nào và thực ra khá vui… cho đến khi tôi gặp phải một rào cản lớn: fisterfunk hoàn toàn không giao tiếp với shamrock portal, cũng chẳng gửi beep-boops cho Snarfus! Tất nhiên bạn biết điều đó có nghĩa là gì[3]— giờ thì toàn bộ hoob-tunnel đã bị gramelions làm tắc nghẽn. Không thể chấp nhận được.

Tôi gần như đã bỏ cuộc, nhưng rồi tôi nhận ra: chỉ cần nối backside Snarfus stagnator với backside shamrock Klingon troglodyte emulater là ổn! Mọi thứ bắt đầu beep-boops và ding-dongs, và cuối cùng tôi cũng đi đến đúng chủ đề thực sự của tutorial này. Và rồi tôi có thể làm một thứ cực kỳ đơn giản theo đúng cách mình muốn! Khá ngầu đúng không[4].

Vậy đây là cách thiết lập nó:

  1. Trong terminal, nhập ajkl;gawgor;iqeg;iJLkqen. wl;R aw;oeiga 4648664 arjarwgj;llj;ja fadgfgajkljl; wlj;sdjk;lfas
  2. Bây giờ hãy đi đến folder/hidden/deep/in/the/file/system/surprise!.file và sao chép nội dung của tệp. Nếu nó không ở đó, có thể nó nằm trong library/library/library/llibrary/liiiiiibrarrrary/llllliiiiibrary/hidden/hidden/hiding/you can’t find me/hidden/nope/never/hahahahereiam.file
  3. Quay lại terminal, dán nội dung tệp vào, rồi nhập 64A786AGR45JAR; rdja;jg [[]][[]][[]][[]]][[]()()()()()()()()(){{}{}{}|{}{|}{}{|}{ ////////////////!! !!!! !! //// !!! agjlkargji;lwej;OI [ASRGASG[]ASGDASG[]EAEadgasg[]EAGE[edaga][]ahgr-0-0=-0-=0-=0=0-0=-0-=0=-0-=0=-0=-0!!!
  4. Boop![5]
  5. Mở Snarfus và tải lên tệp bạn vừa tạo
  6. Chỉ cho vui thôi, nếu bạn muốn bỏ sham của chronostatiomatrix — hãy chạy —()()(]]asdg a=-do —cd go cd stay —sususudododo baby shark—][]. Cái này là tùy chọn
  7. Xong!

Hãy cho tôi biết kết quả thế nào nhé. Tôi cũng tò mò không biết có ai dùng cách này với GewGawGamma hay ometer2.7 không.”

Giải thích chú thích

  1. Có vẻ là một công ty nổi tiếng, nhưng tôi không biết
  2. Hoàn toàn không đơn giản chút nào
  3. Tôi không biết điều đó có nghĩa là gì
  4. Trông thì ngầu đấy nhưng tôi không hiểu gì cả. Dù vậy, thật mừng vì bạn làm được
  5. Ba bước đầu tiên có lẽ sẽ cần khoảng 7 tiếng và 193 lần tìm kiếm. Nhưng khi đến được Boop! thì cảm giác rất phấn khích

Kết lại

  • “Đây chỉ là một bài viết cho vui. Tôi chân thành cảm ơn tất cả những ai chia sẻ kiến thức và viết tutorial.”

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-09-23
Ý kiến trên Hacker News

  • Tôi rất khuyến nghị cách làm là để một người chỉ có kiến thức tối thiểu thử làm theo tài liệu, còn bạn đứng bên cạnh im lặng quan sát. Lúc đó tuyệt đối đừng giúp gì, chỉ quan sát thôi. Qua quá trình đó, bạn có thể phát hiện ra đủ loại vấn đề: người dùng bị mắc ở đâu, tác giả vì quá quen nên không nghĩ tới, hay những phần cấu hình bị bỏ sót. Nếu người dùng đạt được mục tiêu mà không gặp căng thẳng đáng kể thì tài liệu coi như đạt. Nếu không, cần ghi lại không sót một điểm thất bại nào, cải thiện từng mục rồi thử lại với một người mới. Tôi từng thấy cả tài liệu của các công ty lớn kiểu FAANG cũng không qua nổi tiêu chuẩn này. Tôi thật sự biết ơn vì tổ chức của chúng tôi đặt ra tiêu chuẩn cao. Làm tài liệu theo cách này sẽ giảm các cuộc họp lặp đi lặp lại, yêu cầu hỗ trợ, cuộc gọi video, và giúp người dùng tự giải quyết vấn đề

    • Tôi cũng thường gặp vấn đề này khi dùng tài liệu của Apple. Nhiều khi phần định nghĩa trong tài liệu chỉ lặp lại đúng cái tên mà không giải thích gì, đáng lẽ nên viết cụ thể hơn
    • Quy tắc “đừng nói gì, chỉ quan sát” trông có vẻ dễ nhưng thực tế nhiều người không nhịn được mà giải thích hoặc gợi ý. Thậm chí có người còn trực tiếp cầm chuột làm giúp. Để tránh phản ứng rất con người này, việc có một người điều phối trung lập riêng, còn tác giả/lập trình viên chỉ quan sát, cũng rất hữu ích. Nhưng điều quan trọng là phải rèn được kỹ năng “chỉ đứng nhìn”, và nếu muốn đi xa hơn thì tôi khuyên nên tìm hiểu về “think-aloud protocol”
    • Tài liệu onboarding của hầu hết các nhóm trong công ty đều tệ khủng khiếp, và đó cũng là cửa sổ cho thấy trước gánh nặng công việc thực tế. Ba nhóm tôi mới tham gia gần đây hoặc gần như không có tài liệu, hoặc tài liệu đã lỗi thời, nên tôi phải tự đi tìm đúng người để xin quyền truy cập cần thiết hay thông tin về pipeline triển khai. Trong quá trình đó lại viết tài liệu mới, nhưng hễ hệ thống hay quyền hạn thay đổi là nó lại lỗi thời ngay, thành một vòng luẩn quẩn. Chỉ có đúng một nhóm là giúp tôi thiết lập xong toàn bộ môi trường cần thiết chỉ trong hai ngày, và đó là trải nghiệm tuyệt vời nhất. Giờ tôi đang ở một nhóm devex mới và cố cải thiện chính môi trường tài liệu
    • Onboarding bằng cách đọc tài liệu thiết lập tệ hại thực sự làm mức độ căng thẳng tăng lên gấp 10 lần. Tôi luôn khuyến khích nhân viên mới sửa ngay những vấn đề họ gặp như đóng góp đầu tiên. Người mới không có chút bối cảnh nào nên có thể đóng vai trò reviewer tốt nhất
    • Tổ chức của chúng tôi cũng dùng quy trình tương tự. Chúng tôi để người ít kinh nghiệm làm theo tài liệu, rồi khuyến khích mọi người liên tục cải thiện tài liệu sau đó. Vì những người đã có nhiều năm kinh nghiệm thường có “điểm mù”, còn người mới lại rất giỏi chỉ ra chúng. Theo kinh nghiệm của tôi, việc quản lý sự tự tin của người dùng cũng cực kỳ quan trọng. Vì vậy, khi hướng dẫn các bước như “hãy chạy lệnh shell này”, chúng tôi mặc định để một vài phần ở dạng thu gọn (ví dụ: ví dụ output khi chạy thành công, cảnh báo có thể bỏ qua, danh sách lỗi có thể xảy ra và cách xử lý, giải thích cho các lệnh phức tạp, v.v.). Có bước còn đi kèm phần giải thích dài cả một trang, nhưng trong onboarding thì mức độ chi tiết như vậy thực sự giúp ích rất nhiều

  • Tiêu đề bài blog là “Tôi là người không phải lập trình viên, đang đọc tutorial do bạn, một lập trình viên, viết”, nhưng tiêu đề trên HN lại bị đổi thành “Tôi là lập trình viên mới vào nghề...”. Người không phải lập trình viên và lập trình viên mới vào nghề hoàn toàn khác nhau. Ví dụ, với nhân sự HR hay người hoàn toàn trái ngành, ngay cả thuật ngữ nội bộ hay khái niệm cơ bản cũng có thể rất xa lạ. Trong trường hợp đó, nếu lập trình viên viết giải thích quá rời rạc thì bị chỉ trích cũng đáng. Ngược lại, lập trình viên mới vào nghề dù thấy khó vẫn có thể tự tra cứu thuật ngữ, khái niệm mới, và sau một thời gian còn có thể cập nhật tài liệu cho những người mới đến sau

    • Tham khảo thêm thì tiêu đề bài được gửi lên ban đầu là “người không phải lập trình viên”, nhưng giữa chừng đã bị đổi thành “lập trình viên mới vào nghề”. Tác giả là một blogger không chuyên về kỹ thuật, và để xử lý website hay CSS thì hẳn đã phải tham khảo nhiều tài liệu kỹ thuật. Tôi nghĩ việc bàn về xuất bản website và sự thiếu hụt tài liệu dành cho người không chuyên có lẽ sẽ phù hợp hơn, nhưng cộng đồng HN kéo cuộc thảo luận sang hướng khác cũng không sao
    • Sự phân biệt này rất quan trọng. Tác giả Annie nói rõ bản thân làm công việc liên quan đến “content/documentation” và có sở thích với CSS, nên thuộc nhóm “người làm lập trình như sở thích nhưng không chuyên”. Tôi nghĩ đây sẽ là một nhóm ngày càng lớn. Khi viết tutorial bao quát cả người mới lẫn người không phải lập trình viên, đôi khi chỉ cần thêm một chú thích rất ngắn cho câu như cd ~/.snarfus (nếu chưa có thư mục thì hãy tạo nó) là đã đủ. Bản thân tôi hồi trước cài Debian cũng từng được một lời giải thích nhỏ như vậy giúp đỡ rất nhiều
    • Trang web khiến tôi ấn tượng khi mới học lập trình là “FromZero”. Nó giải thích từng bước cho người không phải lập trình viên, từ cài IDE cho tới mở console, và với các thuật ngữ lạ thì trấn an kiểu “phần này sẽ nói sau nên giờ chưa cần lo”, rất tuyệt. Tất nhiên, viết tài liệu tốn rất nhiều thời gian và công sức, nên đôi khi có chút giải thích vẫn còn hơn là không có gì. Tôi nghĩ tài liệu cho lập trình viên mới vào nghề nên được viết với mức độ quan tâm như dành cho người không phải lập trình viên
    • Có người cho rằng nếu cái gì cũng không được giải thích thật dễ thì đó là gatekeeping, và họ bỏ qua thực tế là dù bản thân thấy vất vả, không ai có thể lập tức hiểu mọi thứ mà không có kiến thức nền
    • Nếu là tutorial dành cho lập trình viên mới vào nghề chứ không phải bài viết cho lập trình viên chuyên nghiệp, thì kỳ vọng nó phải giải thích tỉ mỉ mọi khái niệm như “Hoobijag” hay “shamrock portal” cũng hơi lạ. Thật ra ai trong chúng ta lúc đầu cũng đều học bằng cách lên Google tra những thuật ngữ mình chưa biết

  • Phần lớn tutorial thực ra không dành cho người không phải lập trình viên, mà gần hơn với việc các lập trình viên trao đổi thông tin cho nhau, giống như tài liệu dành cho một cộng đồng tri thức cụ thể kiểu bài báo học thuật. Cách đó cũng không hẳn xấu. Thậm chí tài liệu tôi từng ghi lại trước đây cũng rất tiện để tự tra cứu lại. Vì thế mới có các khóa học và giáo trình riêng cho người mới bắt đầu. Nếu tutorial lần nào cũng phải mở đầu bằng toàn bộ phần bối cảnh dài 30.000 chữ thì sẽ chẳng ai đọc đến hết. Ngược lại, dù thêm nhiều bối cảnh hơn nữa thì với ai đó nó vẫn có thể là chưa đủ

    • Con trai tôi (17 tuổi) rất hứng thú với lập trình, và gần đây tôi vừa dạy nó các khái niệm public/private/internal/static cộng với đệ quy. Giờ tôi đang âm thầm chờ xem lần tới nó phản ứng thế nào
    • Tôi không đồng ý với nhận định rằng “phần lớn tutorial không dành cho người không phải lập trình viên”. Tôi muốn nhấn mạnh rằng ngay tiêu đề tutorial lần này đã nói rõ là nhắm tới người không phải lập trình viên. Khi vật lộn để cài một dự án mã nguồn mở, rất cần có tiếng nói yêu cầu ngay cả hướng dẫn cài đặt cực kỳ cơ bản cũng phải đủ dễ để người mới có thể làm theo. Chỉ cần bỏ sót một bước nhỏ thôi là trong một lĩnh vực không quen thuộc, người ta có thể lãng phí hàng giờ
    • Tôi cũng không nghĩ việc viết tài liệu thân thiện hơn cho tất cả mọi người là điều xấu. Tài liệu tốt không chỉ hữu ích cho người mới mà cả với lập trình viên. Lý do thiếu tài liệu dễ tiếp cận đơn giản là vì người ta không muốn bỏ thêm chút công sức. Hơn nữa, khác với bài báo khoa học, tài liệu cho lập trình viên thường bị viết quá sơ sài hoặc người viết chẳng mấy quan tâm người đọc. Kết quả là nó trở thành tài liệu vô dụng với tất cả trừ chuyên gia. Đó là thất bại
    • Tôi đồng ý rằng cần loại tài liệu xây bối cảnh từng bước cho người mới. Tuy nhiên, gần đây DX (trải nghiệm lập trình viên) thường bị cải thiện theo hướng chỉ ưu tiên “sự dễ dàng”, hy sinh cả những thứ vốn hữu ích như log hay khả năng tìm kiếm thông báo lỗi, thành ra chỉ nhắm tới người mới mà lại làm người dùng cũ khó sử dụng hơn
    • Tutorial ngày nay dường như nhiều khi chỉ là bài viết để phục vụ quản lý thành tích kiểu “tôi đã đóng góp cho dự án X”. Thà tác giả sau 3 tháng tự quay lại làm theo tutorial của chính mình còn tốt hơn, vì khi đó những chỗ thiếu sót sẽ lộ ra rất rõ và có thể cải thiện đáng kể

  • Nhiều technical writer không thực sự nhận thức đúng về “lời nguyền của tri thức”. Tôi từng có kinh nghiệm điều hành guild WoW (World of Warcraft). Có 40 người tập hợp cùng lúc để vào dungeon và phối hợp đánh nhiều boss, trong đó chỉ một sai sót rất nhỏ thôi cũng có thể khiến cả nhóm chết hết. Vì thế mọi người tụ họp trên Teamspeak và chiến thuật luôn được giải thích kỹ từ trước. Bài học lớn nhất ở đây là “hãy giả định người nghe không biết bạn đang nói gì” và “điều đã nói một lần thì hãy lặp lại”. Phần lớn mọi người dù không biết cũng sẽ không ngắt lời để hỏi, nên việc liên tục tự hỏi “mình đang dùng thuật ngữ gì?”, “liệu người kia có thể không biết khái niệm này không?” rồi bổ sung giải thích vào đã mang lại hiệu quả rất lớn. Trải nghiệm giao tiếp kiểu này có thể áp dụng nguyên vẹn vào technical communication, và nếu rèn cho mình thói quen cố vượt qua “lời nguyền của tri thức” thì bạn sẽ giúp nâng cao mức độ hiểu của người khác

    • Tôi từng thấy một guild master 18 tuổi ở guild raid cũ có thể tập hợp người lớn ở nhiều múi giờ, điều phối ổn thỏa việc chia đồ, chiến thuật và lịch trình, và tôi đã nghĩ “cậu này đáng lẽ phải được tuyển thẳng làm quản lý”
    • Chỉ cần có kinh nghiệm điều hành raid 40 người là ai cũng có năng lực hạng nhất để làm project manager. Đó đúng nghĩa là dẫn dắt một “bầy mèo đi hoang” mà không được phép rối loạn chút nào

  • Nhiều homepage dự án hay README trên GitHub được viết như thể “người đọc cái này vốn đã biết hết rồi”. Khi xem tài liệu, tôi mong có thêm sự chu đáo kiểu: “công cụ này cần để làm gì”, “nó giải quyết vấn đề gì”, “nó khác các công cụ tương tự ở điểm nào”, “bây giờ nó còn được dùng không”, và “nó có cho mình đủ thông tin để tự cân nhắc ưu nhược điểm hay không”. Chỉ cần bỏ ra 5 phút nghĩ xem “dù là người mới hoàn toàn thì họ sẽ tò mò điều gì?” rồi viết điều đó ra là khả năng tiếp cận đã tăng lên rất nhiều. Dù là dự án được xây suốt nhiều năm, việc người dùng cứ phải bỏ cuộc vì phiền phức ngay cả khi họ còn chưa nhận ra mình đã tìm thấy thứ cần tìm, theo tôi thật đáng tiếc. Và hiểu rõ vai trò của từng loại tài liệu cũng rất quan trọng. https://diataxis.fr/ là một điểm khởi đầu rất tốt

    • Trong lĩnh vực ROS (robot software), README thực sự quá tệ nên tôi luôn cảm thấy căng thẳng. Ngoài tên dự án ra hầu như không có gợi ý nào, nên chuyện ngay cả việc hiểu nó dùng để làm gì cũng rất khó là xảy ra như cơm bữa. Đây không chỉ là vấn đề của mã nguồn mở; ở chỗ làm tôi cũng có trải nghiệm y hệt, và tôi có cảm giác mình là người duy nhất đứng ra thêm giải thích vào README. Hồi còn thời monorepo thậm chí còn hạnh phúc hơn
    • Tôi hiểu đó là những công cụ do lập trình viên tạo ra bằng tâm huyết và công sức, nhưng chỉ cần chăm chút tài liệu tốt hơn thôi thì rào cản gia nhập đã giảm đi rất nhiều. Hơn nữa, nếu ngay cả tài liệu của các thành phần khác trong cùng stack cũng khó hiểu thì đường cong học tập sẽ dốc lên theo cấp số nhân
    • Trước đây trên HN còn từng có cả dự án được đăng lên mà thậm chí không viết nổi nó là cái gì

  • Điều quan trọng nhất khi viết tài liệu là phải xác định rõ “trình độ hiểu biết của độc giả mục tiêu”. Đặt mốc nền cao hay thấp đều không sao, nhưng nếu lệch quá xa khỏi mốc đó thì chắc chắn sẽ có một số độc giả không hài lòng. Trong tình huống như vậy, bạn có thể chọn biện minh hoặc tìm cách giải quyết. Thực ra giờ với AI, Google, sách vở v.v. thì thứ gì cũng có thể tra ra khá nhanh. Nếu thắc mắc “Shoobababoo là gì” hay “vì sao dùng quagmire” thì cứ tìm kiếm là được. Tất nhiên, lý tưởng nhất vẫn là tài liệu càng tự đầy đủ càng tốt, không cần thông tin ngoài, nhưng thế giới không phải lúc nào cũng cho bạn mức độ tử tế đó

    • Chính vì vậy, việc nhiều hướng dẫn thiết lập cứ bắt đầu từ “giờ hãy double-click file exe rồi bấm next” mới là vấn đề hơn. Việc đặt đường cơ sở cho hướng dẫn thật sự rất quan trọng
    • Tôi chủ yếu viết tài liệu cho các hệ thống nội bộ nhạy cảm, và đôi khi ngay đầu tài liệu tôi ghi rõ “hướng dẫn này giả định bạn đã biết cách dùng x, y, z. Nếu không thì bạn không nên thực hiện việc này”. Quyền truy cập vốn cũng bị hạn chế, nhưng vì trong tình huống DR chẳng hạn vẫn có thể có người không quen phải dùng tới, nên đôi khi tôi cố ý để lại ranh giới kiểu “nếu đến mức này còn không hiểu thì tuyệt đối đừng làm” như một cảnh báo

  • Nguyên tắc tôi luôn nhấn mạnh suốt thời gian dài làm mentoring là “điều mình biết thì tốt nhất nên chia sẻ”. Nếu bạn biết điều gì đó thì hãy giải thích, vì nếu người kia đã biết rồi thì cùng lắm bạn chỉ củng cố thêm sự chắc chắn cho họ, còn nếu họ chưa biết thì đó sẽ là giúp đỡ rất lớn. Thỉnh thoảng có người phàn nàn là quá dài dòng, nhưng khi tôi nói “cái này lỡ đâu người mới, khách hàng hoặc quản lý đọc được nên tôi viết cho họ”, thì đa số đều hiểu. Nguyên tắc này áp dụng cho mọi lĩnh vực: phát triển, báo cáo, quản lý nhân sự, v.v.

    • Tất nhiên cũng có những người cực kỳ ghét bị giải thích điều họ đã biết. Nếu tỷ lệ tín hiệu trên nhiễu quá kém thì ngược lại còn có thể cản trở giao tiếp
    • Trải nghiệm dạy con trai tôi chơi bida cũng tương tự. Một văn hóa bỏ bớt phòng thủ và không tiếc chia sẻ mẹo với đồng đội rất có ích cho sự phát triển. Trong mentoring, thay vì đưa đáp án ngay, nếu dẫn dắt bằng câu hỏi để họ tự tìm ra thì khi chính họ ngộ ra, sự tiến bộ mới thực sự xảy ra
    • Việc đi giải thích cho tất cả mọi người có thể bị hiểu lầm là “mansplaining”, hoặc thành một rủi ro chính trị kiểu “tỏ ra biết tuốt”. Ở công ty, đôi khi an toàn hơn là chỉ trả lời khi người khác đặt câu hỏi

  • Gần đây tôi thử triển khai một ứng dụng từ Gitlab lên Kubernetes của DigitalOcean, và phải dùng 3–4 công cụ bên thứ ba mà không hề có giải thích chúng dùng để làm gì. Cả tên hay đường dẫn phải nhập vào dòng lệnh cũng phải tự suy ra. Không có giải thích cái gì là chuẩn, phải khớp với cái gì. Dù tôi khá vững về Docker, tài liệu của những công cụ này còn tệ đến mức thà không có có khi còn hơn

  • Lý do chính khiến tôi bỏ viết sách để làm một website tutorial là vì tôi có thể dùng nhiều công cụ tương tác khác nhau (<abbr> chẳng hạn) để khiến tutorial dễ tiếp cận hơn với nhiều người. Dù vậy, tôi vẫn thấy bực vì nội dung web ngày nay vẫn cứ mắc kẹt ở mức chức năng của sách giấy. Có bao nhiêu tính năng như bấm, hover, thu gọn vùng nội dung, video, phản ứng của người dùng, v.v., vậy mà vẫn ngập tràn những bức tường chữ dài lê thê. Ngay cả OP cũng dùng kiểu bấm chú thích rồi cuộn hẳn xuống cuối trang, khiến tôi có cảm giác vẫn chưa tận dụng đúng tiềm năng của web

    • Tôi đang thử nâng cấp blog của mình, nên nếu ai có thể giới thiệu những website làm tốt kiểu tutorial tương tác như vậy thì tôi sẽ rất biết ơn

  • Thực ra phần lớn tutorial không phải dành cho người không phải lập trình viên hay cho lập trình viên, mà là những “bài dài dòng không cần thiết” rồi cuối cùng lại bỏ qua một hai bước quan trọng. Theo tôi, nguyên nhân lớn nhất là viết theo kiểu đang giải thích cho người khác vốn đã khó. Nếu không lôi được những điều chỉ có trong đầu mình ra thành câu chữ, người đọc sẽ không bao giờ biết được. Thay vì viết theo kiểu “tutorial”, nên viết như “cookbook” thì sẽ hữu ích hơn trong thực tế và cũng tránh việc nhanh chóng mất giá trị sau mỗi lần nâng phiên bản

    • Trớ trêu thay, dạo này các công thức nấu ăn trực tuyến lại thường có nhiều lan man vô ích hơn cả blog của người không phải lập trình viên