Công cụ tốt là công cụ vô hình
(gingerbill.org)- Công cụ tốt là công cụ biến mất vào hậu cảnh khi người dùng đang tập trung vào công việc, và mục tiêu của người làm công cụ cũng là khiến người dùng không phải ý thức về chính công cụ đó
- Khi đóng gói khiếm khuyết của công cụ thành “câu đố thú vị”, ta dễ nhầm cảm giác trông có vẻ thông minh với năng suất thực sự
- Việc chọn trình soạn thảo như vim, emacs hay Sublime có thể phù hợp với workflow cá nhân, nhưng nếu bảo vệ cả khiếm khuyết như một tín hiệu bản sắc, sẽ khó nhìn nhận ưu và nhược điểm một cách trung thực
- Trong tranh luận giữa TUI và GUI, cũng không nên xem những thiếu sót của triển khai hiện tại là giới hạn bản chất của cả phạm trù; nhiều vấn đề phát sinh chỉ vì chưa có triển khai tốt
- Giá trị mặc định tốt là thiết kế giúp tiết kiệm thời gian cho người dùng; khả năng cấu hình cao hay đường cong học tập dốc chỉ đáng chấp nhận khi được bù lại bằng năng suất thực tế
Tiêu chuẩn của một công cụ tốt
- Công cụ tốt phải vô hình
- Khi người dùng có thể tiếp tục làm việc mà không ý thức về chính công cụ, công cụ đó sẽ biến mất vào hậu cảnh
- Khoảnh khắc công cụ cản trở một tác vụ cụ thể, người dùng lại bắt đầu ý thức về công cụ
- Thái độ đóng gói lại thiếu sót thành “câu đố thú vị” làm mờ việc đánh giá công cụ
- Niềm vui khi tìm ra cách đi đường vòng không chứng minh chất lượng của công cụ
- Việc tận hưởng khiếm khuyết như một thú vui và việc công cụ thực sự tốt là hai chuyện riêng biệt
Tranh luận về trình soạn thảo văn bản
- vim chỉ là một ví dụ; cùng logic này cũng áp dụng cho các trình soạn thảo khác như emacs hay Sublime
- Một số người dùng khen quá trình giải quyết nhược điểm của vim như một câu đố thú vị, hơn là khen ưu điểm của nó
- Có trường hợp người ta thấy vui khi tạo macro để refactor văn bản một lần
- Nếu cùng tác vụ đó có thể xử lý trong chưa đầy 1 phút bằng multi-cursor của Sublime, hoặc bằng một script đơn giản, thì xét theo năng suất thực tế, việc làm macro trở nên kém thuyết phục
- Trình soạn thảo rất quan trọng đối với workflow, nhưng thái độ gần như tôn giáo khi theo một trình soạn thảo cụ thể vì “khí chất hacker” là nguy hiểm
- Với người mới tiếp xúc vim hoặc emacs, bầu không khí này có thể trở thành điểm hấp dẫn
- Sự quen thuộc có thể che lấp khiếm khuyết và khiến người ta khoe khoang khiếm khuyết đó như một trò chơi
Lý do dùng Sublime và những giới hạn được thừa nhận
- Sublime là trình soạn thảo đã được dùng trong 15 năm, và lý do chọn có thể tóm gọn ở vài điểm
- Phím tắt gần với một tập bao hàm của môi trường OS đồ họa, nên chi phí chuyển đổi nhận thức khi qua lại giữa các ứng dụng là nhỏ
- Multi-cursor được xem là tốt hơn macro trong 99,999% trường hợp
- Multi-cursor cung cấp phản hồi trực quan trực tiếp
- Trong workflow chỉnh sửa văn bản, nó có ít “câu đố” cần giải nhất
- Sublime vẫn có khiếm khuyết
- Có lúc thiếu công cụ cần thiết nên phải dùng plugin hoặc xử lý chuyển đổi văn bản bằng chương trình riêng
- Những khiếm khuyết này không được đóng gói thành “câu đố thú vị”, mà chỉ được chấp nhận như sự bất tiện
- vim có thể tốt hơn cho việc chỉnh sửa cơ bản, nhưng được xem là yếu hơn trong các tác vụ hàng loạt không thuộc kiểu grep
- Không cảm thấy vim motion năng suất hơn workflow của Sublime nhiều
- Vì hầu như không viết code trong terminal, trình soạn thảo hướng terminal về cơ bản là không cần thiết
Khi công cụ trở thành bản sắc
- Việc chọn công cụ có thể hoạt động như một lá cờ cho thấy bạn là kiểu người nào
- “Khí chất hacker” vượt ra ngoài thẩm mỹ đơn thuần và đôi khi trở thành tín hiệu bộ lạc
- Khi bản sắc bị gắn với công cụ, việc thừa nhận khiếm khuyết có cảm giác như phủ nhận chính mình
- Vì vậy, người ta không chỉ chịu đựng khiếm khuyết mà còn bảo vệ và khoe khoang nó
- Rất khó có một cuộc trò chuyện trung thực về công cụ với người mà công cụ đã trở thành một phần tính cách
Cảm giác năng suất và năng suất thực tế
- Ví dụ về macro trong trình soạn thảo cho thấy khác biệt giữa cảm giác năng suất và năng suất thực tế
- Cảm giác thông minh sinh ra khi giải quyết một vấn đề khó rất dễ bị nhầm với kết quả thực sự
- Một công cụ khiến việc khó trở nên mang màu sắc anh hùng, và khiến sự thông minh có cảm giác như thành tựu, có thể trông rất mạnh mẽ
- Đồng thời, tốc độ làm việc thực tế có thể âm thầm chậm chạp
- Tiêu chuẩn trung thực không phải là cảm giác nhập tâm hay thông minh, mà là thời gian bỏ ra và số lỗi
- Một công cụ được nhiều người giới thiệu như truyền giáo có thể thua theo tiêu chuẩn này
- Nếu mục tiêu là năng suất, cần thực sự nghi ngờ niềm tin của mình và kiểm chứng điều gì năng suất hơn
Tranh luận TUI và GUI
- Với người dùng ở trong terminal cả ngày, lợi thế của ứng dụng terminal là rõ ràng
- Nhưng đa số lập trình viên không bị nhốt trong terminal cả ngày
- Phê bình rằng ứng dụng GUI không thể điều hướng chỉ bằng bàn phím không có nghĩa GUI về bản chất là tệ
- Chỉ là nhiều GUI không hỗ trợ đủ tốt việc điều hướng bằng bàn phím
- Không có điều gì về bản chất khiến GUI không thể điều hướng bằng bàn phím
- Nhiều người làm công cụ không triển khai điều này, hoặc không nhận ra rằng trong nhiều trường hợp, điều hướng bằng bàn phím năng suất hơn dùng chuột thường xuyên
- So sánh rằng một ứng dụng TUI cụ thể tốt hơn một lựa chọn GUI cụ thể là hợp lý
- Tuy nhiên, kết luận rằng TUI về bản chất tốt hơn GUI gần giống với sai lầm nhầm giới hạn của triển khai hiện tại thành giới hạn bản chất
Desktop Linux và niềm vui cấu hình
- Đến năm 2026, “năm của desktop Linux” vẫn chưa đến
- Một trong những lý do là nhiều người dùng Linux thích việc chỉnh sửa file cấu hình để thay đổi hệ thống như một câu đố thú vị
- Ngay cả khi chính mình từng trải qua giai đoạn đó, theo thời gian người ta sẽ chỉ muốn một công cụ hoạt động tốt
- Việc cấu hình trong nhiều giờ hoặc nhiều ngày không còn là điều mong muốn
- Giá trị mặc định phải tốt và phải chạy được ngay
- Khi cần điều chỉnh nhỏ, việc đó phải xong trong vài giây
- Khả năng cấu hình tối đa không nên là mục tiêu của công cụ, mà nên là một lựa chọn được dùng khi thực sự cần
- Thiết kế công cụ theo hướng công thái học là việc cung cấp cả giá trị mặc định tốt lẫn lối thoát khi cần
Giá trị mặc định tốt và trách nhiệm của người làm công cụ
- Giá trị mặc định tốt là trách nhiệm của người làm công cụ
- Người làm công cụ dễ đẩy gánh nặng cấu hình, điều chỉnh và học tập sang người dùng
- Nhiều gánh nặng là kết quả của việc nhà thiết kế né tránh quyết định
- “Khả năng cấu hình cao” có thể trở thành cái cớ để không đưa ra quan điểm nào và chuyển vấn đề cho người dùng
- Giá trị mặc định tốt là sự tôn trọng thời gian của người dùng
- Nếu người làm công cụ suy nghĩ một lần, vô số người dùng sẽ không phải lặp lại cùng suy nghĩ đó
- Lối thoát là cơ chế dành cho một thiểu số thực sự có nhu cầu đặc biệt
- Nó không được thay thế việc làm tốt trường hợp phổ biến
Đường cong học tập dốc không phải là tính năng
- Cũng có cách bảo vệ rằng độ khó của một công cụ là cốt lõi
- Lập luận là nó lọc bỏ những người không tận tâm, và nếu vượt qua được ngưỡng khó thì sẽ được đền đáp cả đời
- Đường cong học tập là chi phí, không phải đức hạnh
- Chi phí đó có thể đáng giá, nhưng phần thưởng phải là năng suất thực tế
- Bản thân sự hài lòng vì đã trả chi phí không nên trở thành phần thưởng
- Logic “vì đã học vài tháng nên nó phải có giá trị, và người khác cũng nên làm theo” là đóng gói chi phí chìm thành năng lực
- Khi đó, câu đố không còn là công việc được làm bằng công cụ, mà là chính công cụ
Thái độ quan trọng hơn lựa chọn công cụ
- Đây không phải là lập luận phản đối một công cụ cụ thể, mà là phê bình cách suy nghĩ về công cụ
- Dùng vim, emacs hay Sublime đều được
- Tiêu chuẩn là liệu công cụ đó có biến mất vào hậu cảnh và giúp người dùng tiếp tục làm việc hay không
- Tiêu chuẩn này mang tính cá nhân
- Vấn đề là những câu chuyện bám quanh lựa chọn công cụ
- Đóng gói lại giới hạn thành tính năng
- Bán nỗ lực đi đường vòng qua khiếm khuyết như một phần thưởng
- Công cụ được nâng cấp từ “thứ dùng” thành “một phần của bản thân”
- Tín hiệu rõ ràng nhất cho thấy công cụ đang phục vụ đúng cách là trạng thái người dùng không còn nhận ra công cụ đó
- Công cụ tốt nhất không phải là công cụ có câu chuyện hay nhất, mà là công cụ khiến người dùng quên rằng mình đang dùng nó
1 bình luận
Các ý kiến trên Hacker News
Sau khi thiết kế khá nhiều công cụ nội bộ cho các nhóm developer, tôi thật sự đồng ý
Trước đây tôi nghĩ vì người dùng là developer nên nên để lộ “cấu trúc nội bộ”, nhưng thực tế điều đó chỉ tạo thêm chướng ngại cho đồng đội khi họ làm công việc chính
Đồng đội dùng công cụ tôi tạo ra để làm việc công ty cần, chứ họ không muốn mày mò một công cụ nhỏ mà ở nơi khác chẳng bao giờ đụng tới, và cũng không có lý do gì phải làm vậy
Hiện giờ tôi vẫn để lại nhiều lối thoát, nhưng cố thiết kế công cụ nội bộ sao cho người dùng tự nhiên rơi vào hố thành công
Và thông báo lỗi, thông báo lỗi, thông báo lỗi, cùng các gợi ý tự động cho lỗi thường gặp là rất quan trọng
Cũng hơi thất vọng vì có nhiều người chỉ bám vào ví dụ trong bài mà không nhìn vào ý chính của bài
Nếu nó giúp người dùng trực tiếp làm việc mà họ coi trọng, khả năng cấu hình rất có giá trị; nhưng nếu là công cụ dọn đi một vấn đề mà họ ít coi trọng hơn, nó lại có thể trở thành trở ngại
Ví dụ cách Gusto xử lý thay phần lương, thuế và nộp biểu mẫu là rất tốt, vì gần như không cần nghĩ đến hay chạm vào
Nhưng với người có công việc chính là lương, kế toán, thuế, hoặc làm ở bộ phận HR, pháp lý, tài chính của doanh nghiệp lớn, sự đơn giản hóa như vậy có thể có hại. Vì họ sẽ phải vật lộn với công cụ, hoặc nói nhẹ hơn là công cụ đã đơn giản hóa quá mức công việc của họ
Ngoài ra, ai là người thực sự trả tiền, và công cụ đó phục vụ mục đích phòng vệ như khả năng audit, bảo mật, hạn chế hành vi không mong muốn, hay phục vụ mục đích sáng tạo, cũng là vấn đề lớn. Tính năng sáng tạo hấp dẫn hơn nhưng khó định lượng, và người dùng cuối thường không sẵn sàng trả nhiều tiền tương xứng dù nó giúp ích cho vai trò của họ đến đâu
Tức là đặt các giá trị mặc định hợp lý và cho phép tùy chỉnh khi cần. Nên bắt đầu từ trường hợp 80%, cho phép thay đổi nếu muốn, và đó phải là tùy chọn
Đặc biệt trong công cụ dành cho developer, thường có xu hướng ngần ngại khi đưa ra quan điểm mạnh. Nếu không chắc một lựa chọn nào đó “luôn đúng”, hỏi người dùng có vẻ an toàn hơn, và developer thì khá hay soi xét
Nếu nghĩ rằng “95% có lẽ sẽ muốn cách này, nhưng 5% kia cũng có điểm hợp lý, nên mình sẽ làm cho mọi người như nhau”, thì công cụ sẽ tệ hơn với đa số người dùng
Hỗ trợ tùy chỉnh phức tạp hơn nhiều so với tưởng tượng. Không chỉ là vấn đề bug; từng lựa chọn một đều làm việc trau chuốt trải nghiệm người dùng trở nên khó hơn. Phạm vi kiểm thử cũng lớn hơn, và các abstraction linh hoạt hơn cũng khó thiết kế hơn
Tuy vậy vẫn có phần cần cân bằng: việc buộc mọi người làm theo cách đúng
Luôn có người phàn nàn rằng họ bị kẹt vì phải làm cho đúng, và họ thường cảm thấy đó là lãng phí thời gian
Từ góc nhìn tổ chức, mục tiêu là tạo ra đường cong hiệu suất cao nhất trong thời gian nhân viên còn làm việc; còn từ góc nhìn nhân viên, đó là đường cong hiệu suất cho toàn bộ sự nghiệp
Rất nhiều điều phụ thuộc vào quan hệ giữa những người liên quan. Nếu người khuân vác chuyển nhà tập thể dục hôm trước nên bị đau cơ, với tôi kết quả sẽ chậm hơn và tệ hơn; nhưng với công ty chuyển nhà, về dài hạn người đó mạnh hơn và làm được nhiều việc hơn, nên có thể là tốt. Tuy nhiên nếu hôm đó họ nghỉ việc hoặc bị sa thải thì lại là kết quả xấu
Đánh giá thật sự không phải là macro hay chỉnh sửa bằng Sublime cái nào tốt hơn, mà là quá trình tư duy khi tạo macro có giúp ích cho việc khác hay không, và trước đó họ đang làm gì
Theo kinh nghiệm của tôi, gần như không ai sẽ dùng thời gian vốn dành cho macro hoặc học Vim vào công việc thật sự có ý nghĩa. Họ thường làm vậy vì chán hoặc burn out, muốn nghĩ về thứ khác cảm thấy thú vị hơn vào lúc đó
Vấn đề không phải là nhân viên dùng các script ngẫu nhiên, mà là họ không có cảm giác khẩn cấp hoặc sự hứng thú với công việc hiện tại
Hiệu ứng khiến giao diện trở nên “vô hình” thực ra là hàm của thời gian đã dành bên trong giao diện đó
Thứ tác giả đang phản ứng có vẻ gần với ma sát tùy ý do designer hoặc product manager thêm tính năng hay độ phức tạp vào
Nhưng để hoàn thành một tác vụ cụ thể, loại ma sát đó có thể cần thiết. Hãy nghĩ đến tình huống giải quyết xung đột khi merge. Và nếu dùng đủ lâu, ngay cả các bước “cản trở” đó cũng biến mất vào nền
Cụ thể, cockpit của 737 có các bộ điều khiển dày đặc khủng khiếp. Bản thân máy bay cũng có nhiều mode, và cũng có nhiều ma sát được chủ ý tạo ra
Nhưng nếu hỏi một phi công đã điều khiển 737 hơn 10 năm, họ sẽ nói giao diện đó đã trở nên vô hình
Bloomberg Terminal, thứ thường bị xem là “tệ”, cũng vậy. Trong lĩnh vực y tế cũng thế: với người dùng phần mềm quét MR hơn 8 giờ mỗi ngày và muốn truy cập tức thì vào mọi điều khiển, một giao diện đầy nút bấm có thể chính xác là giải pháp phù hợp
Programmer có xu hướng quá nhanh chóng khái quát hóa kinh nghiệm và sở thích của mình rồi áp lên người khác
Nguồn: đã thiết kế phần mềm cho người tiêu dùng và cho chuyên gia trong 10 năm tại IDEO
Bài viết bàn về điều này từ phía người dùng, và cho rằng có một nhóm người dùng thích học các tính năng “bổ sung” có giá trị tối hậu thấp hơn chức năng cốt lõi
Phần then chốt là: “Nếu mọi người dùng vim, emacs, v.v. vì thật sự thấy chúng tốt và hiệu quả thì tôi sẽ không phê phán. Con người cảm thấy thoải mái nhất với thứ mình quen thuộc. Nhưng những người tôi đang nói đến vì sự quen thuộc đó mà không nhìn ra khuyết điểm của công cụ, rồi phô diễn và ca ngợi các khuyết điểm ấy như một trò chơi”
Từ góc nhìn của một người đã dùng terminal lâu năm, tôi không quá ngạc nhiên khi mọi người không hiểu. Cuộc trò chuyện thường diễn ra như thế này
“Trong terminal, có thể làm đủ thứ bằng những lệnh đơn giản”
“FrobnicatorStudio của tôi có phím tắt Ctrl+Alt+So cho việc đó”
Cứ thế kéo dài mãi, rồi trôi sang những so sánh gần như vô nghĩa kiểu “trong Vim, bấm bốn lần là xóa được 24 dòng” và “Sublime có nhiều con trỏ”
Có lẽ luận điểm đúng đắn là nhờ cách terminal kết hợp các công cụ dòng lệnh nhỏ thành pipeline, nó bao phủ được vô số use case, nhưng có một đường cong học tập mất khoảng một năm mới thấy thoải mái
Khi đạt đến điểm đó, bạn có thể năng suất hơn hẳn người dùng GUI trung bình, nhưng để tới đó cần sự dấn thân và đau đớn, và nhiều người đi theo con đường đó không phải vì tự nguyện mà vì không còn cách nào khác
Trường hợp của tôi là công việc đầu tiên đòi hỏi quản trị server của khách hàng qua ssh, và các server đó chỉ được cài đặt tối thiểu. Nhiều khi thậm chí không có vim mà chỉ có vi, nên tôi không có lựa chọn nào ngoài việc tìm cách làm việc hiệu quả trong môi trường đó
Nếu không có trải nghiệm ấy, tôi không chắc mình có chịu đựng nỗi đau khi bắt đầu làm việc trong terminal hay không
Nhưng đến một lúc nào đó tôi cảm thấy mình đang lãng phí quá nhiều thời gian ở đó. Tôi quay lại dòng lệnh với tshark và jq, bash/awk/grep cũ kỹ và gnuplot; sau đó thì dùng Python, nhưng vẫn dùng output của tshark
Cuối cùng tôi đã tự làm cả parser pcap và pcapng, xử lý ethernet-ip-udp/tcp, rồi đến một Java IDE hoàn chỉnh, và không quay lại nữa
Với mọi công cụ capture và khám phá dữ liệu phải dùng lặp đi lặp lại, tôi cũng đã đi qua con đường ngoằn ngoèo tương tự
Tôi nghĩ chắc không chỉ mình tôi trải qua các giai đoạn lặp lại của việc cải tiến công cụ như thế này, và ước gì có một thang đo được đặt tên thật chuẩn để mô tả nó
Terminal cho bạn năng lực lớn hơn vô hạn, nhưng những việc bạn thực sự làm đều đặn có khả năng chỉ khoảng 20 việc. Nếu 20 việc đó là tất cả, thì rất khó thuyết phục họ vì đường cong học tập
Ví dụ, nếu đang ở terminal và muốn tìm build script, bạn có thể làm kiểu
cat packages.json | jq .scriptsTrong terminal thì hữu ích, nhưng nếu đang ở VSCode thì
ctrl-p -> packages.json -> ctrl-f -> scrlà xong, và thực tế còn ít phím bấm hơnWorkflow của mỗi người thật sự rất cá nhân, nên tôi sẽ không bảo ai phải đổi, nhưng với tôi, tôi thích công cụ hiểu cấu trúc dự án hơn là công cụ chỉ coi dự án như văn bản thuần, nên IDE hợp hơn
App dòng lệnh là các công cụ bạn tương tác bằng cách gõ lệnh trong shell, như grep, sort, cp, git, ls, tar. Nếu biết cách dùng thông thường, bạn cũng có thể dùng chúng trong script, và vì thế có thể kết hợp chúng thành pipeline
App giao diện người dùng dạng văn bản là các app tương tác chiếm quyền điều khiển terminal trong lúc dùng, như Vim, Emacs, Tmux, Lynx, Tig, Midnight Commander, Claude Code
Những thứ này không được kết hợp bằng pipeline. Chính xác hơn là bạn không đưa chúng vào pipeline theo đúng cách vẫn dùng hằng ngày. Nếu làm được, nhiều khả năng là vì app đó cung cấp giao diện dòng lệnh tách biệt với TUI
Cần thời gian để có thể dùng cùng một hộp công cụ cho mọi vấn đề, nhưng cuối cùng thì hiệu quả hơn
Tuy nhiên rất khó thuyết phục. Trước khi tự giải quyết một vấn đề khó làm nếu không dùng công cụ dòng lệnh, người ta khó hiểu được sự đơn giản đó
Dù vậy tôi vẫn dùng dòng lệnh rất nhiều cho mọi việc. Thường tôi mở sẵn một cửa sổ konsole, khi cần build hay test thì alt+tab sang đó thay vì dùng hỗ trợ “build system” của Sublime
Tôi chỉ dùng Vim khi cần ssh hoặc khi dùng Termux trên điện thoại
Các công cụ GUI có thể mở rộng như Sublime, VSCode, v.v. cũng bao phủ vô số use case, thậm chí còn cung cấp môi trường thực thi ổn định và tái lập tốt hơn
Tôi nghĩ lý do những cuộc tranh luận như thế này không bao giờ kết thúc là vì nhìn chung con người hay suy nghĩ khép kín. Khó đặt mình vào vị trí người khác, và còn khó hơn để nghiêm túc chấp nhận khả năng mình sai
Rốt cuộc, vấn đề này chỉ quan trọng với người mới. Khi đã đủ quen rồi, dùng gì đi nữa thì nút thắt năng suất cũng không còn là công cụ nữa. Tất nhiên ed có thể là ngoại lệ
Về luận điểm “họ không biết rằng điều hướng bằng bàn phím năng suất hơn rất nhiều so với việc thường xuyên với tay lấy chuột”, khá nhiều người nói rằng mình năng suất hơn thực ra chưa từng đo lường
Trong nhiều năm đã có nhiều cuộc thi điều hướng bằng bàn phím so với chuột, và tùy chi tiết thiết kế bài test mà bên này thắng hoặc bên kia thắng, nhiều khi chênh lệch cũng khá lớn
Không ít trường hợp cách mà người dùng từng nói là năng suất hơn lại thua khi nhìn vào kết quả thực tế
Tôi không muốn đuổi theo một chỉ số năng suất tuyệt đối, mà muốn một môi trường không phá vỡ dòng chảy
Với nhiều người, hành động với tay lấy chuột làm đứt mạch và cảm thấy gượng gạo, thường còn tệ hơn việc chậm 1 giây. Vì nó kéo họ ra khỏi ngữ cảnh đang có trong đầu
Với tôi, dùng chuột khi làm việc là tự nhiên, nên việc thay đổi workflow để mọi điều hướng đều bằng bàn phím là bỏ ra một nỗ lực bổ sung rất lớn chỉ vì trong một số tình huống có thể tiết kiệm được chút xíu thời gian
Với các công cụ mà trọng tâm là đọc, nhập, rồi xử lý những gì đã đọc và nhập, như trình soạn thảo văn bản, IDE, trình quản lý file, có thể cho thấy điều hướng bằng bàn phím nhanh hơn và tự nhiên hơn khi người dùng đã học phím tắt
Ngược lại, với các công cụ mà thông tin thị giác không phải văn bản là trung tâm, cuộc tranh luận bàn phím so với chuột nghiêng về phía chuột nhiều hơn hẳn
Dù vậy, vẫn có những lúc phím tắt hiệu quả hữu ích hơn nhiều so với menu và icon. Nhìn vào phần mềm CAD hay mô hình hóa 3D, 90% công việc của người dùng là xử lý dữ liệu không gian được hiển thị trực quan, nhưng nếu biết phím tắt để đổi công cụ hoặc chỉnh thiết lập công cụ thì sẽ nhanh hơn nhiều và giảm việc phải liên tục lục lọi qua các menu lồng nhau
Tôi lo rằng tác giả dường như đang nhầm lẫn việc mình quen với công cụ của mình với bằng chứng rằng nó tốt hơn
Trên thực tế, mọi công cụ đều có đánh đổi, và nếu người dùng thích công cụ X hơn công cụ Y thì rất có thể không phải vì họ ngu ngốc, mà vì họ tận dụng tốt hơn những affordance của công cụ đó mà chỉ người thành thạo mới hiểu
Nếu bắt một lập trình viên dùng vim, emacs và Sublime Text mỗi thứ 10 năm, có lẽ họ sẽ không thể khẳng định chắc chắn cái nào tốt hơn. Họ có thể có sở thích cá nhân, nhưng cũng sẽ giải thích được vì sao người khác lại thích công cụ khác
Đây có vẻ là một tranh luận xuất phát từ việc chưa từng thật sự cho phần mềm chưa quen thuộc một cơ hội đúng nghĩa
Theo tôi, dấu hiệu của một người kỳ cựu từng trải là sự hoài nghi mơ hồ đối với mọi phần mềm và mọi lời hứa sẽ cải thiện phần mềm đó. Về dài hạn, mọi phần mềm đều hội tụ về sự tầm thường
Tôi chỉ nói rằng mình không đồng ý với ý tưởng xem ma sát của công cụ là một tính năng
Cũng có thể lấy nguyên lập luận của anh ấy để cho thấy Vim là trình soạn thảo hoàn hảo với tôi. Vì khi tôi dùng Vim, nó trở nên vô hình, và ở một mức độ nào đó vì tôi đã biến Vim thành công cụ mình muốn
Anh ấy đã biến Sublime thành công cụ mình muốn. Dù vậy, ý chính vẫn giữ nguyên. Nếu bạn tạo ra thứ gì đó để người khác dùng, việc làm cho công cụ đó trở nên vô hình với người dùng là một thuộc tính rất mạnh
Tầm thường có nghĩa là “chất lượng bình thường hoặc phổ biến”
Khi xây ứng dụng CRUD tiếp theo, có thể bạn không nhất thiết cần công nghệ mới nhất, tốt nhất và phi thường nhất
Nếu trích câu tôi đã viết thì là thế này: “Điều khiến tôi bối rối là nhiều người xem ma sát đó, tức nỗ lực đi vòng qua giới hạn của công cụ, như phần ‘thú vị’, và quảng bá nó như thể đó là bằng chứng rằng công cụ rất tuyệt.”
Điều này không liên quan đến việc tôi hay người khác chọn công cụ nào và vì sao, mà là về thái độ xem khiếm khuyết như một thứ để đi đường vòng như trò chơi giải đố
Người bảo trì một công cụ tốt thường nhìn nhận nó tiêu cực hơn rất nhiều so với cách người dùng thực sự nhìn công cụ đó
Rất khó phân biệt giữa “hôm nay 10 người phàn nàn về lỗi hoặc tính năng còn thiếu và 9990 người dùng không vấn đề gì” với “hôm nay 10 người phàn nàn và chỉ 90 người dùng không vấn đề gì”. Nhưng nỗ lực cần thiết để đi từ mức hài lòng 90% lên 99,9% là khác nhau khổng lồ
Tôi rất nghi ngờ rằng đây là một yếu tố lớn dẫn đến burnout của người bảo trì mã nguồn mở
Người dùng không hài lòng nổi bật hơn người dùng hài lòng rất nhiều, và so với tốc độ tăng của người dùng mới, tỷ lệ người dùng không hài lòng tạo ra cùng một lượng báo lỗi/yêu cầu tính năng sẽ giảm xuống
Cuối cùng, người bảo trì sẽ có ảo giác rằng dù cải thiện thế nào thì cảm nhận về chất lượng tổng thể cũng không thay đổi, và động lực tiếp tục bị bào mòn
Tôi không biết giải pháp tốt cho vấn đề này là gì. Câu trả lời hiển nhiên là khen ngợi thường xuyên hơn khi mọi thứ hoạt động tốt, nhưng trên thực tế đây gần như là một vấn đề hành động tập thể vốn hiếm khi xảy ra
Cá nhân tôi cố tình đưa ra phản hồi tích cực thường xuyên và nhiệt tình khi thứ gì đó hoạt động tốt, nhưng nếu không phải ai cũng làm vậy thì khó tạo ra khác biệt lớn
Tôi nhớ đến câu trích dẫn này
“Chúng ta luôn nhận ra người cúi mình, tất bật và khúm núm, rồi có lẽ sẽ nói: ‘Thật khiêm nhường biết bao!’ Nhưng người thật sự khiêm nhường thì không nổi bật. Thế gian không biết đến anh ta.”
~ Tito Colliander
Đoạn “dấu hiệu rõ ràng nhất cho thấy một công cụ phục vụ bạn tốt là bạn không còn ý thức về nó nữa, tức là nó trở nên vô hình. Vì bạn không biến khuyết điểm thành sở thích, bạn không ca ngợi khuyết điểm mà chỉ hơi bực mình và đi đường vòng” có vẻ phụ thuộc vào người dùng nhiều hơn là vào công cụ
Tất nhiên các công cụ khác nhau sẽ thu hút những người dùng khác nhau, và cũng có thể đo được tương quan mạnh
Ngoài ra, lập trường này thiếu cân bằng. Công cụ không bao giờ hoàn hảo, đôi khi ta nhận ra nó có thể được cải thiện, và phải cân nhắc giữa việc triển khai thay đổi đó với tác động của nó lên thói quen
Càng dùng lâu thì những thay đổi như vậy sẽ càng nhỏ đi, nhưng cách sử dụng sẽ tiến hóa trong suốt cuộc đời, và việc công cụ cũng thay đổi như vậy là điều tự nhiên
Đây là một cách diễn giải khá khác thường
Việc tác giả cứ khăng khăng rằng Vim “hiện ra” trong khi ngụ ý rằng đa con trỏ và các tính năng của Sublime thì không, nghe khá lạ. Việc bạn đã được rèn luyện để đầu óc không còn phải nghĩ về nó nữa không có nghĩa là nó ít hiện ra hơn
Đa con trỏ không phải là tính năng mặc định trong nhiều công cụ, và nếu tính cả việc dùng nó hiệu quả thì đó cũng là thứ phải học. Cũng giống như key binding của Vim vậy
Hơn nữa, Vim không chỉ là một lựa chọn TUI cho người dùng thuần terminal. Nó còn là key binding dành cho những người đã học cách biến bàn phím thành phần nối dài tự nhiên của cơ thể, để không phải liên tục qua lại với chuột. Cũng như đa con trỏ có thể trở thành thứ như vậy với một người đã dùng Sublime 15 năm
“Tôi đã thấy người ta nói việc tạo macro để xử lý một bài toán refactor văn bản dùng một lần ‘vui’ đến mức nào. Nhưng khi nhìn họ làm gì và mất bao lâu, phản ứng thật lòng của tôi là: việc đó có thể làm trong 1 phút bằng đa con trỏ của Sublime, hoặc đơn giản là viết một script ngắn.”
Và “Điều khiến tôi bối rối là nhiều người xem chính ma sát đó, tức nỗ lực đi vòng qua giới hạn của công cụ, như phần ‘vui’, rồi quảng bá nó như bằng chứng rằng công cụ đó xuất sắc.”
Nếu bạn có thể dùng macro của Vim hiệu quả thì tốt. Nhưng nếu đã dùng Vim hàng chục năm mà vẫn không dùng được, thì đừng quảng bá nó như phần “vui”
Cảm nhận phổ biến nhất là có đường cong học tập, nhưng cuối cùng thì đáng công
Tôi không hiểu ý đó là gì. Macro của Vim cũng cho phản hồi trực quan trực tiếp trong lúc viết. Bạn ghi macro bằng cách chỉnh sửa như bình thường, rồi phát lại phần chỉnh sửa đó sau
Tôi không biết về mặt kỹ thuật có thể dùng macro mà không nhìn thấy hiệu ứng thời gian thực lên văn bản trong lúc viết hay không, nhưng tôi chưa từng làm vậy
Vì tò mò nên tôi đã tìm hiểu đa con trỏ, và có vẻ ưu điểm của nó là một giao diện duy nhất dễ giải thích. Trên thực tế, để thay thế nó, người ta sẽ dùng nhiều lệnh Vim khác nhau
Tôi đồng ý rằng với hầu hết việc phù hợp để dùng đa con trỏ, đa con trỏ có thể tốt hơn macro. Nhưng thường thì với những việc như vậy tôi không dùng macro
Phần lớn những việc tôi làm bằng macro có vẻ không thể làm bằng đa con trỏ
Nếu có ví dụ kiểu “trong tình huống này, đa con trỏ rất tuyệt và Vim không có phương án thay thế tốt”, tôi muốn được chứng minh là mình sai
Nói vậy không có nghĩa là đa con trỏ không có đường cong học tập. Vẫn phải suy nghĩ cách đặt con trỏ vào đúng vị trí
Tôi từng dùng cụm “vô hình” khi mô tả emacs magit
Nó là một lớp mỏng trên đầu output của git: xuất hiện, suy ra tham số từ trạng thái UI, gọi các lệnh git thông thường rồi biến mất
Nhẹ và nhanh. Có vẻ không phải vậy với các dự án lớn, nhưng nghe nói là thế