45 điểm bởi GN⁺ 2025-12-29 | 3 bình luận | Chia sẻ qua WhatsApp
  • May mắn có vẻ như là một yếu tố bên ngoài không thể kiểm soát, nhưng bằng cách công khai sản phẩm công việc, ta có thể tăng xác suất gặp được những cơ hội tốt
  • Diện tích bề mặt của may mắn (Luck Surface Area) được định nghĩa là tích của mức độ “làm điều gì đó (Doing Things)” và mức độ “cho mọi người biết (Telling People)”
  • Thực hiện công việc và công khai nó là quá trình thiết yếu với các nhà sáng tạo như lập trình viên, nhà thiết kế, v.v., đồng thời là cách thể hiện sự tò mò và chuyên môn của mỗi cá nhân
  • Thay vì chờ đợi một kết quả hoàn hảo, điều quan trọng là cùng chia sẻ quá trình, việc học hỏi và những lần thử sai, vì điều đó có thể truyền cảm hứng cho người khác
  • Công việc được công khai có thể tạo ra những cơ hội ngoài dự kiến như việc làm mới, hợp tác, diễn thuyết, kết nối cộng đồng, và đó không đơn thuần là may mắn mà là kết quả mang tính xác suất do hành động chia sẻ tạo ra

Khái niệm diện tích bề mặt của may mắn

  • May mắn được định nghĩa là “những điều tốt đẹp bất ngờ xảy ra”
    • Ví dụ: thành công của thư viện OSS, được mời tới hội nghị, đề nghị công việc mới, có được khách hàng, tham gia podcast, xây dựng quan hệ trong cộng đồng
  • Theo định nghĩa của Jason Roberts, diện tích bề mặt của may mắn (Luck Surface Area) tỷ lệ với tích giữa “mức độ làm một điều gì đó với đam mê” và “số người được truyền đạt điều đó một cách hiệu quả”
    • Biểu diễn bằng công thức: Luck = [Doing Things] × [Telling People]
    • Làm nhiều hơn và cho nhiều người biết hơn sẽ làm diện tích bề mặt của may mắn lớn hơn

Thực hiện công việc (Doing the work)

  • Trước khi công khai, trước hết cần thực sự làm ra thứ gì đó
    • Lập trình viên, nhà thiết kế, nhà sáng tạo đều là những người về bản chất tạo ra sản phẩm, và đó là nền tảng của may mắn
  • Có hai kiểu người
    1. Đã làm rất nhiều việc nhưng nghĩ rằng công việc của mình không đáng để chia sẻ
    2. Muốn bắt đầu điều gì đó nhưng không thể thực hiện
  • Nhóm đầu tiên có xu hướng đánh giá thấp giá trị của kiến thức mình sở hữu; nếu quan sát những gì được chia sẻ trong cộng đồng, họ sẽ nhận ra rằng mình đã có thể làm được rất nhiều điều
  • Với nhóm thứ hai, điều cần thiết là bắt đầu từ những thứ nhỏ
    • Đừng chờ một ý tưởng hoàn hảo, hãy bắt đầu bằng dự án nhỏ hoặc thử nghiệm nhỏ
    • “Chuyển động tạo ra chuyển động”

Thể hiện sự tò mò và chuyên môn

  • Dự án cá nhân là không gian tuyệt vời để khám phá sự tò mò
    • Ví dụ: tạo máy in hóa đơn in ra GitHub issue, cải tạo nhà kho lắp ghép thành văn phòng, phát triển công cụ vẽ SVG, viết newsletter dài về hạ tầng tài chính
  • Dự án trong công việc là nơi phù hợp để phát huy chuyên môn
    • Có thể chuyển các vấn đề đã giải quyết hoặc những điều học được ở nơi làm việc thành blog, bài thuyết trình, dự án mã nguồn mở
    • Dù chi tiết cụ thể không thể công khai, vẫn có thể chia sẻ khái niệm, bài học, mẫu hình
    • Nếu ghi lại những vấn đề hoặc mẫu hình thú vị trong công việc suốt một tháng, bạn sẽ có rất nhiều ý tưởng để chia sẻ

Công khai (Hitting the publish button)

  • Nhiều người cảm thấy sợ hãi ở bước chia sẻ
    • Lý do có thể là sợ bị chỉ trích, chủ nghĩa hoàn hảo, hoặc ác cảm với marketing
  • Nhưng chia sẻ không phải là tự cao, mà là hành động lan tỏa việc học hỏi, một quá trình truyền cảm hứng và hỗ trợ người khác học tập
  • Nền tảng công khai có thể là Twitter, GitHub, blog, newsletter, YouTube, v.v.; miễn là “không phải trên ổ cứng”
  • Chia sẻ là một kỹ năng cần học, và điều quan trọng là không chỉ chia sẻ thành phẩm mà còn cả quá trình tiến triển, thất bại và cách tư duy
    • Ban đầu có thể gượng gạo, nhưng nếu duy trì thì sẽ trở nên tự nhiên

Nắm bắt may mắn (Capturing the luck)

  • Khi công khai công việc, khả năng xuất hiện những kết quả tích cực ngoài mong đợi sẽ tăng lên
    • Ví dụ: được nhìn nhận là chuyên gia về một chủ đề cụ thể, nhận phản hồi từ độc giả, có lời mời việc làm, khách hàng liên hệ, được mời diễn thuyết, xây dựng quan hệ trong cộng đồng, tăng độ nhận biết cho dự án OSS
  • Đây đều là những trường hợp tác giả đã thực sự trải qua, và là kết quả của việc mở rộng diện tích bề mặt của may mắn thông qua chia sẻ
  • Công thức cốt lõi rất đơn giản
    • Do the work. Tell people.
    • Đào sâu sự tò mò và chuyên môn, rồi công khai chia sẻ những gì mình đã học được
  • Không thể tránh hoàn toàn những lời chỉ trích trên mạng, nhưng sẽ có nhiều người âm thầm ủng hộ bạn hơn rất nhiều so với số người chỉ trích
    • Và cuối cùng, một trong số họ có thể mang đến cơ hội làm thay đổi cuộc đời

3 bình luận

 
wedding 2025-12-29

Một trong những điều tôi luôn nhấn mạnh với các bạn junior là
'Hãy sắp xếp gọn gàng những gì mình đã giải quyết được và để lại dưới dạng một bài đăng công khai.'

Trước hết, trong lúc sắp xếp lại, bạn sẽ rà soát lại toàn bộ quá trình một lần nữa nên rất dễ ôn lại,
và dù gặp lại đúng vấn đề đó thì chỉ cần tìm trên Google là bài viết của chính tôi hiện ra nên có thể xử lý rất nhanh (cảm ơn tôi của quá khứ!)
Ngoài ra, vì có thể giúp được ai đó nên danh tiếng của bạn cũng có thể tăng lên.

 
GN⁺ 2025-12-29
Ý kiến trên Hacker News
  • Là người đã làm việc trong ngành mã nguồn mở (OSS), tôi thực lòng mong dự án GitHub của mình đừng trở nên nổi tiếng
    Tôi có vài dự án thử nghiệm được hơn 50 sao, và may là chúng không phát triển thành OSS “thực thụ”
    Tôi từng mất cả cuối tuần vì các yêu cầu sửa lỗi trên những dự án cũ hoặc phải review PR mà mình chẳng còn hứng thú
    Bảo trì OSS gần như là một công việc bán thời gian không lương. Danh tiếng cũng có hạn, và ngay cả các lập trình viên OSS rất giỏi cũng thường khó tìm được công việc xứng đáng trong ngành
    Tôi nghĩ những người bảo trì OSS là kiểu thánh nhân đang gánh đỡ phần mềm của cả thế giới

    • Tôi cũng làm OSS lâu năm, và ước gì có một khoảng trung gian được chấp nhận rộng rãi hơn giữa “không còn bảo trì” và “bỏ cả sinh nhật con để review PR”
      Sẽ hay nếu README trên GitHub có thêm các huy hiệu trạng thái như “hoan nghênh PR”, “chỉ sửa lỗi bảo mật/lỗi nghiêm trọng”, “đang tìm maintainer mới”
    • Văn hóa mã nguồn mở đã thay đổi rất nhiều trong vài chục năm qua. Giờ số người dùng nhiều hơn người đóng góp rất nhiều, và maintainer bị đẩy vào vai trò hỗ trợ như kỹ sư sản phẩm thương mại
      Vì thế dạo này mới nảy sinh câu hỏi “tại sao mình phải ký vào kiểu khế ước xã hội này?”
      Một lựa chọn thay thế là vận hành dự án tự chủ thông qua cộng đồng Git tự host. Cách này không biến công sức của maintainer thành hàng hóa, và có thể khiến mã nguồn mở vui trở lại
    • GitHub đang ở vị thế có thể cải thiện cuộc sống của maintainer OSS, nên khá tiếc là họ không chủ động hơn trong việc giải quyết vấn đề
      Ví dụ, nếu một PR gửi tới kho đã 5 năm không đụng đến, họ có thể tự động cung cấp bản tóm tắt review mã, hoặc đưa vào tính năng lọc các bình luận khiếm nhã
    • Gần đây tôi cũng đã chuyển vài thư viện sang chế độ riêng tư vì kiệt sức trong việc bảo trì. Những người dùng đầy cảm giác đòi hỏi quyền lợi kiểu “gọi quản lý ra đây cho tôi” đã phá hỏng trải nghiệm
    • Tôi vừa bắt đầu một dự án OSS mới, sẽ để mặc định là mã nguồn mở và thêm tùy chọn enterprise
      Nếu không công khai mã thì rất khó xây dựng niềm tin của cộng đồng, và kiểu tiếp cận “để lại email để nhận PDF whitepaper” không còn hiệu quả vào năm 2025
      100% của 0 đô vẫn là 0, nhưng 0,001% của một thị trường khổng lồ vẫn là cơ hội khá lớn
  • Nhìn vào trọng tâm bài này thì rốt cuộc vẫn là cấu trúc mà ai đó khác (thường là doanh nghiệp) hưởng lợi nhiều nhất từ việc công khai mã nguồn
    Đó cũng là lý do GitHub (=Microsoft) dễ bị nhìn như một cỗ máy hút lao động miễn phí
    Nếu là một bài viết cân bằng hơn thì lẽ ra phải cảnh báo về xung đột lợi ích này

    • Tôi cũng nghĩ vậy. Lời khuyên của nhà đầu tư kiểu “ra mắt nhanh dù chưa hoàn hảo” nghe cũng giống một lời khuyên nguy hiểm. Họ có nhiều nguồn lực, cần thì cứ sao chép thôi
    • (Tác giả) Tôi là người viết bài đó. Dự án OSS của tôi thành công và cuộc đời tôi đã thay đổi, dù tất nhiên không phải ai cũng vậy
    • Tôi mong thế hệ trẻ hiểu lại vì sao chúng ta tạo ra GPL
      Doanh nghiệp rất thích sức lao động miễn phí của chúng ta, nhưng lại không tuyển dụng. Kiểu “cảm ơn nhé, chúng tôi dùng rất tốt, nhưng không thuê đâu”
      Giờ thì mã của chúng ta còn bị hấp thụ làm dữ liệu huấn luyện cho LLM mà đến tên cũng chẳng còn
  • Tôi có cảm giác như đang ném bài viết xuống biển rồi không nghe thấy bất kỳ phản hồi nào
    Nền tảng cứ thì thầm “đăng thêm lần nữa là sẽ thành công thôi”, nhưng tôi ngày càng hoài nghi liệu có thật vậy không

    • Nghe các buổi phỏng vấn trên Startups for the Rest of Us thì sự bền bỉ mới là cốt lõi
      Có người thành công sau 3 năm nhờ marketing dựa trên sản phẩm, có người khác xây dựng độc giả qua blog suốt 5 năm rồi mới kiếm tiền từ OSS
      Rốt cuộc câu “tăng vận may” gần như chỉ là khẩu hiệu tạo động lực, còn thực tế thì cần tối thiểu 5–6 năm nỗ lực bền bỉ
    • Giờ chúng ta đang dần trở thành những kẻ sản xuất nội dung ma cho LLM
      Bài viết của chúng ta bị hút vào dữ liệu huấn luyện của doanh nghiệp, độc giả trả tiền cho doanh nghiệp đó, còn chúng ta thậm chí chẳng nhận được một lời cảm ơn
      Ngoại lệ duy nhất là các cộng đồng đóng nơi con người vẫn có thể giao tiếp trực tiếp với nhau
    • Mỉa mai nhất là đôi khi một bài viết viết ra không kỳ vọng gì lại bùng nổ ngoài dự kiến, còn bài đầu tư công sức thì lại chìm nghỉm
    • (Đùa) Thế cậu có đăng kèm video nhảy TikTok với bài đó không?
    • Xin chào, đồng loại con người
  • Tôi cũng rất đồng cảm với bài này
    Nhờ OSS mà tôi nhận được lời mời từ nhiều công ty không cần CV hay bài test code
    Có lần tôi cùng debug lỗi với bộ phận hỗ trợ khách hàng của GitHub rồi được một MD của Microsoft giới thiệu, Cloudflare cũng từng có chuyện tương tự
    Suy cho cùng, OSS là công cụ để tạo ra mạng lưới dựa trên sự tin cậy

    • Đúng vậy, cuối cùng thì đây là câu chuyện về hiệu ứng mạng lưới. Tôi cũng gần như chưa từng nộp đơn xin việc chính thức nào suốt 25 năm
      Viết sách, ký tặng ở hội nghị, rồi cơ hội tự nhiên xuất hiện
  • Theo tôi, các bước của mã nguồn mở là thế này
    1. Tìm ra điểm đau trong công việc của mình
    2. Tạo ra công cụ giải quyết vấn đề đó
    3. Chia sẻ một cách tự nhiên trên Reddit, HN, Bluesky, v.v.
    Mã nguồn mở là phương tiện phát tín hiệu. Nếu thuận lợi, nó trở thành danh thiếp và dẫn tới cơ hội tư vấn hoặc tuyển dụng
    Ví dụ, tháng 4/2023 tôi thấy LangChain rồi làm ra Langroid LLM agent framework,
    và hiện cũng đang duy trì bộ công cụ CLI Claude Code Tools.
    Quá trình đó khiến mã nguồn mở trở thành một cách tích lũy uy tín tương tự xuất bản học thuật

  • (Châm biếm) “Xin chào, hỡi những nông nô mã nguồn mở! Hãy cung cấp thêm dữ liệu để AI của chúng tôi có thể thay thế công việc của các bạn!”

    • “99% lập trình viên mã nguồn mở bỏ cuộc ngay trước khi viral! Nên làm ơn đăng thêm dữ liệu huấn luyện… à không, thêm code đi!”
    • (Tác giả) Tôi không phải nhân viên GitHub. Tôi chỉ là người muốn chia sẻ trải nghiệm cá nhân của mình thôi
    • Có lẽ ngay cả repo riêng tư cũng đang bị dùng để huấn luyện
  • Tôi đã viết vài cuốn sách toán, và dù vận may có tăng đôi chút thì 1200 giờ lao động vẫn không được trả nổi ngay cả ở mức lương tối thiểu

    • Và đó chính là bản chất của “may mắn”. Thử càng nhiều thì xác suất càng tăng, nhưng không có gì đảm bảo cả
    • Tôi cũng là người đóng góp OSS rất tích cực, nhưng nó không chuyển hóa thành phần thưởng nghề nghiệp
  • Tôi cũng đã nhiều lần có được công việc tốt nhờ công khai thứ gì đó. Không giàu lên, nhưng rất có ích cho sự nghiệp

    • (Hài hước) Wow, cảm ơn lần nữa vì Beej’s Guide to Networking!
    • Tôi cũng có trải nghiệm tương tự
  • (Tác giả) Tôi viết bài này từ vài năm trước, giờ thấy nó xuất hiện lại trên HN cũng vui
    Chuỗi thảo luận khi đó cũng đã có những tranh luận tương tự
    Nhiều người nói đây là “bài viết để nuôi máy”, nhưng bài này đã thay đổi cuộc đời tôi. Tôi mong nó cũng giúp được người khác

    • Xin lỗi nhưng tôi nghĩ bài đó hoàn toàn nhảm nhí. Thứ thực sự có giá trị chỉ xuất hiện khi bạn làm ra tác phẩm đẳng cấp hàng đầu
  • Chức danh của tác giả là “Aaron Francis, Marketing Engineer”, nghe như thể giờ marketing cũng được gọi là engineering vậy

    • Thực ra trong nhiều lĩnh vực, các chức danh như sales engineer đã có từ lâu rồi. Đó là vai trò đưa ra tư vấn kỹ thuật
    • (Tác giả) Khi đó tôi là lập trình viên đảm nhiệm vai trò marketing. Cứ hỏi thoải mái
    • Cũng có thể xem đây là phiên bản tiến hóa của “DevRel”. Khi một kỹ sư thuần túy chuyển sang marketing, cách gọi này giúp giữ lại bản sắc nên tôi khá thích
      Hồ sơ GitHub của tôi
    • Giống như “full-stack engineer”, giờ là thời đại mà ý nghĩa của từ ngữ đã được mở rộng
 
roxie 2026-01-01

> Luck = [Doing Things] × [Telling People]

Hình như tôi cũng đã thấy công thức này từ vài năm trước, nhưng suốt thời gian qua lại không thực hành được tốt.