Niềm vui và sức mạnh của sự thấu hiểu

 (binaryigor.com)
3 điểm bởi GN⁺ 4 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Khi hiểu sâu về phần mềm, bạn sẽ không bị công cụ dẫn dắt mà có thể có quyền kiểm soát và quyền sở hữu đối với hệ thống mình chịu trách nhiệm
  • Tìm kiếm và LLM cho câu trả lời nhanh, nhưng thói quen sao chép các lời giải không thể tự giải thích có thể làm suy yếu khả năng sửa đổi và năng lực cốt lõi
  • Với script dùng một lần hoặc UI nội bộ rủi ro thấp, việc tạo sinh và copy-paste có thể hợp lý, nhưng mã sẽ được duy trì lâu dài thì phải được xây bằng công nghệ mà bạn thực sự hiểu sâu
  • Nếu chỉ đo năng suất bằng output như số dòng code hay số PR, kết quả rất dễ bị bóp méo; còn outcome như phát hành ổn định, đơn giản hóa, tự động hóa, kiểm thử mới gần với giá trị dài hạn hơn
  • Phần mềm hiện đại đã trở nên phức tạp với runtime, mạng, bảo mật, cơ sở dữ liệu, AI, nhưng nếu nắm được các nguyên lý nền tảng thì bạn sẽ hiểu công cụ và cách tiếp cận mới nhanh hơn

Quyền kiểm soát và niềm vui mà sự thấu hiểu mang lại

  • Hiểu biết sâu là điều kiện thực chất để sửa chữa và thay đổi code cũng như hệ thống
  • Những gì bạn không hiểu thì rất khó chỉnh sửa hoặc thay đổi, và cuối cùng quyền kiểm soát cũng như quyền sở hữu đối với đoạn code bạn chịu trách nhiệm sẽ suy yếu
  • Sự thấu hiểu không chỉ giúp bạn trở thành người làm chủ công cụ mà còn mang lại cảm giác thỏa mãn về mặt tâm lý
  • Việc những hành động giúp ta kiểm soát môi trường tốt hơn gắn với cảm xúc tích cực là điều hoàn toàn tự nhiên

Sự lười biếng của con người và phụ thuộc vào LLM

  • Con người có xu hướng giảm mức tiêu hao năng lượng và tối đa hóa phần thưởng so với công sức bỏ ra
  • Sự lười biếng này là động lực để tự động hóa những công việc nhàm chán và tốn kém, nhưng trong học tập và rèn nghề nó có thể trở thành điểm yếu
  • Nhờ Internet và LLM, ta có thể dễ dàng nhận được câu trả lời cho những vấn đề tương tự theo đúng hình thức mình muốn, nên rất dễ bỏ qua quá trình thấu hiểu
  • Thay vì tự học SQL, chỉ cần đưa bảng và dữ liệu mong muốn cho LLM rồi sao chép kết quả thì trước mắt sẽ dễ hơn, nhưng năng lực xử lý đúng đắn sẽ không được tích lũy
  • Dù LLM có thể tạo SQL nhanh hơn, khả năng đọc và hiểu từng được rèn qua lặp đi lặp lại trong quá khứ sẽ suy giảm nếu không được sử dụng
  • Trong trường hợp tốt nhất, LLM và công cụ tìm kiếm là bộ khuếch đại năng lực (force multiplier), nhưng trước hết bạn phải có nền tảng vững
  • Kỹ năng và kiến thức cốt lõi rất khó duy trì chỉ bằng tìm kiếm, viết prompt và kiểm chứng thủ công; bạn cần tham gia trực tiếp vào quá trình xây dựng và sáng tạo
  • Cần thường xuyên chống lại xu hướng lười biếng của bản thân: đọc tài liệu và mã nguồn, hiểu lý do đằng sau lời giải và trade-off của công cụ, đồng thời tự thiết kế lời giải và thuật toán

Cân bằng giữa năng suất ngắn hạn và sự thấu hiểu dài hạn

  • Không phải mọi đoạn code và mọi lời giải đều cần được hiểu hoàn toàn; có thể đặt tiêu chuẩn khác nhau tùy tình huống
  • Những script dùng một lần có mức độ quan trọng và rủi ro thấp thì việc sao chép hoặc tạo sinh là chấp nhận được
  • Các UI hoặc trang nội bộ chỉ có hai ba người dùng cũng có thể áp dụng cách làm tương tự
  • Đoạn code mà bạn sẽ sở hữu, duy trì và phát triển trong nhiều tháng hoặc nhiều năm thì phải được viết bằng ngôn ngữ và công nghệ mà bạn hiểu sâu
    • Bạn nên hiểu được mọi dòng, mọi từ, mọi ký tự, mọi tùy chọn cấu hình, hoặc ít nhất phải đi theo hướng đó
    • Thay vì tối ưu cho sản lượng cao ngay lúc này, cần tối ưu cho sự thấu hiểu dài hạn, khả năng bảo trì và năng suất về lâu dài
  • Với các trường hợp như MVP hoặc tính năng thử nghiệm trong sản phẩm hiện có, nơi khả năng thành công còn chưa chắc chắn, có thể hạ tiêu chuẩn về chất lượng và mức độ thấu hiểu xuống một chút
  • Những lựa chọn như vậy giống với việc gánh nợ nhận thức
    • Hiện tại bạn có thể di chuyển nhanh hơn
    • Nhưng khi sản phẩm hay tính năng cần hoạt động thực sự hoặc cần sửa đổi, bạn sẽ phải trả nhiều hơn về sau
  • Dù vậy, tối thiểu bạn vẫn phải hiểu và kiểm chứng đủ để có thể tự tin nói rằng “nó hoạt động”
  • Trong một số trường hợp, chiến lược tạo ra trước, kiểm chứng sau rồi viết lại từ đầu có thể là lựa chọn hợp lý

Hiệu ứng lãi kép của tech stack và sự thành thạo

  • Với những ngôn ngữ lập trình, thư viện hay công cụ chỉ dùng thỉnh thoảng, bạn không nhất thiết phải đầu tư quá nhiều thời gian vào việc học sâu và rèn độ thành thạo
  • Nếu có thể kiểm chứng kết quả, đôi khi việc sao chép hoặc tạo sinh những gì chỉ hiểu một phần cũng là điều chấp nhận được
  • Nhưng nếu bỏ qua giai đoạn học hỏi và vật lộn, bạn cũng đang tự làm giảm khả năng trở nên thành thạo và làm việc hiệu quả với công nghệ đó
  • Trong tech stack cốt lõi được dùng thường xuyên, sự thành thạo có thể mang lại phần thưởng gấp hàng trăm, hàng nghìn lần
  • Kiến thức và kỹ năng có hiệu ứng lãi kép
    • Càng biết nhiều, bạn càng có thể tự xây dựng nhanh hơn
    • Bạn cũng có thể tiếp thu kiến thức và kỹ năng mới ngày càng nhanh hơn
    • Năng lực càng tăng, bạn càng dễ nghĩ ra lời giải và ý tưởng mới

Năng suất hướng đến Outcome hơn là Output

  • Cách hiểu và đo năng suất có thể chia lớn thành hướng output và hướng outcome
  • Việc đo output thì dễ và cũng dễ đếm bằng con số
    • Số dòng code đã viết
    • Số PR đã mở và đã merge
    • Số tính năng đã triển khai
    • Số bug đã phát hiện và sửa
    • Số công việc đã hoàn thành
  • Các chỉ số thiên về output rất dễ bị thao túng
    • Có thể viết code dài dòng
    • Có thể tạo thật nhiều PR nhỏ
    • Có thể chia nhỏ công việc một cách nhân tạo
    • Có thể thêm những tính năng vô ích
  • Dù con số tăng lên, cũng khó đảm bảo đó là đúng hướng
    • Nhiều PR hơn không nhất thiết là tốt hơn
    • Codebase lớn hơn cũng không phải lúc nào cũng đáng mong muốn
    • Đôi khi thay vì thêm tính năng, loại bỏ những tính năng không ai dùng lại tốt hơn
  • Ví dụ về cách nhìn theo outcome gắn trực tiếp hơn với giá trị dài hạn
    • Một quy trình CI/CD mới giúp việc phát hành production ổn định hơn
    • Refactor và đơn giản hóa giúp bảo trì và thay đổi trong tương lai dễ hơn
    • Thiết kế lại giải pháp tích hợp giúp thêm đối tác mới nhanh hơn và tiết kiệm tài nguyên tính toán
    • Tăng cường kiểm thử để bắt bug sớm và ngăn hồi quy
    • Bổ sung metric và cảnh báo để phát hiện sớm các vấn đề tiềm ẩn và bug
    • Tự động hóa các thao tác thủ công nhàm chán để tiết kiệm thời gian và giảm khả năng xảy ra lỗi nghiêm trọng
  • Năng suất và sự thấu hiểu dài hạn phù hợp hơn với các chỉ số hướng outcome, và nhiều output hơn không phải lúc nào cũng tốt hơn

Phần mềm ngày càng phức tạp và các nguyên lý nền tảng

  • Định lý cơ bản của kỹ nghệ phần mềm có thể được tóm tắt bằng câu: “Mọi vấn đề trong khoa học máy tính đều có thể được giải bằng một tầng gián tiếp khác, ngoại trừ vấn đề có quá nhiều tầng gián tiếp”
  • Phát triển phần mềm hiện đại rất phức tạp vì có nhiều tầng và nhiều thành phần
    • Runtime và nền tảng: trình duyệt, server, cloud, mobile, desktop, embedded
    • Mạng: HTTP, DNS, TLS, TCP, UDP, IP, WebSockets, WebRTC, cùng các giao thức của cơ sở dữ liệu và message broker
    • Bảo mật, xác thực, phân quyền
    • Hệ điều hành
    • Ảo hóa, container hóa, điều phối kiểu Kubernetes
    • Cơ sở dữ liệu: SQL, NoSQL, local, remote, phân tán
    • Ngôn ngữ lập trình bậc cao và pipeline compiler, interpreter, transpiler
    • Thư viện, framework, package manager
    • API và dịch vụ bên ngoài
    • CI/CD, TDD, BDD, GitOps, IaC, DDD, EDA, Event Sourcing, CQRS, SSR, CSR, Clean Architecture, Hexagonal Architecture, Modular Monolith, Microservices, Microfrontends
    • LLM và AI
  • Cũng có những lý do khiến ta có thể đối phó với sự phức tạp này
    • Nhiều hệ thống được thiết kế quá mức và có thể được đơn giản hóa đáng kể
    • Trong một giai đoạn nhất định, thông thường chỉ cần thành thạo chuyên sâu một phần nhỏ của bức tranh phát triển phần mềm
    • Phần còn lại chỉ cần ở mức nhận biết là đủ
    • Nếu nắm được các mẫu hình và nguyên lý chung phía sau công cụ, đó sẽ là đòn bẩy để học công cụ, cách tiếp cận và công nghệ mới

Phạm vi và tác động của các nguyên lý nền tảng

  • Các nguyên lý nền tảng là những quy tắc, ràng buộc và cơ chế cơ bản, ít thay đổi, nằm bên dưới các công cụ, thư viện, framework, giao thức và thành phần được dùng trong phát triển phần mềm
  • Phạm vi cốt lõi bao gồm nhiều lĩnh vực
    • Kiến trúc máy tính và phần cứng: cấu trúc CPU, thực thi lệnh, phân cấp bộ nhớ, thanh ghi, cache, thiết bị lưu trữ
    • Mã máy, assembly, ngôn ngữ bậc cao: vì sao cần assembler, compiler, interpreter và các trade-off theo từng loại ngôn ngữ
    • Hệ điều hành: process, thread, scheduling, lock, đồng bộ hóa, bộ nhớ ảo, file system, IPC, system call, I/O
    • Thuật toán, cấu trúc dữ liệu, phân tích độ phức tạp
    • Mạng: giao tiếp giữa các máy tính, độ tin cậy, thông lượng, độ trễ, cấu trúc phân tầng
    • Cơ sở dữ liệu và hệ thống dữ liệu: ACID, transaction, isolation level, index, cách lưu trữ, quan hệ, mô hình hóa dữ liệu
    • Thiết kế và kiến trúc phần mềm: tính mô-đun, quản lý phụ thuộc và trách nhiệm, che giấu thông tin, đóng gói, tầng lớp, client-server, event, coupling và cohesion
    • Trạng thái và luồng dữ liệu: tính định danh, nguồn sự thật duy nhất, giải quyết xung đột, cache và memoization, vô hiệu hóa trạng thái, state machine, tính nhất quán và đồng bộ
    • Hệ thống phân tán: định lý CAP, replication, độ trễ, partition, consensus, service discovery, tính nhất quán cuối cùng
    • Đồng thời và song song: lock, đồng bộ hóa, khả năng song song hóa, race condition, deadlock
  • Không cần và cũng có thể không thể làm chủ hết mọi lĩnh vực, nhưng nên đặt mục tiêu biết một ít về từng mảng và trở nên xuất sắc ở một vài mảng đã chọn
  • Khi tập trung vào các nguyên lý nền tảng, theo thời gian bạn sẽ hình thành một meta-skill là trực giác phổ quát
  • Nếu hiểu sâu cách tính toán và máy tính hoạt động khi chạy đơn lẻ hay theo cụm, bạn sẽ ít bị chi phối hơn bởi chi tiết của các công cụ và framework luôn thay đổi
  • Khi đạt tới mức đó, việc học những công cụ đang thịnh hành mới cũng sẽ trở nên dễ hơn rất nhiều

Niềm vui và sức ảnh hưởng của sự thấu hiểu

  • Như lời Leonardo da Vinci: “Niềm vui cao quý nhất là niềm vui của sự thấu hiểu”
  • Trong phát triển phần mềm, sự thấu hiểu không chỉ mang lại niềm vui mà còn đem đến ảnh hưởng thực tiễn và sức mạnh
  • Phạm vi của kỹ nghệ phần mềm là rất rộng, nhưng nếu tập trung vào các nguyên lý nền tảng thì vùng mà bạn có thể xử lý sẽ mở rộng hơn
  • Thái độ liên tục đẩy giới hạn nhận thức hiện tại của bản thân sẽ dẫn tới niềm vui thường xuyên và sức ảnh hưởng ngày càng lớn

Bài viết liên quan

1 bình luận

 
GN⁺ 4 giờ trước
Ý kiến trên Lobste.rs

  • Tôi thực sự thích sắc thái chung của bài blog này
    Dạo này tôi thấy quá thường xuyên những bài kiểu “tôi đã làm ra công cụ nhưng cũng không biết bên trong đang diễn ra chuyện gì”, và tôi đã mệt với bầu không khí coi đó như một điều đáng tự hào

    • Đúng vậy. Sự hiểu biết sâu sắc mới tạo ra lợi thế thực sự và dẫn đến những ý tưởng, góc nhìn mới
      Hơn nữa, bản thân quá trình đó cũng rất thú vị

  • Đây là một bài viết thú vị, và tôi cho rằng xu hướng thúc đẩy mọi người tạo ra những kết quả mà họ không hiểu ở một mức độ nào đó là có chủ ý
    Từ phía các phòng thí nghiệm AI cũng có lý do kinh tế rất rõ ràng. Họ cần người dùng phụ thuộc vào sản phẩm của mình thì mới có thể bắt đầu biện minh cho mức định giá, và làm suy yếu năng lực của người dùng cũng là một cách để làm điều đó
    Tình cờ là hôm nay tôi cũng viết một bài tương tự, cùng chia sẻ tiền đề cốt lõi về niềm vui khi thật sự học và thành thạo một điều gì đó: https://hgrsd.nl/blog/simplicity-agency-and-mastery/

    • Cảm ơn vì đã chia sẻ bài viết. Điểm về tính chủ thể và hiệu ứng quả cầu tuyết đặc biệt hay
      Chúng ta tuyệt đối không được từ bỏ tính chủ thể, và càng biết nhiều, làm được nhiều thì lại càng có thể biết nhiều, làm được nhiều hơn, tạo ra một vòng tuần hoàn tích cực. Đó thực sự là một vòng phản hồi rất đẹp và tích cực

  • Tôi mừng là bài này không bị gắn cái thẻ vibecoding đáng sợ. Thực ra kiểu câu chuyện này đã được nói đi nói lại hàng chục năm rồi, chỉ là ở những phiên bản ngắn hơn và thường càu nhàu hơn
    Phần mềm phức tạp đến mức kinh khủng nên có rất nhiều lối tắt nhận thức, và đến một lúc nào đó chúng còn cần thiết để sinh tồn. Nhưng con người lại có xu hướng lười biếng hơn đúng vào lúc cần phải thận trọng. Máy tính hợp với kiểu mô-đun hóa nghiêm ngặt, còn con người thì không hẳn vậy
    Tôi thích việc bài này nhấn mạnh rằng hiểu biết không chỉ là một “nghĩa vụ”, mà còn là việc hiểu thứ gì đó hoạt động như thế nào thì thú vị đến mức nào. Có lẽ vẫn có những người không thích việc hiểu thế giới, nhưng điều đó quá cốt lõi với tính cách của tôi nên gần như chỉ mang tính lý thuyết. Nếu không có niềm vui đó thì nên suy nghĩ lại trước khi bắt đầu sự nghiệp phần mềm

    • Tôi thấy bài này có thẻ vibecoding
      Giờ gần như bài nào cũng bị gắn thẻ vibecoding, nên có lẽ tốt hơn là đảo ngược cách nghĩ và đưa vào thẻ non-vibecoding. Tức là chỉ gắn thẻ như vậy cho những bài không phải vibecoding hoặc nói về lợi ích của vibecoding, còn lại thì để nguyên. Đáng tiếc là có vẻ đây đang trở thành tiêu chuẩn mới
      Đây là một bài hay, cũng rất “hợp vibe” với cảm xúc của tôi

  • Tôi thật sự thích học hỏi, và bài viết đề cập đến tình huống “tạo ra một thứ mình mới chỉ nắm được một phần, rồi phải dành thêm thời gian để hiểu nó”, cá nhân tôi lại không ghét kiểu nợ nhận thức đó
    Nếu đó là một miền vấn đề tôi quan tâm, tôi sẵn sàng dành thời gian để trả món nợ ấy và đạt được sự hiểu biết. Cuối cùng nó giống như một con đường khác để đi đến cùng một mức độ hiểu biết
    Nó cũng khiến tôi nghĩ tới khái niệm lean startup. Khi có một thứ gì đó nhìn thấy được, ta có thể bắt đầu bằng cách mổ xẻ một đối tượng cụ thể thay vì đoán xem điều gì quan trọng từ một màn hình trống. Không biết nên bắt đầu từ đâu còn tệ hơn, và AI có thể giúp khởi động rất nhanh
    Điều tôi vẫn chưa nghĩ thông là những junior ít kinh nghiệm sẽ phát triển trực giác để nhận ra mùi hôi và phản biện lại nó như thế nào. Cách tôi dùng AI rất lặp đi lặp lại, và tôi đối xử với nó như một kiểu đối thoại Socrates để cải thiện. Nó rất khác với thế giới vibecoding one-shot có thể làm được bằng công cụ hiện nay

    • Về chỗ “những junior ít kinh nghiệm sẽ phát triển trực giác để nhận ra mùi hôi và phản biện lại nó như thế nào”, tôi có những người bạn thân và người nhà mới bước vào ngành từ cuối năm ngoái
      Thực tế thì tôi thấy chuyện này không khác trước quá nhiều. Những người senior hơn sẽ đưa lời khuyên và phản biện, và ở phần lớn công ty công nghệ cũng có review đồng nghiệp. Vì vậy junior không hoàn toàn một mình. Ngược lại, họ vẫn có đủ thời gian để mắc lỗi và thích nghi

  • Tôi thích việc bài viết liệt kê khá nhiều chủ đề nền tảng
    Người đọc rất dễ hình dung đây là một kiểu thủ pháp tu từ như Gish gallop hay parading of horribles, nhưng thực tế tôi nghĩ có hàng chục lý thuyết nền tảng giao cắt nhau trong từng khoảnh khắc của cuộc sống chúng ta
    Máy tính cũng không được lập trình dựa trên một lý thuyết thống nhất duy nhất, mà gần với một sơ đồ bao hàm tập hợp chồng lấn được ghép từ nhiều lý thuyết nhỏ hơn

  • Tôi đã rất thích thú khi đọc kỹ bài này và còn chia sẻ cho vài người bạn
    Khi việc chậm lại ngày càng trở nên khó khăn hơn, tôi cũng đã viết https://writing.tidefield.dev/hello-world-again/#honing-my-focus về việc sẽ công khai cam kết với việc học các nền tảng cơ bản trong năm mới
    Thật vui khi thấy cùng chung một định hướng kiểu “sau năm 2026, tôi sẽ học những thứ nền tảng và không nhanh chóng lỗi mốt…”