मैंने बिना किसी कमाई की योजना के एक तकनीकी ब्लॉग शुरू किया। फिर एक जापानी इंजीनियरिंग साइट ने उसे खोज लिया

काफी लंबे समय तक मुझे यह भी यकीन नहीं था कि इस वेबसाइट को ब्लॉग की जरूरत है।

मैं अपने काम का ज्यादातर समय वैसे भी समस्याएँ हल करने में बिताता हूँ। कुछ सामान्य frontend या backend काम होते हैं। कुछ बहुत संकीर्ण हो जाते हैं: image encoding, browser behavior, SEO experiments, infrastructure failures, AI-assisted development, media processing, या production की कोई अजीब समस्या जो एक साधारण सवाल से शुरू होकर कई दिनों की जाँच में बदल जाती है।

उसके बाद कुछ हजार शब्द और लिखना गैरज़रूरी लग सकता है।

इसे पढ़ेगा कौन?

मुझे इससे मिलेगा क्या?

समस्या हल करके आगे क्यों न बढ़ जाऊँ?

आखिरकार मुझे एक जवाब मिला जो मेरे लिए काफी था: इस काम का कुछ हिस्सा इतना महँगा है कि उसे यूँ ही फेंकना ठीक नहीं।

कभी-कभी किसी कठिन समस्या के भीतर पूरा लेख छिपा होता है, और मुझे बाद में पता चलता है

मेरे लेख आमतौर पर इस सोच से शुरू नहीं होते कि “इस हफ्ते एक ब्लॉग पोस्ट लिखनी है।”

वे एक समस्या से शुरू होते हैं।

कभी वह मेरे काम से आती है, कभी मेरे किसी अपने प्रोजेक्ट से। कभी कोई ऐसी चीज मुझे दिलचस्प लगती है जिसे मैं समझता नहीं, और मैं तब तक गहराई में जाता रहता हूँ जब तक उसे काफी बेहतर न समझ लूँ।

Image processing ने मुझे कई बार ऐसे रास्तों पर भेजा है।

शुरुआत में काम लगभग हास्यास्पद रूप से आसान लग सकता है:

इन तस्वीरों को लो और इनका आकार छोटा कर दो।

आप किसी AI model से script माँग सकते हैं और लगभग तुरंत पा सकते हैं।

इसका मतलब यह नहीं कि आपके पास अच्छा image-processing pipeline है।

पहला version JPEG, PNG, WebP और animated content के फर्क को नज़रअंदाज़ कर सकता है। वह हर चीज के लिए एक ही quality value इस्तेमाल कर सकता है, बिना जरूरत image upscale कर सकता है, transparency को खराब तरीके से संभाल सकता है, वह metadata बचा सकता है जिसे आप हटाना चाहते थे या वह metadata नष्ट कर सकता है जिसे आप रखना चाहते थे। वह visual damage मापे बिना file size को optimize कर सकता है। दस test files पर बिल्कुल सही चलकर बहुत बड़े scale पर बेहद महँगी गलती बन सकता है।

किसी script का सफलतापूर्वक चल जाना उस system के बराबर नहीं है जिस पर मैं भरोसा करूँ।

मेरे कई लेख इसी अंतर से पैदा होते हैं।

मेरा AI workflow “ChatGPT से जवाब पूछ लो” से कहीं धीमा है

इस तरह की समस्याओं पर काम करते समय मैं paid ChatGPT account का काफी इस्तेमाल करता हूँ।

एक conversation दिनों या हफ्तों तक चल सकती है। मैं सवाल करता हूँ, सुझावों को test करता हूँ, परिणाम वापस देता हूँ, assumptions पर सवाल उठाता हूँ, code देखता हूँ, अगला edge case ढूँढ़ता हूँ, implementation बदलता हूँ, फिर चलाता हूँ, परिणाम तुलना करता हूँ और यही प्रक्रिया दोहराता हूँ।

बहुत गहरी investigations में एक ही व्यापक समस्या के आसपास 100 घंटे से ज्यादा काम जमा हो चुका है।

इसका अर्थ यह नहीं कि मैं 100 घंटे इस इंतज़ार में बैठा रहता हूँ कि AI model जादू से जवाब निकाल देगा।

प्रक्रिया iterative है।

आम तौर पर यह कुछ ऐसी होती है:

1. मैं समस्या समझाता हूँ।
2. Model एक शुरुआती समाधान देता है।
3. मैं उसे वास्तविक data पर चलाता हूँ।
4. कुछ कमजोर, inefficient या सीधा गलत निकलता है।
5. मैं evidence वापस देता हूँ।
6. हम approach बदलते हैं।
7. मैं फिर test करता हूँ।
8. एक और edge case सामने आता है।
9. फिर दोहराते हैं।

यह cycle कई बार चल सकती है।

काम की चीज अक्सर पहला script नहीं होता, बल्कि उसके आसपास जमा failures, measurements, corrections और decisions होते हैं।

AI ने शुरुआती समाधान बनाना सस्ता कर दिया, verification को नहीं

यही एक कारण है कि AI से लिखे technical content पर होने वाली सामान्य बहस मुझे जरूरत से ज्यादा सरल लगती है।

हाँ, AI model बहुत जल्दी एक plausible tutorial बना सकता है।

वह ऐसा code भी बना सकता है जो बिल्कुल सही दिखे और उन्हीं स्थितियों में गलत हो जहाँ गलती सबसे अधिक मायने रखती है।

संकीर्ण technical समस्याओं में मुझे पहली plausible answer शायद ही कभी चाहिए। मैं जानना चाहता हूँ कि उसे वास्तव में चलाने पर क्या होता है।

अगर मैं image pipeline बना रहा हूँ, तो output size और visual quality देखना चाहता हूँ। अलग source formats पर क्या होता है, यह जानना चाहता हूँ। unusual dimensions, alpha, animations और corrupt inputs test करना चाहता हूँ। और यह समझना चाहता हूँ कि implementation किन assumptions पर बनी है।

अगर script को बाद में एक बहुत बड़ी collection पर चलना है, तो यह काम और अधिक महत्वपूर्ण हो जाता है।

दस मिलियन images जानबूझकर लिया गया एक extreme example है, मेरे किसी खास dataset के आकार का दावा नहीं। मगर यह समस्या को साफ दिखाता है: दस मिलियन बार दोहराई गई छोटी systematic mistake अब छोटी नहीं रहती।

Code generate करने की लागत गिर चुकी है।

यह तय करने की लागत नहीं गिरी कि वह code scale पर चलाने लायक है या नहीं।

Chat research material है, तैयार लेख नहीं

ऐसी लंबी investigation के बाद chat history में बहुत बड़ी मात्रा में जानकारी जमा हो सकती है।

उसमें हो सकते हैं:

• वे approaches जो fail हुए;
• बाद में बदला गया code;
• काम के benchmark results;
• logs;
• गलतफहमियाँ;
• corrections;
• अस्पष्ट behavior की explanations;
• alternatives की comparisons;
• वे edge cases जिनके बारे में मैंने शुरुआत में नहीं सोचा था;
• और वे final rules जिन पर अंततः मुझे भरोसा हुआ।

इन सबको एक private conversation में छोड़ देना मुझे बर्बादी लगता है।

इसलिए मैं उपयोगी हिस्से निकालकर उन्हें लेख में बदलता हूँ।

लेख conversation का transcript नहीं है। Conversation का अधिकांश हिस्सा कभी लेख बनना ही नहीं चाहिए।

एक उपयोगी technical article के लिए एक और pass चाहिए: वे dead ends हटाना जो कुछ नहीं सिखाते, वे रखना जो महत्वपूर्ण बात समझाते हैं, claims verify करना, chronology फिर बनाना, observation और explanation अलग करना और final result को ऐसी चीज़ में बदलना जिसे कोई दूसरा developer वास्तव में इस्तेमाल कर सके।

यह editing step महत्वपूर्ण है।

AI इसमें भाग ले सकता है, मगर evidence अभी भी वास्तविक काम से आता है।

Image processing ने मुझे सिखाया कि “सरल” समस्या कितनी गहरी हो सकती है

मेरे अपने काम में image optimization शायद सबसे साफ उदाहरण है।

मैंने इसमें इतना समय लगाया है कि जो शुरुआत में encoder settings का collection लगता था, वह धीरे-धीरे बहुत बड़ी systems problem बन गया।

सवाल तेजी से बदलते हैं।

मैं किस source format से काम कर रहा हूँ?

क्या वह animated है?

क्या dimensions बदलने चाहिए?

Quality कैसे चुनूँ?

कौन-सा metric तय करे कि quality loss स्वीकार्य है?

क्या एक quality threshold बिल्कुल अलग-अलग images पर काम करेगा?

Upscaling कैसे रोकूँ?

कौन-सा metadata बचना चाहिए?

Transparency का क्या होगा?

Output validate कैसे करना चाहिए?

क्या छोटी file अतिरिक्त encoding cost को वास्तव में justify करती है?

Input population बदलने पर क्या होता है?

इसीलिए मैं पाँच लाइन वाले “ultimate image optimization” scripts को लेकर skeptical हूँ।

वे निश्चित रूप से image process कर सकते हैं।

लेकिन ऐसे pipeline को बनाना अलग बात है जिसके trade-offs आप समझते हों।

मेरे मौजूदा image-heavy workloads में AVIF आमतौर पर वह format है जिसे मैं पहले देखना चाहता हूँ। यह मेरे काम के projects पर आधारित rule है, यह दावा नहीं कि दुनिया की हर website को कल सारे पुराने formats मिटा देने चाहिए। Compatibility requirements, source material, latency, encoder cost और delivery architecture जवाब बदल सकते हैं।

दिलचस्प बात किसी एक format को winner घोषित करना नहीं है।

दिलचस्प बात workload को इतना समझना है कि फैसला जानबूझकर लिया जाए।

मैं video processing में भी उतनी ही गहराई तक जाना चाहता हूँ। अभी वहाँ नहीं पहुँचा हूँ। यही इन विषयों को रोचक रखता है: हर बार जब लगता है कि समस्या की तह तक पहुँच गया हूँ, एक नई layer दिखाई देती है।

फिर एक जापानी साइट ने ब्लॉग ढूँढ़ लिया

इन लेखों को प्रकाशित करते समय मुझे किसी खास लाभ की उम्मीद नहीं थी।

इस blog से मुझे कोई meaningful financial return नहीं मिलता। मैं इसे इसलिए करता हूँ क्योंकि प्रक्रिया मुझे पसंद है और useful work को पुराने chats और terminal history में गायब होने देने के बजाय बचाकर रखना चाहता हूँ।

फिर कुछ ऐसा हुआ जिसकी सच में उम्मीद नहीं थी।

17 सितंबर 2026 को जापानी साइट Levtech Freelance ने लगभग “अपनी skills बेहतर करना चाहने वाले engineers के लिए सुझाए गए blogs” जैसे शीर्षक वाली एक roundup प्रकाशित की।

Levtech Freelance के लेख में JSVar को कई अन्य engineering blogs के साथ शामिल किया गया।

Levtech जापान के बड़े IT-career ecosystem का हिस्सा है और Levtech Freelance freelance IT engineers को support और opportunities से match करने पर केंद्रित है। मेरे लिए सबसे दिलचस्प बात सिर्फ backlink मिलना नहीं थी। यह देखना था कि किसी बाहरी editorial team को मेरे काम के कौन-से हिस्से वर्णन करने लायक लगे।

JSVar वाले section में उन्होंने खास तौर पर तीन लेख उठाए।

एक इस बारे में था कि production development में मुझे Codex और TypeScript अच्छी जोड़ी क्यों लगे, खासकर इसलिए कि TypeScript के types और compiler feedback generated code की समस्याएँ जल्दी सामने ला सकते हैं।

दूसरा ChatGPT की मदद से blog को 20 भाषाओं में translate करने और अलग देशों के search visitors को सीधे localized pages पर आते देखने के बारे में था।

तीसरा 10,000 AI-generated SEO pages publish करने का मेरा experiment था, जो अंततः आसान growth की कहानी बनने के बजाय failure की कहानी बन गया।

यह selection मुझे मज़ेदार लगी क्योंकि तीनों लेख बहुत अलग हैं, लेकिन उनमें एक pattern समान है।

वे किसी ऐसी चीज़ पर आधारित हैं जो मैंने वास्तव में की।

मुझे ठीक-ठीक नहीं पता कि Levtech ने मुझे कैसे खोजा

यहाँ एक आकर्षक कहानी बनाई जा सकती है।

मैं जापानी नहीं बोलता।

मेरी site का Japanese version है।

एक Japanese engineering publication ने site खोजी।

इसलिए blog को Japanese में translate करने के कारण Levtech ने उसे खोजा।

मैं इसे साबित नहीं कर सकता।

हो सकता है Japanese pages ने मदद की हो।

हो सकता है search उन्हें English article तक ले गई हो।

हो सकता है किसी ने link share किया हो।

या उन्होंने site किसी बिल्कुल अलग रास्ते से खोजी हो।

मेरे पास वह attribution data नहीं है, इसलिए मैं उससे एक साफ-सुथरी SEO case study नहीं बनाना चाहता जिसे evidence support नहीं करता।

मैं जो confirm कर सकता हूँ वह बहुत सरल है: मैंने blog को कई भाषाओं में publish किया और बाद में एक Japanese publication ने उसे इतना उपयोगी समझा कि editorial roundup में शामिल किया।

यह अपने आप में अच्छा result है।

और खासकर इसलिए अच्छा लगता है क्योंकि localization भी शुरुआत में ऐसा experiment था जिसमें बहुत काम और अनिश्चित payoff था।

यह उल्लेख इसलिए मायने रखता था क्योंकि यह independent validation था

“Validation” से मेरा मतलब यह नहीं कि Levtech ने मेरे लिखे हर शब्द को सही साबित कर दिया।

उन्होंने मेरी codebase audit नहीं की और हर experiment reproduce नहीं किया।

जो मायने रखता था, वह इससे छोटा था।

दुनिया के दूसरी तरफ किसी व्यक्ति ने, ऐसे audience के लिए लिखते हुए जिसे मैं खुद उनकी भाषा में address नहीं कर सकता, मेरे काम में इतनी value देखी कि अपने readers के लिए उसका सार लिखे।

मैंने उन्हें pitch नहीं किया था।

मैंने मूल लेख Levtech के लिए नहीं लिखे थे।

मुझे Japanese roundup में आने की उम्मीद नहीं थी।

इसीलिए यह result मेरे लिए meaningful है।

यह बताता है कि बहुत niche technical article को publish करने लायक होने के लिए जरूरी नहीं कि बहुत बड़ा audience मिले।

उसे सही reader के लिए उपयोगी होना चाहिए।

क्या 2026 में developer को blog शुरू करना चाहिए?

मेरे लिए जवाब है हाँ — एक महत्वपूर्ण शर्त के साथ।

आपको सच में कुछ लिखकर रखना चाहना चाहिए।

मैं technical blog सिर्फ इसलिए शुरू करने की सलाह नहीं दूँगा कि किसी ने कहा हर developer को “personal brand” चाहिए।

मैं passive income की उम्मीद में भी नहीं शुरू करूँगा।

और ऐसी technologies की generic explanations से इसे नहीं भरूँगा जिनकी documentation पहले से बेहतर है।

लेकिन अगर आपका काम बार-बार ऐसी चीजें पैदा करता है जिन्हें शुरुआत में आप खुद खोज पाते तो अच्छा होता, तो बात अलग है।

उन्हें लिखिए।

उस अजीब production failure के बारे में लिखिए।

उस optimization के बारे में लिखिए जिसमें उम्मीद से तीन दिन ज्यादा लगे।

उस benchmark के बारे में लिखिए जिसने आपकी assumption को गलत साबित किया।

उस approach के बारे में लिखिए जो elegant लगी और fail हुई।

Final implementation लिखिए, मगर यह भी बताइए कि obvious implementation क्यों पर्याप्त नहीं थी।

यही वे हिस्से हैं जिन्हें generic knowledge से बनाना कठिन है।

AI मुझे लिखने के लिए कम नहीं, ज्यादा material देता है

AI ने मुझे यह नहीं सोचने पर मजबूर किया कि technical blogs obsolete हो गए हैं।

मेरे लिए लगभग उल्टा हुआ है।

मैं ज्यादा ideas investigate कर सकता हूँ क्योंकि initial implementation या explanation पहले से जल्दी मिल जाती है।

मगर तेज iteration अधिक evidence भी बनाती है: ज्यादा variants, logs, benchmarks, failed attempts और verify करने के लिए ज्यादा चीजें।

यह raw material तभी valuable होता है जब कोई यह तय करने का काम करे कि सच क्या है और महत्वपूर्ण क्या है।

500 messages वाली AI conversation अपने आप knowledge नहीं बन जाती।

एक script जो अंततः real testing survive कर ले, साथ में उन 20 versions की explanation जो नहीं कर पाए, knowledge बन सकती है।

यही फर्क मैं blog में capture करना चाहता हूँ।

Publishing useful work को गायब होने से बचाने का मेरा तरीका है

ज्यादातर technical work हैरान करने वाली हद तक temporary होता है।

कठिन bug fix हो जाता है।

Terminal बंद हो जाता है।

Deployment सफल हो जाता है।

Chat history में conversation नीचे चली जाती है।

छह महीने बाद शायद मुझे खुद भी याद न रहे कि final implementation ऐसी क्यों है।

लिखना इसे बदल देता है।

यह मुझे उस समय reasoning फिर से बनाने को मजबूर करता है जब evidence अभी मौजूद है।

यह searchable चीज़ बनाता है।

यह मेरे भविष्य के काम के लिए reference देता है।

और कभी-कभी, ऐसा लगता है, यह किसी ऐसे व्यक्ति तक पहुँच जाता है जिसकी मैंने कभी उम्मीद नहीं की थी — यहाँ तक कि ऐसी भाषा की engineering publication तक जिसे मैं बोलता नहीं।

इस blog को चलाने के लिए मेरे पास अभी भी कोई sophisticated reason नहीं है।

मुझे सीखना पसंद है।

मुझे चीजें बनाना पसंद है।

मुझे उन समस्याओं में जरूरत से ज्यादा गहराई तक जाना पसंद है जो शुरुआत में आसान दिखती थीं।

और किसी उपयोगी answer तक पहुँचने के लिए दर्जनों, कभी-कभी 100 घंटे से भी ज्यादा बिताने के बाद मैं नहीं चाहता कि वह answer chat window के भीतर मर जाए।

मेरे लिए उसे publish करने का यह पर्याप्त कारण है।

अगर आपका काम भी इसी तरह मेहनत से हासिल knowledge पैदा करता है, तो मुझे लगता है शायद आपके लिए भी यह पर्याप्त कारण हो सकता है।