Trong một thời gian dài, tôi không chắc trang web này có thực sự cần một blog hay không.
Tôi vốn đã dành phần lớn thời gian làm việc để giải quyết vấn đề. Có những việc frontend hoặc backend khá bình thường. Nhưng cũng có những vấn đề đi vào các ngách rất hẹp: mã hóa hình ảnh, hành vi trình duyệt, thử nghiệm SEO, sự cố hạ tầng, phát triển có AI hỗ trợ, xử lý media, hoặc một lỗi production kỳ lạ bắt đầu từ một câu hỏi đơn giản rồi biến thành nhiều ngày điều tra.
Sau tất cả những việc đó, viết thêm vài nghìn từ có thể cảm thấy không cần thiết.
Ai sẽ đọc nó?
Tôi nhận được gì từ việc này?
Tại sao không giải quyết vấn đề rồi tiếp tục?
Cuối cùng tôi tìm được một câu trả lời đủ thuyết phục với mình: có những phần công việc quá tốn công để đơn giản vứt đi.
Một vấn đề khó có thể chứa cả một bài viết trước khi tôi nhận ra
Các bài của tôi thường không bắt đầu bằng suy nghĩ: “Tuần này mình cần viết một bài blog.”
Chúng bắt đầu bằng một vấn đề.
Đôi khi vấn đề đến từ công việc. Đôi khi từ một dự án cá nhân. Đôi khi tôi chỉ tình cờ quan tâm đến một thứ mình chưa hiểu và tiếp tục đào sâu cho tới khi hiểu nó tốt hơn nhiều.
Xử lý hình ảnh đã tạo ra rất nhiều “hố thỏ” như vậy đối với tôi.
Ban đầu, một nhiệm vụ có thể nghe đơn giản đến mức gần như ngớ ngẩn:
Hãy lấy những hình ảnh này và làm chúng nhỏ hơn.
Bạn có thể yêu cầu một AI model viết script và gần như lập tức nhận được một phiên bản.
Điều đó không có nghĩa là bạn đã có một pipeline xử lý hình ảnh tốt.
Phiên bản đầu tiên có thể bỏ qua sự khác biệt giữa JPEG, PNG, WebP và nội dung động. Nó có thể dùng một mức quality cho mọi thứ. Nó có thể upscale hình ảnh một cách không cần thiết. Nó có thể xử lý transparency kém. Nó có thể giữ lại metadata mà bạn muốn xóa hoặc xóa metadata mà bạn muốn giữ. Nó có thể tối ưu kích thước file mà không đo tổn thất chất lượng hình ảnh. Nó có thể chạy hoàn hảo với mười file test rồi trở thành một sai lầm rất đắt đỏ ở quy mô lớn hơn.
Một script chạy thành công không đồng nghĩa với một hệ thống mà tôi tin tưởng.
Rất nhiều bài viết của tôi xuất phát từ chính sự khác biệt đó.
Workflow AI của tôi chậm hơn rất nhiều so với “hỏi ChatGPT rồi lấy câu trả lời”
Tôi sử dụng tài khoản ChatGPT trả phí rất nhiều khi xử lý những vấn đề kiểu này.
Một cuộc trò chuyện có thể kéo dài nhiều ngày hoặc nhiều tuần. Tôi đặt câu hỏi, thử các đề xuất, gửi kết quả trở lại, chất vấn các giả định, xem code, tìm thêm edge case, thay đổi implementation, chạy lại, so sánh kết quả rồi lặp lại.
Với những cuộc điều tra đặc biệt sâu, tôi từng tích lũy hơn 100 giờ làm việc xoay quanh cùng một vấn đề tổng quát.
Điều đó không có nghĩa là tôi ngồi 100 giờ chờ một AI model kỳ diệu tìm ra đáp án.
Quy trình mang tính lặp.
Một chu trình điển hình thường giống thế này:
- Tôi mô tả vấn đề.
- Model đề xuất giải pháp ban đầu.
- Tôi chạy nó với dữ liệu thật.
- Một thứ gì đó yếu, kém hiệu quả hoặc đơn giản là sai.
- Tôi đưa bằng chứng trở lại cuộc trò chuyện.
- Chúng tôi thay đổi cách tiếp cận.
- Tôi test lại.
- Một edge case khác xuất hiện.
- Lặp lại.
Chu trình này có thể diễn ra rất nhiều lần.
Kết quả hữu ích thường không phải script đầu tiên. Nó là toàn bộ tập hợp các thất bại, phép đo, chỉnh sửa và quyết định tích lũy xung quanh script đó.
AI làm cho việc tạo điểm khởi đầu trở nên rẻ. Nó không làm verification rẻ đi
Đây là một lý do khiến tôi thấy cuộc tranh luận phổ biến về nội dung kỹ thuật do AI viết thường quá đơn giản.
Đúng, một AI model có thể tạo ra một tutorial trông hợp lý cực kỳ nhanh.
Nó cũng có thể tạo ra code trông hoàn toàn hợp lý nhưng lại sai đúng ở những tình huống quan trọng nhất.
Với các vấn đề kỹ thuật hẹp, tôi hiếm khi muốn câu trả lời có vẻ hợp lý đầu tiên. Tôi muốn biết điều gì thực sự xảy ra khi chạy nó.
Nếu đang xây dựng một image pipeline, tôi muốn xem kích thước output và chất lượng hình ảnh. Tôi muốn biết chuyện gì xảy ra với các source format khác nhau. Tôi muốn test kích thước bất thường, alpha, animation và input hỏng. Tôi muốn hiểu implementation đang dựa trên những giả định nào.
Nếu script sau này sẽ áp dụng cho một bộ sưu tập cực lớn, công việc đó càng quan trọng.
Mười triệu hình ảnh là một ví dụ cố tình cực đoan, không phải khẳng định rằng một dataset cụ thể của tôi có mười triệu ảnh. Nhưng nó minh họa vấn đề rất rõ: một lỗi hệ thống nhỏ, khi nhân lên mười triệu lần, không còn là lỗi nhỏ nữa.
Chi phí tạo code đã giảm mạnh.
Chi phí xác định xem code đó có đáng để chạy ở quy mô lớn hay không thì chưa.
Chat là nguyên liệu nghiên cứu, không phải bài viết hoàn chỉnh
Sau một cuộc điều tra dài như vậy, lịch sử chat có thể chứa một lượng thông tin khổng lồ.
Có thể có:
- những cách tiếp cận thất bại;
- code về sau bị thay thế;
- kết quả benchmark hữu ích;
- log;
- những hiểu nhầm;
- các lần sửa;
- giải thích về hành vi khó hiểu;
- so sánh giữa những phương án khác nhau;
- các edge case ban đầu tôi chưa nghĩ tới;
- và những quy tắc cuối cùng tôi quyết định tin dùng.
Để tất cả những thứ đó nằm lại trong một cuộc trò chuyện riêng tư khiến tôi cảm thấy rất lãng phí.
Vì vậy tôi lấy những phần hữu ích và biến chúng thành một bài viết.
Bài viết không phải transcript của cuộc trò chuyện. Phần lớn cuộc trò chuyện không bao giờ nên trở thành bài viết.
Một bài kỹ thuật hữu ích cần thêm một bước: loại bỏ những ngõ cụt không dạy được gì, giữ lại những ngõ cụt giải thích một điều quan trọng, xác minh claim, dựng lại chronology, phân biệt observation với explanation, rồi biến kết quả thành thứ một developer khác thực sự có thể sử dụng.
Bước biên tập đó rất quan trọng.
AI có thể tham gia, nhưng bằng chứng vẫn đến từ công việc thực tế.
Xử lý hình ảnh dạy tôi một vấn đề “đơn giản” có thể sâu đến mức nào
Tối ưu hình ảnh có lẽ là ví dụ rõ nhất trong công việc của tôi.
Tôi đã dành đủ nhiều thời gian cho nó để thứ ban đầu có vẻ chỉ là một nhóm encoder setting dần biến thành một bài toán hệ thống lớn hơn rất nhiều.
Các câu hỏi xuất hiện rất nhanh.
Tôi đang xử lý source format nào?
Nó có animation không?
Có nên thay đổi kích thước không?
Chọn quality thế nào?
Metric nào nên quyết định mức suy giảm chất lượng có chấp nhận được hay không?
Một quality threshold có dùng được cho những hình ảnh rất khác nhau không?
Làm sao tránh upscaling?
Metadata nào cần được giữ lại?
Transparency sẽ được xử lý ra sao?
Output cần được validate như thế nào?
File nhỏ hơn có thực sự đáng với encoding cost bổ sung không?
Điều gì xảy ra khi phân bố input thay đổi?
Đó là lý do tôi hoài nghi những script “tối ưu hình ảnh tối thượng” chỉ dài năm dòng.
Chúng hoàn toàn có thể xử lý được một hình ảnh.
Nhưng điều đó khác với việc xây dựng một pipeline mà bạn hiểu rõ các đánh đổi của nó.
Với các workload hiện tại vốn nặng về hình ảnh, AVIF thường là format đầu tiên tôi muốn cân nhắc. Đó là quy tắc dựa trên loại dự án tôi làm, không phải khẳng định rằng mọi website trên thế giới nên xóa hết các format cũ vào ngày mai. Yêu cầu tương thích, source material, latency, encoder cost và kiến trúc delivery đều có thể thay đổi câu trả lời.
Điều thú vị không phải là tuyên bố một format nào đó chiến thắng.
Điều thú vị là hiểu workload đủ sâu để đưa ra quyết định có chủ ý.
Tôi cũng muốn đào sâu xử lý video đến mức tương tự. Tôi chưa tới đó. Đó là một phần khiến những chủ đề này hấp dẫn: mỗi khi tôi nghĩ mình đã chạm đáy một vấn đề, một lớp khác lại xuất hiện.
Rồi một trang Nhật Bản tìm thấy blog
Tôi không mong đợi một lợi ích cụ thể nào từ việc xuất bản những bài này.
Blog này không mang lại cho tôi lợi nhuận tài chính đáng kể. Tôi làm vì thích quá trình đó và vì muốn giữ lại những công việc hữu ích thay vì để chúng biến mất trong chat cũ hoặc lịch sử terminal.
Rồi một chuyện thực sự nằm ngoài dự đoán của tôi xảy ra.
Ngày 17 tháng 9 năm 2026, trang Levtech Freelance của Nhật xuất bản một bài tổng hợp có thể dịch gần đúng là “Những blog được đề xuất cho kỹ sư muốn nâng cao kỹ năng”.
Bài viết của Levtech Freelance đưa JSVar vào cùng với một số blog kỹ thuật khác.
Levtech là một phần của hệ sinh thái nghề nghiệp IT lớn tại Nhật Bản, còn Levtech Freelance tập trung hỗ trợ và kết nối các kỹ sư IT freelance với dự án. Với tôi, điều thú vị không chỉ là có thêm một backlink. Tôi muốn biết một đội ngũ biên tập bên ngoài đã thấy phần nào trong công việc của tôi đủ đáng để mô tả.
Trong phần viết về JSVar, họ đặc biệt nhắc đến ba bài.
Một bài nói về lý do tôi thấy Codex và TypeScript phối hợp tốt trong phát triển production, đặc biệt vì type và compiler feedback của TypeScript có thể giúp phát hiện sớm lỗi trong generated code.
Một bài khác nói về việc tôi dùng ChatGPT để dịch blog sang 20 ngôn ngữ và sau đó thấy người dùng tìm kiếm từ nhiều quốc gia truy cập trực tiếp vào các trang đã được localized.
Bài thứ ba là thử nghiệm xuất bản 10.000 trang SEO do AI tạo, cuối cùng trở thành câu chuyện về thất bại hơn là tăng trưởng dễ dàng.
Tôi thấy lựa chọn đó khá thú vị vì ba bài rất khác nhau, nhưng chúng có cùng một mẫu.
Chúng dựa trên những việc tôi thực sự đã làm.
Tôi không biết chính xác Levtech đã tìm thấy tôi bằng cách nào
Có một câu chuyện rất hấp dẫn để kể ở đây.
Tôi không biết tiếng Nhật.
Website của tôi có phiên bản tiếng Nhật.
Một ấn phẩm kỹ thuật Nhật Bản tìm thấy website.
Vậy chắc việc dịch blog sang tiếng Nhật đã khiến Levtech tìm thấy nó.
Tôi không thể chứng minh điều đó.
Có thể các trang tiếng Nhật đã giúp.
Có thể search đưa họ tới một bài tiếng Anh.
Có thể ai đó chia sẻ link.
Cũng có thể họ tìm thấy site qua một con đường hoàn toàn khác.
Tôi không có dữ liệu attribution đó, nên tôi sẽ không dựng lên một case study SEO sạch đẹp từ nó.
Điều tôi có thể xác nhận đơn giản hơn nhiều: tôi xuất bản blog bằng nhiều ngôn ngữ, và sau đó một ấn phẩm Nhật Bản thấy nó đủ thú vị để đưa vào một tuyển tập do biên tập viên lựa chọn.
Chỉ riêng điều đó đã là một kết quả tốt.
Nó càng thú vị hơn vì localization cũng từng là một thử nghiệm đòi hỏi nhiều công sức với lợi ích rất khó đoán trước.
Việc được nhắc đến có ý nghĩa vì đó là một dạng xác nhận độc lập
Tôi không dùng từ “xác nhận” theo nghĩa Levtech đã chứng minh mọi thứ tôi viết đều đúng.
Họ không audit codebase của tôi hay tái hiện từng experiment.
Điều có ý nghĩa khiêm tốn hơn nhiều.
Một người ở phía bên kia thế giới, viết cho một nhóm độc giả mà tôi không thể trực tiếp nói chuyện bằng ngôn ngữ của họ, đã thấy đủ giá trị trong công việc của tôi để tóm tắt nó cho độc giả của mình.
Tôi không pitch cho họ.
Tôi không viết những bài ban đầu đó cho Levtech.
Tôi không mong đợi xuất hiện trong một tuyển tập của Nhật.
Chính điều đó khiến kết quả này có ý nghĩa với tôi.
Nó gợi ý rằng một bài kỹ thuật rất hẹp không nhất thiết cần lượng độc giả khổng lồ mới đáng để xuất bản.
Nó chỉ cần hữu ích với đúng người đọc.
Một developer có nên bắt đầu blog vào năm 2026 không?
Với tôi, có — nhưng với một điều kiện quan trọng.
Bạn phải thực sự có điều gì đó muốn viết lại.
Tôi sẽ không khuyên mở blog kỹ thuật chỉ vì ai đó nói mọi developer đều cần một “thương hiệu cá nhân”.
Tôi cũng sẽ không bắt đầu vì kỳ vọng passive income.
Và tôi sẽ không tạo blog chỉ để lấp đầy bằng những giải thích chung chung về các công nghệ vốn đã có documentation tốt hơn.
Nhưng nếu công việc của bạn liên tục tạo ra những điều mà bạn từng ước mình có thể tìm thấy khi mới bắt đầu, thì đó là chuyện khác.
Hãy viết chúng xuống.
Viết về sự cố production kỳ quặc.
Viết về một tối ưu hóa mất lâu hơn dự kiến ba ngày.
Viết về benchmark mâu thuẫn với giả định của bạn.
Viết về cách tiếp cận trông thanh lịch nhưng thất bại.
Viết về implementation cuối cùng, nhưng cũng giải thích tại sao implementation hiển nhiên ban đầu lại chưa đủ.
Đó là những phần khó có thể tạo ra từ kiến thức chung chung.
AI cho tôi nhiều thứ để viết hơn, không phải ít đi
AI không khiến tôi nghĩ blog kỹ thuật đã lỗi thời.
Với tôi, gần như ngược lại.
Tôi có thể điều tra nhiều ý tưởng hơn vì việc có được implementation hoặc explanation ban đầu nhanh hơn trước.
Nhưng iteration nhanh hơn cũng tạo ra nhiều evidence hơn: nhiều phiên bản hơn, nhiều log hơn, nhiều benchmark hơn, nhiều lần thử thất bại hơn và nhiều thứ cần kiểm tra hơn.
Nguyên liệu thô đó chỉ trở nên có giá trị sau khi có người làm công việc quyết định điều gì đúng và điều gì quan trọng.
Một cuộc trò chuyện AI có 500 tin nhắn không tự động trở thành kiến thức.
Một script cuối cùng vượt qua testing thực tế, kèm giải thích vì sao 20 phiên bản trước không làm được, thì có thể.
Đó là sự khác biệt tôi muốn lưu lại trong blog.
Xuất bản là cách tôi ngăn công việc hữu ích biến mất
Phần lớn công việc kỹ thuật tồn tại ngắn hơn ta nghĩ.
Một bug khó được sửa.
Terminal đóng lại.
Deployment thành công.
Cuộc chat trôi xuống lịch sử.
Sáu tháng sau, có thể ngay cả tôi cũng không nhớ tại sao implementation cuối cùng lại có hình dạng như vậy.
Viết thay đổi điều đó.
Nó buộc tôi dựng lại reasoning khi evidence vẫn còn.
Nó tạo ra thứ có thể tìm kiếm.
Nó cho tôi một tài liệu tham khảo cho công việc tương lai của chính mình.
Và đôi khi, dường như nó còn đến được với một người tôi hoàn toàn không ngờ tới — kể cả một ấn phẩm kỹ thuật bằng ngôn ngữ mà tôi không nói được.
Tôi vẫn không có một lý do cầu kỳ để duy trì blog này.
Tôi thích học.
Tôi thích xây dựng mọi thứ.
Tôi thích đi quá sâu vào những vấn đề lúc đầu trông rất đơn giản.
Và sau khi đã bỏ ra hàng chục, đôi khi hơn một trăm giờ để đi tới một câu trả lời hữu ích, tôi không còn muốn câu trả lời đó chết trong một cửa sổ chat.
Với tôi, đó đã là lý do đủ để xuất bản.
Nếu công việc của bạn cũng tạo ra kiểu kiến thức phải rất vất vả mới có được như vậy, có lẽ đó cũng là lý do đủ cho bạn.