یک وبلاگ فنی را بدون برنامه درآمدزایی شروع کردم؛ بعد یک سایت مهندسی ژاپنی آن را پیدا کرد

مدت زیادی حتی مطمئن نبودم که این وب‌سایت اصلاً به وبلاگ نیاز دارد.

بخش عمده زمان کاری من همین حالا هم صرف حل مسئله می‌شود. بعضی مسائل، کارهای عادی frontend یا backend هستند. بعضی دیگر بسیار خاص می‌شوند: کدگذاری تصویر، رفتار مرورگر، آزمایش‌های SEO، خرابی‌های زیرساخت، توسعه با کمک AI، پردازش رسانه یا یک مشکل عجیب در production که با یک سؤال ساده شروع می‌شود و چند روز تحقیق را به دنبال دارد.

بعد از همه این‌ها، نوشتن چند هزار کلمه دیگر ممکن است غیرضروری به نظر برسد.

چه کسی قرار است آن را بخواند؟

من چه چیزی از آن به دست می‌آورم؟

چرا مسئله را حل نکنم و سراغ کار بعدی نروم؟

در نهایت به جوابی رسیدم که برای خودم کافی بود: بخشی از این کار بیش از آن ارزش دارد که دور ریخته شود.

یک مسئله سخت ممکن است پیش از آنکه متوجه شوم یک مقاله کامل درون خود داشته باشد

مقاله‌های من معمولاً با این فکر شروع نمی‌شوند که «این هفته باید یک پست وبلاگ بنویسم».

با یک مسئله شروع می‌شوند.

گاهی از کارم می‌آید، گاهی از یکی از پروژه‌های شخصی‌ام. گاهی هم چیزی که نمی‌فهمم برایم جالب می‌شود و آن‌قدر دنبالش می‌کنم تا درک بسیار عمیق‌تری پیدا کنم.

پردازش تصویر بارها مرا وارد چنین مسیرهای عمیقی کرده است.

در ابتدا ممکن است کار تقریباً خنده‌دار ساده به نظر برسد:

این تصاویر را بگیر و حجمشان را کمتر کن.

می‌توانید از یک مدل AI یک اسکریپت بخواهید و تقریباً بلافاصله یکی تحویل بگیرید.

اما این به معنی داشتن یک pipeline خوب برای پردازش تصویر نیست.

نسخه اول ممکن است تفاوت JPEG، PNG، WebP و محتوای متحرک را نادیده بگیرد. ممکن است برای همه چیز یک مقدار quality استفاده کند، تصاویر را بی‌دلیل upscale کند، شفافیت را بد مدیریت کند، metadataای را که باید حذف می‌شد نگه دارد یا metadataای را که باید می‌ماند از بین ببرد. ممکن است فقط حجم فایل را کم کند بدون اینکه آسیب بصری را بسنجد. حتی ممکن است روی ده فایل آزمایشی بی‌نقص کار کند و در مقیاس بسیار بزرگ‌تر به اشتباهی بسیار پرهزینه تبدیل شود.

اسکریپتی که بدون خطا اجرا می‌شود همان سیستمی نیست که من به آن اعتماد می‌کنم.

بسیاری از مقاله‌های من دقیقاً از همین تفاوت شکل می‌گیرند.

workflow من با AI بسیار کندتر از «جواب را از ChatGPT بپرس» است

برای حل چنین مسائلی از حساب پولی ChatGPT به‌شدت استفاده می‌کنم.

یک گفت‌وگو ممکن است روزها یا هفته‌ها ادامه داشته باشد. سؤال می‌پرسم، پیشنهادها را آزمایش می‌کنم، نتایج را برمی‌گردانم، فرض‌ها را زیر سؤال می‌برم، کد را بررسی می‌کنم، edge case تازه‌ای پیدا می‌کنم، implementation را تغییر می‌دهم، دوباره اجرا می‌کنم، نتیجه را مقایسه می‌کنم و این چرخه را ادامه می‌دهم.

در بعضی بررسی‌های بسیار عمیق، برای یک مسئله کلی بیش از ۱۰۰ ساعت کار جمع کرده‌ام.

این به آن معنا نیست که ۱۰۰ ساعت منتظر می‌مانم تا یک مدل AI به‌صورت جادویی جواب را کشف کند.

فرآیند تکرارشونده است.

روند معمول بیشتر شبیه این است:

1. مسئله را توضیح می‌دهم.
2. مدل یک راه‌حل اولیه پیشنهاد می‌کند.
3. آن را روی داده واقعی اجرا می‌کنم.
4. بخشی ضعیف، ناکارآمد یا کاملاً اشتباه است.
5. شواهد را به گفت‌وگو برمی‌گردانم.
6. رویکرد را تغییر می‌دهیم.
7. دوباره تست می‌کنم.
8. یک edge case دیگر ظاهر می‌شود.
9. تکرار.

این چرخه ممکن است بارها تکرار شود.

نتیجه مفید اغلب اولین اسکریپت نیست؛ مجموعه شکست‌ها، اندازه‌گیری‌ها، اصلاح‌ها و تصمیم‌هایی است که پیرامون آن شکل گرفته‌اند.

AI تولید نقطه شروع را ارزان کرد، اما verification را ارزان نکرد

این یکی از دلایلی است که بحث رایج درباره محتوای فنی نوشته‌شده با AI را بیش از حد ساده می‌دانم.

بله، یک مدل AI می‌تواند خیلی سریع یک tutorial قابل‌قبول تولید کند.

همان مدل می‌تواند کدی تولید کند که کاملاً منطقی به نظر می‌رسد اما دقیقاً در موقعیت‌هایی اشتباه است که اهمیت دارند.

در مسائل فنی محدود، به‌ندرت اولین جواب قابل‌قبول را می‌خواهم. می‌خواهم ببینم وقتی واقعاً آن را اجرا می‌کنم چه اتفاقی می‌افتد.

اگر در حال ساخت یک image pipeline باشم، می‌خواهم اندازه خروجی و کیفیت بصری را بررسی کنم. می‌خواهم بدانم با فرمت‌های مختلف منبع چه می‌شود. می‌خواهم ابعاد غیرمعمول، alpha، animation و ورودی خراب را آزمایش کنم. همچنین می‌خواهم بفهمم implementation روی چه فرض‌هایی بنا شده است.

اگر اسکریپت قرار است در نهایت یک مجموعه عظیم را پردازش کند، این کار مهم‌تر می‌شود.

ده میلیون تصویر عمداً یک مثال افراطی است، نه ادعایی درباره اندازه یکی از datasetهای من. اما مسئله را خوب نشان می‌دهد: یک خطای سیستماتیک کوچک که ده میلیون بار تکرار شود دیگر کوچک نیست.

هزینه تولید کد به‌شدت کاهش یافته است.

هزینه تشخیص اینکه آیا آن کد شایسته اجرا در مقیاس بزرگ هست یا نه، کاهش مشابهی نداشته است.

چت ماده پژوهشی است، نه مقاله نهایی

بعد از چنین بررسی طولانی‌ای، تاریخچه چت می‌تواند مقدار عجیبی اطلاعات داشته باشد.

از جمله:

• رویکردهایی که شکست خوردند؛
• کدی که بعداً جایگزین شد؛
• نتایج benchmark مفید؛
• logها؛
• برداشت‌های اشتباه؛
• اصلاح‌ها؛
• توضیح رفتارهای مبهم؛
• مقایسه گزینه‌ها؛
• edge caseهایی که ابتدا به ذهنم نرسیده بودند؛
• و قواعد نهایی‌ای که در نهایت به آن‌ها اعتماد کردم.

رها کردن همه این موارد در یک گفت‌وگوی خصوصی برایم هدر دادن کار است.

بنابراین بخش‌های مفید را بیرون می‌کشم و به مقاله تبدیل می‌کنم.

مقاله transcript گفت‌وگو نیست. بیشتر گفت‌وگو اصولاً نباید به مقاله تبدیل شود.

یک مقاله فنی مفید به یک مرحله دیگر نیاز دارد: بن‌بست‌هایی که چیزی یاد نمی‌دهند حذف شوند، بن‌بست‌هایی که نکته مهمی را روشن می‌کنند بمانند، ادعاها بررسی شوند، ترتیب زمانی بازسازی شود، مشاهده از توضیح جدا شود و نتیجه به چیزی تبدیل شود که یک توسعه‌دهنده دیگر واقعاً بتواند استفاده کند.

این مرحله ویرایشی مهم است.

AI می‌تواند در آن کمک کند، اما شواهد همچنان از کار واقعی می‌آیند.

پردازش تصویر به من نشان داد یک مسئله «ساده» تا چه حد می‌تواند عمیق شود

بهینه‌سازی تصویر احتمالاً واضح‌ترین نمونه در کار خودم است.

آن‌قدر روی آن وقت گذاشته‌ام که چیزی که ابتدا مجموعه‌ای از تنظیمات encoder بود، کم‌کم به یک مسئله بسیار بزرگ‌تر در سطح سیستم تبدیل شد.

سؤال‌ها خیلی سریع عوض می‌شوند.

فرمت منبع چیست؟

متحرک است؟

ابعاد باید تغییر کند؟

کیفیت را چگونه انتخاب کنم؟

چه metricی تعیین کند افت کیفیت قابل‌قبول است؟

آیا یک quality threshold برای تصاویر کاملاً متفاوت جواب می‌دهد؟

چطور از upscaling جلوگیری کنم؟

کدام metadata باید حفظ شود؟

شفافیت چه می‌شود؟

خروجی را چگونه باید validate کرد؟

آیا فایل کوچک‌تر واقعاً هزینه اضافی encoding را توجیه می‌کند؟

اگر مجموعه ورودی تغییر کند چه می‌شود؟

به همین دلیل نسبت به اسکریپت‌های پنج‌خطی «بهینه‌سازی نهایی تصویر» بدبینم.

این اسکریپت‌ها قطعاً می‌توانند یک تصویر را پردازش کنند.

اما این با ساخت pipelineای که مصالحه‌هایش را می‌فهمید فرق دارد.

برای workloadهای فعلی من که تصویرمحور هستند، AVIF معمولاً اولین فرمتی است که به آن فکر می‌کنم. این یک قاعده بر اساس نوع پروژه‌های خودم است، نه ادعایی مبنی بر اینکه همه وب‌سایت‌های دنیا باید فردا تمام فرمت‌های قدیمی را حذف کنند. الزامات سازگاری، منبع، latency، هزینه encoder و معماری delivery می‌توانند پاسخ را تغییر دهند.

بخش جالب اعلام برنده شدن یک فرمت نیست.

بخش جالب این است که workload را آن‌قدر خوب بفهمیم که آگاهانه تصمیم بگیریم.

می‌خواهم به همان عمق وارد پردازش ویدئو هم بشوم. هنوز به آنجا نرسیده‌ام. همین موضوع این حوزه‌ها را جالب می‌کند: هر بار فکر می‌کنم به ته یک مسئله رسیده‌ام، لایه دیگری ظاهر می‌شود.

بعد یک سایت ژاپنی وبلاگ را پیدا کرد

از انتشار این مقاله‌ها انتظار نتیجه خاصی نداشتم.

این وبلاگ برای من بازده مالی معناداری ندارد. آن را ادامه می‌دهم چون خود فرآیند را دوست دارم و ترجیح می‌دهم کار مفید را حفظ کنم تا اینکه در چت‌های قدیمی و تاریخچه ترمینال ناپدید شود.

بعد اتفاقی افتاد که واقعاً انتظارش را نداشتم.

در ۱۷ سپتامبر ۲۰۲۶، سایت ژاپنی Levtech Freelance مطلبی منتشر کرد با عنوانی تقریباً معادل «وبلاگ‌های پیشنهادی برای مهندسانی که می‌خواهند مهارت‌هایشان را ارتقا دهند».

مقاله Levtech Freelance در کنار چند وبلاگ مهندسی دیگر، JSVar را هم معرفی کرد.

Levtech بخشی از یک اکوسیستم بزرگ ژاپنی در حوزه مشاغل IT است و Levtech Freelance روی پشتیبانی و تطبیق مهندسان freelance IT با فرصت‌های کاری تمرکز دارد. برای من بخش جالب صرفاً گرفتن یک backlink نبود. جالب‌تر این بود که ببینم یک تیم تحریریه بیرونی کدام بخش‌های کارم را شایسته معرفی دانسته است.

در بخش مربوط به JSVar سه مقاله را به‌طور خاص برجسته کردند.

یکی درباره این بود که چرا در توسعه production، Codex و TypeScript را ترکیب خوبی دیدم، مخصوصاً چون typeها و بازخورد compiler در TypeScript می‌توانند مشکلات کد تولیدشده را زودتر آشکار کنند.

دیگری درباره ترجمه وبلاگ به ۲۰ زبان با ChatGPT و مشاهده کاربران جست‌وجو بود که از کشورهای مختلف مستقیماً وارد صفحات محلی‌شده می‌شدند.

سومی آزمایش من در انتشار ۱۰,۰۰۰ صفحه SEO تولیدشده با AI بود که در نهایت بیشتر به داستان شکست تبدیل شد تا رشد آسان.

این انتخاب برایم جالب بود، چون سه مقاله بسیار متفاوت‌اند اما یک الگوی مشترک دارند.

هر سه بر کاری بنا شده‌اند که واقعاً انجام داده‌ام.

دقیقاً نمی‌دانم Levtech چگونه مرا پیدا کرد

اینجا یک روایت بسیار وسوسه‌کننده وجود دارد.

من ژاپنی بلد نیستم.

سایتم نسخه ژاپنی دارد.

یک نشریه مهندسی ژاپنی سایت را پیدا کرده است.

پس ترجمه وبلاگ به ژاپنی باعث شده Levtech آن را کشف کند.

نمی‌توانم این را ثابت کنم.

شاید صفحات ژاپنی کمک کرده‌اند.

شاید جست‌وجو آن‌ها را به یک مقاله انگلیسی رسانده باشد.

شاید کسی لینکی را به اشتراک گذاشته باشد.

شاید هم از مسیری کاملاً متفاوت به سایت رسیده باشند.

داده attribution ندارم، بنابراین نمی‌خواهم از آن یک case study تمیز SEO بسازم که شواهد پشتیبانش نیست.

چیزی که می‌توانم تأیید کنم بسیار ساده‌تر است: وبلاگ را به چند زبان منتشر کردم و بعد یک نشریه ژاپنی آن را آن‌قدر جالب دید که در یک انتخاب تحریریه قرار دهد.

همین نتیجه به‌تنهایی خوب است.

به‌خصوص به این دلیل که localization نیز آزمایشی بود که در ابتدا کار زیاد با نتیجه نامطمئن به نظر می‌رسید.

این معرفی مهم بود چون نوعی تأیید مستقل بود

منظورم از «تأیید» این نیست که Levtech ثابت کرده همه چیزهایی که می‌نویسم درست هستند.

آن‌ها codebase مرا audit نکردند و همه آزمایش‌ها را دوباره اجرا نکردند.

موضوع مهم، ساده‌تر از این بود.

کسی در آن سوی دنیا، برای مخاطبانی که خودم نمی‌توانم به زبانشان با آن‌ها صحبت کنم، آن‌قدر در کار ارزش دیده بود که برای خوانندگانش خلاصه‌اش کند.

من چیزی برایشان pitch نکردم.

مقاله‌های اصلی را برای Levtech ننوشته بودم.

انتظار حضور در یک فهرست ژاپنی را هم نداشتم.

همین موضوع نتیجه را برای من معنادار می‌کند.

نشان می‌دهد یک مقاله فنی بسیار خاص لزوماً به مخاطب عظیمی نیاز ندارد تا ارزش انتشار داشته باشد.

کافی است برای خواننده درست مفید باشد.

آیا یک توسعه‌دهنده باید در ۲۰۲۶ وبلاگ راه بیندازد؟

برای من، بله — با یک شرط مهم.

واقعاً باید چیزی داشته باشید که بخواهید ثبتش کنید.

من توصیه نمی‌کنم فقط چون کسی گفته هر توسعه‌دهنده‌ای به «برند شخصی» نیاز دارد وبلاگ فنی بسازید.

برای انتظار درآمد منفعل هم شروعش نمی‌کردم.

و صرفاً برای پر کردن آن با توضیح‌های عمومی درباره فناوری‌هایی که مستندات بهتری دارند هم وبلاگ نمی‌ساختم.

اما اگر کارتان مرتب چیزهایی تولید می‌کند که آرزو می‌کردید هنگام شروع خودتان پیدا می‌کردید، موضوع فرق دارد.

آن‌ها را بنویسید.

از خرابی عجیب production بنویسید.

از بهینه‌سازی‌ای بنویسید که سه روز بیشتر از انتظار طول کشید.

از benchmarkی بنویسید که فرض شما را نقض کرد.

از رویکردی بنویسید که زیبا به نظر می‌رسید اما شکست خورد.

از implementation نهایی بنویسید، اما توضیح دهید چرا implementation واضح کافی نبود.

این‌ها بخش‌هایی هستند که ساختنشان از دانش عمومی دشوار است.

AI به من موضوع بیشتری برای نوشتن می‌دهد، نه کمتر

AI باعث نشده فکر کنم وبلاگ‌های فنی منسوخ شده‌اند.

برای من تقریباً برعکس بوده است.

می‌توانم ایده‌های بیشتری را بررسی کنم چون رسیدن به implementation یا توضیح اولیه سریع‌تر از قبل شده است.

اما iteration سریع‌تر شواهد بیشتری هم تولید می‌کند: variantهای بیشتر، logهای بیشتر، benchmarkهای بیشتر، تلاش‌های ناموفق بیشتر و چیزهای بیشتری که باید بررسی شوند.

این ماده خام تنها وقتی ارزش پیدا می‌کند که کسی کار تعیین اینکه چه چیزی درست و چه چیزی مهم است را انجام دهد.

یک گفت‌وگوی AI با ۵۰۰ پیام خودبه‌خود دانش نیست.

اما اسکریپتی که در نهایت آزمایش واقعی را پشت سر می‌گذارد، همراه با توضیح ۲۰ نسخه‌ای که موفق نشدند، می‌تواند دانش باشد.

همین تفاوت چیزی است که می‌خواهم در وبلاگ حفظ کنم.

انتشار راه من برای جلوگیری از ناپدید شدن کار مفید است

بیشتر کارهای فنی به شکل عجیبی موقتی هستند.

یک bug سخت برطرف می‌شود.

ترمینال بسته می‌شود.

deployment موفق می‌شود.

گفت‌وگو در تاریخچه پایین می‌رود.

شش ماه بعد حتی شاید خودم یادم نباشد چرا implementation نهایی دقیقاً چنین شکلی دارد.

نوشتن این وضعیت را تغییر می‌دهد.

مجبورم می‌کند استدلال را تا زمانی که شواهد هنوز وجود دارند بازسازی کنم.

چیزی قابل جست‌وجو می‌سازد.

برای کار آینده خودم یک مرجع ایجاد می‌کند.

و ظاهراً گاهی به کسی می‌رسد که هرگز انتظارش را نداشته‌ام — حتی یک نشریه مهندسی به زبانی که صحبت نمی‌کنم.

هنوز دلیل پیچیده‌ای برای نگه داشتن این وبلاگ ندارم.

یاد گرفتن را دوست دارم.

ساختن چیزها را دوست دارم.

دوست دارم بیش از حد در مسائلی عمیق شوم که ابتدا ساده به نظر می‌رسیدند.

و بعد از صرف ده‌ها ساعت، و گاهی بیش از صد ساعت، برای رسیدن به یک جواب مفید، دیگر نمی‌خواهم آن جواب در یک پنجره چت بمیرد.

برای من همین دلیل کافی است که منتشرش کنم.

اگر کار شما هم چنین دانشی تولید می‌کند که با زحمت به دست آمده، فکر می‌کنم شاید برای شما هم دلیل کافی باشد.