অনেক দিন পর্যন্ত আমি নিশ্চিত ছিলাম না যে এই ওয়েবসাইটে আদৌ একটি ব্লগ দরকার কি না।
আমার কাজের বেশির ভাগ সময়ই সমস্যা সমাধানে যায়। কিছু সাধারণ frontend বা backend কাজ। কিছু আবার অনেক সংকীর্ণ হয়ে যায়: image encoding, browser behavior, SEO experiment, infrastructure failure, AI-assisted development, media processing, অথবা এমন কোনো অদ্ভুত production সমস্যা যা একটি সহজ প্রশ্ন দিয়ে শুরু হয়ে কয়েক দিনের তদন্তে গড়ায়।
এরপর আরও কয়েক হাজার শব্দ লেখা অপ্রয়োজনীয় মনে হতেই পারে।
কে পড়বে?
আমি এর থেকে কী পাব?
সমস্যাটি সমাধান করে সামনে এগিয়ে গেলেই তো হয়?
শেষ পর্যন্ত আমার জন্য যথেষ্ট একটি উত্তর পেয়েছি: এই কাজের কিছু অংশ ফেলে দেওয়ার জন্য খুব বেশি মূল্যবান।
আমি বুঝে ওঠার আগেই একটি কঠিন সমস্যার ভেতরে পুরো একটি নিবন্ধ লুকিয়ে থাকতে পারে
আমার নিবন্ধ সাধারণত “এই সপ্তাহে একটা ব্লগ পোস্ট লিখতে হবে” ভাবনা দিয়ে শুরু হয় না।
শুরু হয় একটি সমস্যা দিয়ে।
কখনও সেটা আমার কাজ থেকে আসে, কখনও নিজের কোনো প্রকল্প থেকে। কখনও এমন কিছুতে আগ্রহ জন্মায় যা আমি বুঝি না, আর আমি খুঁড়তে থাকি যতক্ষণ না বিষয়টি অনেক গভীরভাবে বুঝতে পারি।
Image processing আমাকে এমন বহু গভীর গর্তে নামিয়েছে।
প্রথমে কাজটি প্রায় হাস্যকরভাবে সহজ শোনাতে পারে:
এই ছবিগুলো নাও এবং ছোট করে দাও।
একটি AI model-কে script চাইলে প্রায় সঙ্গে সঙ্গেই একটি script পাওয়া যায়।
তাতে একটি ভালো image-processing pipeline তৈরি হয়ে যায় না।
প্রথম সংস্করণ JPEG, PNG, WebP ও animated content-এর পার্থক্য উপেক্ষা করতে পারে। সব কিছুর জন্য একই quality value ব্যবহার করতে পারে। অপ্রয়োজনীয়ভাবে ছবি upscale করতে পারে। Transparency খারাপভাবে সামলাতে পারে। আপনি যে metadata মুছতে চেয়েছিলেন তা রেখে দিতে পারে, আবার যেটি রাখতে চেয়েছিলেন সেটি নষ্ট করতে পারে। Visual damage না মেপেই file size কমাতে পারে। দশটি test file-এ একদম ঠিক চলেও বৃহৎ scale-এ অত্যন্ত ব্যয়বহুল ভুলে পরিণত হতে পারে।
একটি script সফলভাবে চলে মানেই সেটি এমন একটি system নয় যাকে আমি বিশ্বাস করি।
আমার অনেক নিবন্ধের জন্ম এই পার্থক্য থেকেই।
আমার AI workflow “ChatGPT-কে উত্তর জিজ্ঞেস করা”-র চেয়ে অনেক ধীর
এই ধরনের সমস্যা নিয়ে কাজ করার সময় আমি একটি paid ChatGPT account অনেক ব্যবহার করি।
একটি conversation দিন বা সপ্তাহ ধরে চলতে পারে। আমি প্রশ্ন করি, প্রস্তাব পরীক্ষা করি, ফলাফল আবার পাঠাই, assumption নিয়ে প্রশ্ন তুলি, code দেখি, নতুন edge case খুঁজি, implementation বদলাই, আবার চালাই, ফল তুলনা করি এবং পুনরাবৃত্তি করি।
বিশেষভাবে গভীর কিছু তদন্তে একই বিস্তৃত সমস্যাকে ঘিরে আমার 100 ঘণ্টারও বেশি কাজ জমেছে।
এর মানে এই নয় যে আমি 100 ঘণ্টা বসে থাকি, AI model জাদুর মতো উত্তর আবিষ্কার করবে বলে।
প্রক্রিয়াটি iterative।
সাধারণত ধাপগুলো এমন:
- আমি সমস্যাটি বর্ণনা করি।
- Model একটি প্রাথমিক সমাধান প্রস্তাব করে।
- আমি সেটি বাস্তব data-তে চালাই।
- কিছু দুর্বল, অদক্ষ অথবা সরাসরি ভুল দেখা যায়।
- আমি evidence আবার ফিরিয়ে দিই।
- আমরা approach বদলাই।
- আমি আবার পরীক্ষা করি।
- আরেকটি edge case আসে।
- পুনরাবৃত্তি।
এই চক্র বহুবার ঘটতে পারে।
উপকারী ফলটি প্রায়ই প্রথম script নয়; বরং তার চারপাশে জমা হওয়া failure, measurement, correction ও decision-এর সমষ্টি।
AI একটি শুরুর সমাধান তৈরি করা সস্তা করেছে, verification সস্তা করেনি
AI দিয়ে লেখা technical content নিয়ে প্রচলিত আলোচনাকে আমার অতিরিক্ত সরল মনে হওয়ার একটি কারণ এটি।
হ্যাঁ, একটি AI model খুব দ্রুত বিশ্বাসযোগ্য একটি tutorial লিখতে পারে।
এটি এমন code-ও লিখতে পারে যা সম্পূর্ণ যুক্তিসঙ্গত দেখায়, কিন্তু ঠিক সেই জায়গায় ভুল যেখানে ভুল হওয়াটা সবচেয়ে গুরুত্বপূর্ণ।
সংকীর্ণ technical সমস্যায় আমি সাধারণত প্রথম বিশ্বাসযোগ্য উত্তর চাই না। বাস্তবে চালালে কী হয়, সেটিই জানতে চাই।
আমি যদি image pipeline বানাই, output size এবং visual quality দেখতে চাই। বিভিন্ন source format-এ কী হয় তা জানতে চাই। অস্বাভাবিক dimension, alpha, animation এবং corrupt input পরীক্ষা করতে চাই। Implementation কোন assumption-এর উপর দাঁড়িয়ে আছে সেটিও বুঝতে চাই।
Script-টি যদি পরে বিশাল collection স্পর্শ করে, কাজটি আরও গুরুত্বপূর্ণ হয়।
দশ মিলিয়ন ছবি ইচ্ছাকৃতভাবে চরম একটি উদাহরণ; এটি আমার কোনো নির্দিষ্ট dataset-এর আকারের দাবি নয়। কিন্তু সমস্যাটি পরিষ্কার করে: দশ মিলিয়ন বার পুনরাবৃত্ত একটি ছোট systematic mistake আর ছোট থাকে না।
Code generation-এর খরচ ভীষণ কমেছে।
কিন্তু সেই code scale-এ চালানোর যোগ্য কি না নির্ধারণের খরচ কমেনি।
Chat গবেষণার উপাদান, চূড়ান্ত নিবন্ধ নয়
এই ধরনের দীর্ঘ তদন্তের পরে chat history-তে অবিশ্বাস্য পরিমাণ তথ্য জমতে পারে।
তার মধ্যে থাকতে পারে:
- ব্যর্থ approach;
- পরে প্রতিস্থাপিত code;
- উপকারী benchmark result;
- log;
- ভুল বোঝাবুঝি;
- correction;
- অস্পষ্ট behavior-এর ব্যাখ্যা;
- বিকল্পগুলোর তুলনা;
- শুরুতে আমার মাথায় না আসা edge case;
- এবং শেষ পর্যন্ত যে rule-গুলোকে আমি বিশ্বাস করতে শিখেছি।
সব কিছু একটি private conversation-এর মধ্যে রেখে দেওয়া অপচয় মনে হয়।
তাই উপকারী অংশগুলো বের করে নিবন্ধে রূপ দিই।
নিবন্ধটি conversation-এর transcript নয়। Conversation-এর বেশির ভাগই নিবন্ধ হওয়া উচিত নয়।
একটি উপকারী technical article-এ আরও একটি editing pass দরকার: যে dead end কিছু শেখায় না তা বাদ দেওয়া, গুরুত্বপূর্ণ কিছু বোঝায় এমন dead end রাখা, claim যাচাই করা, chronology পুনর্গঠন করা, observation ও explanation আলাদা করা, এবং শেষ ফলকে এমন কিছুতে রূপ দেওয়া যা অন্য developer সত্যিই ব্যবহার করতে পারে।
এই editing ধাপ গুরুত্বপূর্ণ।
AI এতে অংশ নিতে পারে, কিন্তু evidence এখনও কাজ থেকেই আসে।
Image processing আমাকে শিখিয়েছে একটি “সহজ” সমস্যা কত গভীর হতে পারে
আমার কাজ থেকে image optimization সম্ভবত সবচেয়ে পরিষ্কার উদাহরণ।
এতে আমি এত সময় দিয়েছি যে প্রথমে encoder setting-এর একটি collection মনে হওয়া বিষয়টি ধীরে ধীরে বড় system problem-এ পরিণত হয়েছে।
প্রশ্ন খুব দ্রুত বদলে যায়।
আমি কোন source format নিয়ে কাজ করছি?
এটি animated কি?
Dimension বদলানো উচিত কি?
Quality কীভাবে নির্বাচন করব?
Quality loss গ্রহণযোগ্য কি না কোন metric নির্ধারণ করবে?
সম্পূর্ণ ভিন্ন ছবিতে একটি quality threshold কি কাজ করবে?
Upscaling কীভাবে এড়াব?
কোন metadata রাখা উচিত?
Transparency-র কী হবে?
Output কীভাবে validate করা উচিত?
ছোট file কি অতিরিক্ত encoding cost-কে সত্যিই ন্যায্যতা দেয়?
Input population বদলে গেলে কী হয়?
এই কারণেই পাঁচ লাইনের “ultimate image optimization” script নিয়ে আমার সন্দেহ আছে।
ওগুলো অবশ্যই একটি ছবি process করতে পারে।
কিন্তু এমন pipeline বানানো, যার trade-off আপনি বোঝেন, অন্য ব্যাপার।
আমার বর্তমান image-heavy workload-এ AVIF সাধারণত প্রথম যে formatটির দিকে আমি তাকাই। এটি আমার কাজের project-এর ধরন থেকে তৈরি rule; পৃথিবীর সব website-কে আগামীকাল পুরোনো format মুছে দিতে হবে — এমন দাবি নয়। Compatibility requirement, source material, latency, encoder cost এবং delivery architecture উত্তর বদলে দিতে পারে।
আসল বিষয় একটি format-কে বিজয়ী ঘোষণা করা নয়।
Workload-টি যথেষ্ট ভালোভাবে বোঝা, যাতে সিদ্ধান্তটি সচেতনভাবে নেওয়া যায়।
Video processing-এও একই গভীরে যেতে চাই। এখনও সেখানে পৌঁছাইনি। আর সেটিই বিষয়গুলোকে আকর্ষণীয় রাখে: একটি সমস্যার তলায় পৌঁছে গেছি মনে হলেই আরেকটি স্তর দেখা দেয়।
তারপর একটি জাপানি সাইট ব্লগটি খুঁজে পেল
এই নিবন্ধগুলো প্রকাশ করে কোনো নির্দিষ্ট লাভের প্রত্যাশা ছিল না।
এই blog থেকে আমার অর্থপূর্ণ financial return নেই। আমি করি কারণ process-টি আমার ভালো লাগে এবং useful work পুরোনো chat ও terminal history-তে হারিয়ে যাক, সেটা চাই না।
তারপর এমন কিছু ঘটল যা সত্যিই প্রত্যাশা করিনি।
২০২6 সালের 17 সেপ্টেম্বর জাপানি সাইট Levtech Freelance আনুমানিক “যেসব engineer নিজের skill বাড়াতে চান, তাঁদের জন্য প্রস্তাবিত blog” শিরোনামে একটি roundup প্রকাশ করে।
Levtech Freelance-এর নিবন্ধটি আরও কয়েকটি engineering blog-এর সঙ্গে JSVar-কে অন্তর্ভুক্ত করে।
Levtech জাপানের বড় IT-career ecosystem-এর অংশ, আর Levtech Freelance freelance IT engineer-দের সহায়তা ও কাজের সঙ্গে match করার উপর কেন্দ্রীভূত। আমার কাছে আকর্ষণীয় বিষয়টি শুধু backlink পাওয়া ছিল না। বাইরের একটি editorial team আমার কাজের কোন অংশগুলো বর্ণনা করার মতো মনে করেছে, সেটিই বেশি আকর্ষণীয় ছিল।
JSVar নিয়ে তাদের অংশে বিশেষভাবে তিনটি নিবন্ধ তুলে ধরা হয়।
একটি ছিল production development-এ Codex ও TypeScript-কে একসঙ্গে ভালো কাজ করতে দেখার কারণ নিয়ে, বিশেষ করে TypeScript type এবং compiler feedback generated code-এর সমস্যা আগে ধরতে পারে বলে।
আরেকটি ছিল ChatGPT দিয়ে blog-টি 20 ভাষায় অনুবাদ করা এবং বিভিন্ন দেশের search visitor-কে সরাসরি localized page-এ পৌঁছাতে দেখা নিয়ে।
তৃতীয়টি ছিল 10,000 AI-generated SEO page প্রকাশের পরীক্ষা, যা শেষ পর্যন্ত সহজ growth-এর গল্প না হয়ে failure-এর গল্পে পরিণত হয়।
এই selection আমার মজার লেগেছিল, কারণ তিনটি নিবন্ধ একে অন্যের থেকে খুব আলাদা, কিন্তু একই pattern শেয়ার করে।
প্রতিটিই আমি সত্যিই করেছি এমন কিছুর উপর ভিত্তি করে।
Levtech আমাকে ঠিক কীভাবে খুঁজে পেল, আমি জানি না
এখানে খুব আকর্ষণীয় একটি গল্প বানানো যায়।
আমি জাপানি ভাষা জানি না।
আমার site-এর Japanese version আছে।
একটি Japanese engineering publication site-টি খুঁজে পেয়েছে।
অতএব blog-টি Japanese-এ translate করার কারণেই Levtech সেটি খুঁজে পেয়েছে।
এটি আমি প্রমাণ করতে পারি না।
হয়তো Japanese page সাহায্য করেছে।
হয়তো search তাদের একটি English article-এ নিয়ে গেছে।
হয়তো কেউ link share করেছে।
হয়তো সম্পূর্ণ অন্য কোনো পথে site-এ পৌঁছেছে।
আমার কাছে attribution data নেই, তাই এর থেকে পরিচ্ছন্ন একটি SEO case study বানানোর ইচ্ছা নেই।
আমি যেটুকু নিশ্চিতভাবে বলতে পারি সেটি অনেক সহজ: আমি blog-টি একাধিক ভাষায় প্রকাশ করেছি, এবং পরে একটি Japanese publication সেটিকে editorial roundup-এ রাখার মতো আকর্ষণীয় মনে করেছে।
এটুকুই ইতিমধ্যে ভালো ফল।
বিশেষ করে ভালো লাগে কারণ localization-ও শুরুতে এমন একটি experiment ছিল যার জন্য অনেক পরিশ্রম লাগবে, কিন্তু ফল অনিশ্চিত।
এই উল্লেখটি গুরুত্বপূর্ণ ছিল কারণ এটি স্বাধীন স্বীকৃতি
“Validation” বলতে আমি বোঝাচ্ছি না যে Levtech আমার লেখা সব কিছু সঠিক প্রমাণ করেছে।
তারা আমার codebase audit করেনি বা প্রতিটি experiment reproduce করেনি।
গুরুত্বপূর্ণ বিষয়টি আরও ছোট ছিল।
বিশ্বের অন্য প্রান্তে এমন একজন, যার audience-কে আমি নিজে তাদের ভাষায় সম্বোধন করতে পারি না, আমার কাজের মধ্যে যথেষ্ট value দেখেছেন যাতে পাঠকদের জন্য সেটি সংক্ষেপে তুলে ধরেন।
আমি তাদের pitch করিনি।
মূল নিবন্ধগুলো Levtech-এর জন্য লিখিনি।
Japanese roundup-এ থাকারও আশা করিনি।
তাই ফলটি আমার কাছে অর্থপূর্ণ।
এটি দেখায় যে খুব সংকীর্ণ একটি technical article প্রকাশযোগ্য হওয়ার জন্য বিশাল audience প্রয়োজন নাও হতে পারে।
সঠিক reader-এর জন্য উপকারী হওয়াই যথেষ্ট।
২০২6 সালে একজন developer-এর blog শুরু করা উচিত কি?
আমার জন্য উত্তর হ্যাঁ — একটি গুরুত্বপূর্ণ শর্তে।
আপনার সত্যিই কিছু লিখে রাখতে ইচ্ছে করতে হবে।
কেউ বলেছে প্রতিটি developer-এর “personal brand” দরকার — শুধু এই কারণে technical blog শুরু করার পরামর্শ দেব না।
Passive income-এর আশা করেও শুরু করতাম না।
আর এমন technology নিয়ে generic explanation লিখে blog ভরাতাম না যার documentation ইতিমধ্যেই আরও ভালো।
কিন্তু আপনার কাজ যদি বারবার এমন জিনিস তৈরি করে যা শুরুতে আপনি নিজেই খুঁজে পেতে চেয়েছিলেন, তাহলে বিষয়টি আলাদা।
সেগুলো লিখে রাখুন।
অদ্ভুত production failure নিয়ে লিখুন।
যে optimization প্রত্যাশার চেয়ে তিন দিন বেশি লেগেছে সেটি নিয়ে লিখুন।
যে benchmark আপনার assumption ভুল প্রমাণ করেছে সেটি নিয়ে লিখুন।
যে approach সুন্দর মনে হয়েছিল কিন্তু ব্যর্থ হয়েছে সেটি লিখুন।
Final implementation লিখুন, কিন্তু obvious implementation কেন যথেষ্ট ছিল না সেটিও ব্যাখ্যা করুন।
Generic knowledge থেকে এই অংশগুলো বানানো কঠিন।
AI আমাকে লেখার জন্য কম নয়, বরং বেশি উপাদান দেয়
AI আমাকে technical blog-কে obsolete ভাবায়নি।
আমার ক্ষেত্রে প্রায় উল্টো হয়েছে।
Initial implementation বা explanation আগের তুলনায় দ্রুত পাওয়া যায় বলে আরও বেশি idea পরীক্ষা করতে পারি।
কিন্তু দ্রুত iteration আরও বেশি evidence-ও তৈরি করে: আরও variant, log, benchmark, failed attempt এবং যাচাই করার আরও বিষয়।
কোনটি সত্য এবং কোনটি গুরুত্বপূর্ণ তা নির্ধারণের কাজ কেউ না করা পর্যন্ত raw material-টির value তৈরি হয় না।
500 message-এর একটি AI conversation নিজে থেকেই knowledge নয়।
বাস্তব test টিকে যাওয়া একটি script, সঙ্গে যে 20 version টেকেনি তার ব্যাখ্যা — সেটি knowledge হতে পারে।
এই পার্থক্যটিই blog-এ ধরে রাখতে চাই।
Publishing-ই useful work-কে হারিয়ে যাওয়া থেকে বাঁচানোর আমার উপায়
বেশির ভাগ technical work আশ্চর্যজনকভাবে সাময়িক।
কঠিন bug ঠিক হয়।
Terminal বন্ধ হয়।
Deployment সফল হয়।
Chat history-তে conversation নিচে নেমে যায়।
ছয় মাস পরে final implementation কেন এমন, সেটি হয়তো আমিও মনে রাখতে পারি না।
লেখা সেটি বদলে দেয়।
Evidence এখনও থাকা অবস্থায় reasoning আবার তৈরি করতে বাধ্য করে।
Search করা যায় এমন কিছু তৈরি হয়।
ভবিষ্যতের নিজের কাজের জন্য reference পাই।
আর মাঝে মাঝে, মনে হচ্ছে, এটি এমন কারও কাছে পৌঁছে যায় যাকে কখনও প্রত্যাশা করিনি — এমনকি এমন ভাষার engineering publication-এও, যে ভাষা আমি বলি না।
এই blog চালিয়ে যাওয়ার জন্য এখনও আমার কোনো জটিল কারণ নেই।
শিখতে ভালো লাগে।
জিনিস বানাতে ভালো লাগে।
প্রথমে সহজ মনে হওয়া সমস্যার মধ্যে অস্বাভাবিক গভীরে যেতে ভালো লাগে।
আর একটি কার্যকর উত্তর পেতে কয়েক দশক ঘণ্টা, কখনও 100 ঘণ্টারও বেশি সময় দেওয়ার পরে, সেই উত্তরকে chat window-এর মধ্যে মরে যেতে দিতে চাই না।
আমার জন্য publish করার এটুকুই যথেষ্ট কারণ।
আপনার কাজ থেকেও যদি একই ধরনের কঠিন পরিশ্রমে পাওয়া জ্ঞান তৈরি হয়, আমার মনে হয় আপনার জন্যও এটি যথেষ্ট কারণ হতে পারে।