Fast - Sức mạnh của phần mềm nhanh

• Trong phát triển phần mềm, hiếm khi người ta trực tiếp yêu cầu sự nhanh (fast), nhưng phần mềm nhanh tạo ra thay đổi trong hành vi người dùng
• Các công nghệ như triển khai nhanh và truyền phát thời gian thực cải thiện mang tính đột phá hiệu suất công việc và làm việc từ xa
• Phần mềm chậm gây ra ma sát nhận thức, và thực sự là yếu tố làm suy giảm đáng kể năng suất của người dùng
• Phần mềm nhanh không che giấu sự phức tạp, mà thể hiện tính đơn giản và sự tập trung
• Trong tương lai, ngành phát triển sẽ ngày càng coi trọng tối ưu hóa hiệu năng và trải nghiệm

---

Ngành phần mềm không đòi hỏi sự nhanh

• Trong ngành phần mềm, người ta chủ yếu yêu cầu tính năng, giá cả, tích hợp dữ liệu, nhưng hiếm khi trực tiếp yêu cầu “nhanh”
• Tuy nhiên, phần mềm nhanh có sức mạnh thay đổi chính hành vi của người dùng
• Khi thời gian triển khai code được rút xuống còn tính bằng giây, tần suất triển khai của lập trình viên cũng tăng lên
• Tính năng tự động hoàn thành mã nguồn dựa trên AI giúp việc tạo prototype bằng những ngôn ngữ chưa quen trở nên dễ dàng
• Công nghệ truyền phát thời gian thực mở ra khả năng cho làm việc từ xa

Giới hạn của phần mềm chậm

• Phần mềm chậm tạo ra nhiều ràng buộc hơn chúng ta nghĩ
• Ví dụ, khi sử dụng WiFi trên máy bay, bạn có thể trải qua cảm giác khó đạt được kết quả lớn
  • Chỉ làm được những việc như gửi tin nhắn Slack hoặc trả lời email,
  • Google Docs thường không hoạt động ổn định
  • Cuối cùng, đó trở thành một trải nghiệm khiến người dùng bỏ cuộc
• Ngược lại, các dịch vụ như Instagram mang lại trải nghiệm nhanh một cách nhất quán

Tác động của phần mềm nhanh

• Sự nhanh mang lại cảm giác kỳ diệu
• Phần mềm nhanh loại bỏ ma sát nhận thức và cho phản hồi nhanh hơn một nhịp so với dự đoán, như Raycast hay Superhuman
• Tốc độ phản hồi dưới 100ms của Superhuman cùng khả năng hỗ trợ phím tắt xuất sắc đã cách mạng hóa trải nghiệm dùng email
• Tính năng chuyển tiền tức thì của Mercury cũng mang lại sự ngạc nhiên cho những người dùng đã quen với giao dịch ngân hàng chậm chạp
• Tốc độ của những công cụ này không thường được khen ngợi một cách trực diện, nhưng là yếu tố khiến người dùng cảm thấy như có phép màu

Sự nhanh, tính đơn giản và sự tập trung

• Nhanh đồng nghĩa với đơn giản, và đó là một giá trị ngày càng hiếm trong môi trường phần mềm hiện đại
• Để phần mềm trở nên nhanh hơn, cần có nỗ lực loại bỏ những tính năng không cần thiết
• Những công cụ quản lý dự án gọn gàng như Linear mang lại trải nghiệm sử dụng vượt trội về tốc độ so với các ứng dụng doanh nghiệp như Workday hay Oracle
• Sự nhanh là một biểu hiện của sự tôn trọng dành cho người dùng, cho thấy các yếu tố thừa thãi đã được sàng lọc triệt để

Nỗ lực ẩn phía sau để tạo ra sự nhanh

• Để tạo ra phần mềm nhanh, cần đến tối ưu hóa backend phức tạp
• Tại Cash App, họ cố gắng chỉ thêm những bước thật sự cần thiết trong hành trình người dùng, còn sự phức tạp được xử lý ở bên trong
• Khi tải ảnh lên, Instagram bắt đầu upload ngay trong lúc người dùng nhập caption, khiến người dùng cảm thấy ảnh đã được tải lên ngay lập tức
• Sự nhanh không chỉ là một thành tựu kỹ thuật đơn thuần, mà là kết quả của ưu tiên và sự tập trung

Sự nhanh là niềm vui và động lực

• Phần mềm nhanh tự nó mang lại niềm vui và cảm giác thỏa mãn
• Ngay cả ở những chi tiết nhỏ như đo tốc độ gõ (WPM) hay thiết lập phím tắt, người dùng cũng thích thú với trải nghiệm trở nên nhanh hơn

Tính tương đối của sự nhanh

• Workflow dựa trên AI và LLM mang lại trải nghiệm nhanh vượt trội so với cách làm truyền thống
• Ví dụ, giao việc nghiên cứu cho LLM trong 6 phút tạo ra mức năng suất nhanh hơn hơn 10.000 lần so với trước đây
• Tuy nhiên, trong quá trình phát triển, build và triển khai ứng dụng AI, vẫn còn nhiều điểm chưa bằng thời kỳ phần mềm trước đó
• Ở thời điểm hiện tại, người ta vẫn tập trung vào tính năng mới nhiều hơn là hiệu năng và trải nghiệm
• Trong tương lai, xu hướng ưu tiên tối ưu hóa như độ trễ thấp, thiết kế giao diện, khả năng kết nối và độ tin cậy sẽ xuất hiện
• Khi đó, sẽ mở ra nhiều khả năng mới và sự tiến hóa của trải nghiệm người dùng hơn nữa

Tài liệu tham khảo

• Dưới đây là một số tài liệu bổ sung hữu ích về sự nhanh
  • Patrick Collison: https://patrickcollison.com/fast
  • Charlie Marsh: https://notes.crmarsh.com/python-tooling-could-be-much-much-faster
  • Paul Graham: https://www.paulgraham.com/growth.html

[GN⁺]

Ý kiến trên Hacker News

• Thật sự rất biết ơn YCom vì đã giữ giao diện HN nhanh và ổn định đến vậy. Tôi từng rời Slashdot ngay sau khi họ đổi toàn bộ giao diện dưới danh nghĩa "UI hiện đại", rồi nó biến thành một mớ đầy khoảng trắng và rất khó quét đọc. Trước đây đó là trang tôi đọc hằng ngày
  • Mật độ thông tin và khả năng nhanh chóng tìm thấy thứ mình cần là khái niệm hoàn toàn đối lập với "engagement". Thường các trang cố tình làm mọi thứ phức tạp hơn để tăng thời gian ở lại trang rồi đem đi thuyết phục nhà quảng cáo. Trang còn cố ý tải chậm để người dùng bấm nhầm và tạo ra "chuyển đổi". Thực tế là lừa người khác lại kiếm ra tiền hơn là thực sự đặt người dùng làm trung tâm
  • HN là trang tôi mở lên để kiểm tra xem Internet có đang hoạt động không. Giữa cả đống web bloat, nó thật sự là một điểm sáng
  • UI của HN cũng vẫn cần cải thiện, nhất là trên di động. Độ tương phản thấp, nút quá nhỏ nên khó thao tác, không có dark mode, v.v. Tôi có một phiên bản đúng với UI lý tưởng của mình, viết bằng Elm, hoàn toàn client-side, dùng HN firebase API tại https://seville.protostome.com/
  • Tôi không nghĩ Slashdot suy tàn là vì UI. Giá trị thật sự nằm ở các bình luận của những SME chất lượng cao từ thời rất sớm. Sau khi trang bị bán đi, với người dùng chất lượng thấp hơn, vận hành tệ hơn và sự rời bỏ dần, nó bắt đầu đi xuống. Vẫn còn sống tới giờ cũng khá ngạc nhiên
  • orange site (HN) vẫn không hỗ trợ thẻ liên kết Markdown
• Tôi có cảm giác workflow đưa LLM vào thực tế lại thường chậm hơn. Chức năng "refactor" của IDE xong trong 1 giây, nhưng giao cho trợ lý AI thì 30 giây, kiểu "agent" thì 15 phút. Ví dụ, tôi từng giao cho agent viết mã endpoint HTTP và lúc đầu nghĩ rằng "việc cả ngày đã xong trong 10 phút", nhưng xem lại thì logic bị rối, xử lý lỗi cũng hời hợt. Cuối cùng tôi tự viết lại mất khoảng 5 tiếng, test còn tốt hơn tiêu chuẩn của tôi trước đó và xử lý lỗi cũng ra hồn hơn hẳn. Cũng có nghiên cứu liên quan https://www.reddit.com/r/programming/comments/1lxh8ip/study_finds_that_ai_tools_make_experienced/
  • Tôi từng viết vài bài về đúng chủ đề này rồi. Theo tôi, việc LLM chạy theo điểm benchmark là đi sai hướng nếu nhìn như một công cụ lập trình. Theo kinh nghiệm của tôi, nó sai với xác suất khá cao nên lúc nào cũng phải kiểm tra đầu ra, thành ra thời gian qua lại với LLM kéo dài, mà phản hồi lại chậm, nhiều khi còn thấy tự làm bằng tay sẽ nhanh hơn. Thứ tôi muốn là một agent phản hồi ngay trong vòng 1 giây, dù benchmark chỉ ở mức 60%
  • LLM thật sự giúp tôi nhanh hơn chỉ trong phạm vi như một khái niệm find/replace nâng cao cho code. Ví dụ kiểu prompt yêu cầu thay đổi "logic liên quan đến XXX" ở nhiều chỗ trong code, nó trả lời khá ổn. Giảm được rất nhiều công tìm thủ công rồi sửa từng chỗ một. Tuy nhiên tôi chưa thử với code cực lớn
  • Có lẽ tùy tình huống. Refactor thì IDE hay language server hỗ trợ sẽ nhanh hơn nhiều, còn ngoài ra LLM vẫn hữu ích. Ví dụ hôm qua tôi làm logic chuẩn hóa URL ở mức MVP, mà trong dữ liệu khách hàng có rất nhiều dạng URL lẫn lộn nên có nhiều case kiểm chứng. Tôi đưa các case khách hàng phổ biến nhất vào Claude và nhờ tạo "các test case phủ tối thiểu", chỉ 5~10 giây là có kết quả, rồi từ đó dùng tính năng agent Opus trong Zed để tạo file test, sau khi xem lại các case thì dọn bớt phần không cần thiết và cải thiện logic thêm chút nữa. Cách này nhanh hơn nhiều so với tự làm hết một mình
  • Tôi nghe rất nhiều, cả online lẫn offline, rằng ở công việc cấp senior thì tốc độ tăng 40~60%. Dù vậy vẫn chưa đến mức có thể chỉ tin AI agent rồi lười biếng giao hết mọi thứ cho nó
• Đây là một giai thoại về việc hồi mới vào nghề tôi nổi tiếng là kỹ sư phần mềm tăng tốc hệ thống. Khi đó là thời mà cả kiến thức thuật toán lẫn khả năng đọc đầu ra trình biên dịch đều rất quan trọng, cũng là thời Carmak và Abrash đang trở thành ngôi sao. Năm 22 tuổi, tôi lần đầu tham gia một cuộc họp với khách hàng là một tập đoàn đa quốc gia lớn, và họ chỉ ra rằng tốc độ sản phẩm của chúng tôi là vấn đề. Tôi thực sự bị sốc khi nghe vị VP của công ty đó nói thẳng rằng "nhanh hơn 1 giây tương đương thêm 1 triệu đô lợi nhuận hằng năm cho chúng tôi". Đó là khoảnh khắc quyết định đầu tiên tôi thấy tốc độ được quy đổi trực tiếp ra tiền. Sau 20 năm, đó vẫn là một trong những điểm nhấn lớn nhất sự nghiệp của tôi. Và rồi một kỹ sư khác đùa với vị VP rằng "nếu giảm xuống 0 giây thì có phải kiếm được vô hạn tiền không", cả phòng không ai cười nhưng tôi thì thấy khá buồn cười
  • Từ 1 giây xuống 0 giây, hay từ 2 giây xuống 1 giây, đều tăng thêm 1 triệu đô mỗi lần sao? Lý luận rằng như vậy sẽ thành vô hạn tiền nghe cũng khá lạ
  • Cuối cùng có cải thiện nhanh hơn thật không thì tôi cũng tò mò
• Tôi viết phản hồi này vì đồng cảm với câu đầu của bài blog. Người dùng không trực tiếp yêu cầu lập trình viên "hãy làm cho nó nhanh", nhưng nếu nó không nhanh thì họ cũng sẽ không tin tưởng. Nếu Rust chậm hơn Ruby thì chẳng ai quan tâm. Rust phải được nói là "nhanh hơn C++" thì mới được chú ý. Trên HN cũng vậy, chỉ cần có điểm "nhanh" là mọi người như bị hút vào. Chỉ cần nhanh hơn một chút là được chú ý ngay
  • Đây là kiểu lập luận chỉ hợp với tầng lớp thiểu số lập trình viên viết bài trên HN. Phần lớn lập trình viên hay người dùng phổ thông không quá quan tâm chuyện chậm, miễn UI tiện là được. Ngay cả data scientist chuyên nghiệp cũng dùng Github Desktop gọn gàng nhiều hơn là các command siêu nhanh
  • Có vẻ kết luận này sai. "Nhanh" là điểm khác biệt mạnh khi cung cấp cùng một bộ tính năng mà nhanh hơn. Mọi người đổ xô tới "X nhưng nhanh hơn X", nhưng họ cũng có thể chuyển vì nhiều tính năng hơn, UX tốt hơn, rẻ hơn hay đơn giản là tốt hơn, và vẫn có thể chọn thứ chậm hơn
  • Với ngôn ngữ hay runtime thì tốc độ quan trọng, nhưng khi dùng framework thì các yếu tố khác như tính năng, khả năng tương thích quan trọng hơn. Mọi người vẫn dùng Electron rất nhiều dù nó chậm
  • Thực tế là chúng ta đang sống trong một thế giới mà rất nhiều ứng dụng, đặc biệt là web app, chậm khủng khiếp. Người dùng thao tác gì đó rồi phải đợi vài giây mới có phản hồi là chuyện xảy ra như cơm bữa. Dù ai cũng nói "nhanh là nhất" nhưng thực tế lại ngược lại
  • Lý do người dùng HN thích 'nhanh' là vì chúng ta biết phần lớn công nghệ mình đang dùng hiện nay chậm khủng khiếp, và về bản chất hoàn toàn có thể làm nhanh hơn
• Ngược lại, nếu một thứ "quá" nhanh thì cũng có hiện tượng người ta nghi ngờ không biết nó đã thật sự chạy chưa. Trong trường hợp của TurboTax, việc phân tích thực tế còn chưa đến 1 giây, nhưng khi họ cố tình thêm màn hình loading giả thì người dùng lại tin tưởng và thích hơn. Nhờ vậy, dù thời gian xử lý thật ngắn hơn nhiều, họ vẫn làm cho nó trông chậm đi để tạo cảm giác "đã thật sự xem xét"
• Nhanh còn quan trọng ở khía cạnh chi phí. Trong môi trường cloud tính tiền theo từng giây, nếu không tối ưu mọi quy trình thì không thể cung cấp dịch vụ chép lời toàn công ty với chi phí rẻ được. Ví dụ, image tôi làm ra nhỏ hơn bản open source kế tiếp tới 2.5 lần, nhờ đó cold boot nhanh hơn, chi phí thấp hơn và dịch vụ tốt hơn https://speechischeap.com
  • S3 là chậm hay nhanh? Thực ra là cả hai. Nếu nhìn theo từng request đơn lẻ thì chậm, nhưng nếu bắn song song nhiều request thì lại cho cảm giác nhanh. Cuối cùng, 'nhanh' đôi khi quan trọng để sống còn, đôi khi lại là một kiểu mỹ học
  • Tôi thì ngược lại, chạy dịch vụ trên phần cứng tiêu dùng nên vận hành rẻ hơn cloud rất nhiều. Không cần lo về kích thước image (bare metal nhanh hơn). Tôi đang cung cấp miễn phí dịch vụ chép lời 20 nghìn phút mỗi phút xử lý (với giới hạn 5 giây mỗi request). Tôi cũng đang phát triển các lựa chọn thay thế mã nguồn mở và đa nền tảng liên quan https://geppetto.app https://github.com/Mozilla-Ocho/llamafile/tree/main/whisper.cpp https://github.com/cjpais/whisperfile https://handy.computer Nếu quan tâm tới việc đổi mới dịch vụ chép lời thì rất sẵn lòng kết nối
  • Tôi kỳ vọng các công cụ như PAPER, ít nhất trên Linux, có tổng dung lượng cài đặt dưới 2MB, kể cả tính cả cache. pip đã 10~15MB, pipx còn lớn hơn, uv là 35MB. Tôi đang cố đi theo hướng nhỏ hơn thế
  • Nhanh không có nghĩa là lúc nào cũng nhẹ và hiệu quả. Nhiều khi nó được làm nhanh bằng cách đổ vào rất nhiều phần cứng đắt tiền
• Mỗi khi thấy một bài phàn nàn về chuyển khoản ngân hàng ở Mỹ, tôi lại phải tự nhắc mình rằng ở Anh hay Thụy Sĩ, chuyển khoản gần như xong ngay lập tức. Không hiểu vì sao ở Mỹ lại chậm đến vậy
  • Các ngân hàng địa phương ở Mỹ gần như không có lập trình viên nội bộ, mà phụ thuộc vào "core processor". Vì vậy việc nâng cấp hệ thống rất chậm. Việc áp dụng Faster ACH cũng mất nhiều năm, và các nhóm vận động của ngân hàng địa phương còn yêu cầu trì hoãn vì cho rằng điều đó bất lợi cho họ. Có một bài blog giải thích rất rõ chuyện này https://www.bitsaboutmoney.com/archive/community-banking-and-fintech/
  • ACH chậm là do lịch xử lý và xử lý theo lô (batch). Việc chuyển tiền bản thân có thể xong ngay, nhưng thường được gom lại xử lý vào nửa đêm. Nhờ vậy ở Mỹ Venmo hay Zelle mới phổ biến. Ở Thụy Sĩ, chuyển IBAN cũng chậm, còn thanh toán thời gian thực thì TWINT mới là chủ đạo (theo kiểu quét QR code). BACS ở Anh cũng chậm vì lý do tương tự
  • Ở Mỹ thực ra có hai hệ thống chuyển tiền thời gian thực: RTP và FedNow. Số ngân hàng tham gia đang tăng dần https://real-timepayments.com/Banks-Real-Time-Payments.html Trước đây cũng có thể chuyển tiền tức thì qua mạng thẻ tín dụng nếu trả một khoản phí nhỏ. Tuy nhiên thẻ tín dụng có cơ chế bảo đảm và hoàn tiền khác, và khi có gian lận thì ngân hàng chịu thiệt hại lớn hơn
  • Điều này đôi khi lại có lợi cho người tiêu dùng. Ví dụ khi tiền bị rút khỏi một tài khoản không đủ số dư qua auto-debit, ngân hàng sẽ gửi email cảnh báo vài lần. Nhờ vậy nếu mọi thứ không diễn ra thời gian thực thì người dùng còn có thời gian nhận thông báo rồi tự xử lý, tránh phí phạt hay phụ phí. Vì không phải chuyển tiền tức thì nên ngân hàng có cơ hội báo trước và tôi có thời gian đối phó
  • patio11 có một bài viết khá chi tiết về chủ đề này https://www.bitsaboutmoney.com/archive/the-long-shadow-of-checks/
• Bài viết thú vị và gợi ra nhiều điều để nghĩ. Lúc tốc độ thật sự tạo ra khác biệt về cảm nhận, điều quan trọng không hẳn là throughput thực tế mà là "cảm giác nhanh", tức độ phản hồi UI hay độ trễ đầu vào tạo nên cảm giác dễ chịu. Vì vậy tôi thích Go hơn Rust. Tốc độ biên dịch của Go đủ nhanh tới mức gần như không cần đo nữa. Ngược lại, thứ gì chậm thì dù throughput thực tế cao đến đâu tôi cũng ghét (kiểu startup Java)
  • Ngay cả khi so Go với Rust thì tốc độ biên dịch cũng thật sự rất quan trọng. Bản build Rust có đủ loại dependency lặt vặt nên cấu trúc dự án trở nên giống JavaScript. Go thì số dep tương đối ít hơn nhiều nên tôi thích điểm đó
  • Việc các lập trình viên tranh luận như thế này cũng hay, nhưng điều thật sự quan trọng là "ngôn ngữ nào nhanh hơn đối với người dùng"
• Trái với câu "hiếm khi nghe trong phần mềm rằng 'hãy làm cho nhanh lên'", ở gần như mọi công ty tôi từng làm, tốc độ phản hồi trang và độ trễ đều là ưu tiên hàng đầu. Dù là startup hay tập đoàn lớn, tốc độ và latency đều là mục tiêu quan trọng, và việc sản phẩm nhanh tới đâu, trang hiện ra nhanh thế nào, có độ trễ kỳ lạ nào không, luôn là điều được cân nhắc nghiêm túc
  • Phần lớn công ty tôi từng trải qua trực tiếp (6 trên 8 nơi) hầu như không cho thời gian để tối ưu hiệu năng, nên tôi luôn phải lén làm. Ngay cả những nơi đo latency rồi nói nó quan trọng, trên thực tế vẫn bị tính năng mới lấn át và bị đẩy xuống ưu tiên thấp hơn
  • Nhiều nơi ám ảnh với việc tăng tốc kết quả tìm kiếm, nhưng lại không quá quan tâm đến tốc độ render trang hay kích thước dữ liệu gửi xuống cho người dùng
• Đây là điều tôi lặp đi lặp lại ở nhiều nơi làm việc: phần lớn mọi người đánh giá thấp giá trị thật của tốc độ. Họ chỉ giả định đơn giản là "cùng một workflow nhưng nhanh hơn". Ví dụ, họ nghĩ tăng tốc một thí nghiệm lớn chạy qua đêm cũng không giúp ích bao nhiêu, nhưng nếu có thể tăng tốc thật mạnh thì bạn có thể chạy đi chạy lại nhiều lần ngay trong ban ngày, và từ đó tạo ra năng suất ở một đẳng cấp hoàn toàn khác
  • Mọi người đánh giá cực thấp chi phí chuyển ngữ cảnh. Họ nghĩ một lệnh từ 30 giây xuống 3 giây thì nếu mỗi ngày chạy 10 lần cũng chỉ tiết kiệm có 5 phút, nhưng thực tế chi phí chuyển đổi còn lớn hơn nhiều
  • Mỗi khi CI pipeline mất hàng giờ, tôi lại nghĩ rằng nếu nó xong trong vòng 20 phút thì chắc tôi đã sửa luôn cả những cảnh báo lint vụn vặt ngay lúc đó rồi