আপনার কাজ শুধু কোড লেখা নয়। এটি সিদ্ধান্ত নেওয়া। আপনি সেগুলো থেকে শিখছেন। সময়ের সাথে সাথে আপনি কম ভুল করেন। অবশেষে, আপনি অন্যদের সেই একই কুয়াশার মধ্য দিয়ে পথ দেখান। সেই বিবর্তন—লজিক লেখা থেকে ফলাফলের দায়িত্ব নেওয়া পর্যন্ত—একজন সিনট্যাক্স টাইপ করা ব্যক্তি এবং একজন সিস্টেম নির্মাতা—এই দুয়ের মধ্যে পার্থক্য তৈরি করে।
আপনি প্রতিদিন সিদ্ধান্ত নেন। কিছু সিদ্ধান্ত খুব তুচ্ছ মনে হতে পারে, যেমন একটি বাটনের রঙ নির্বাচন করা। অন্যগুলো পুরো প্রোডাক্টের কাঠামো বদলে দিতে পারে। আসল কৌশল হলো এটি আগেভাগেই বুঝতে পারা যে এই দুটি একে অপরের সাথে সম্পর্কিত। অসাবধানতাবশত নেওয়া একটি ছোট সিদ্ধান্ত পরবর্তীতে বড় বাধা হয়ে দাঁড়াতে পারে, অন্যদিকে শুরুতে নেওয়া একটি কঠিন সিদ্ধান্ত পরবর্তীতে অনেক সময় অসাধারণ বা প্রতিভাময় মনে হয়।
শুরুর দিকের সিদ্ধান্তের প্রভাবের ব্যাপ্তি (Blast Radius)
যখন আপনি শুরু করছেন, আপনার ভুলগুলো একটি ছোট ঘরে প্রতিধ্বনিত হয়। একটি খারাপ কমিট একটি লোকাল বিল্ড নষ্ট করে দেয়। একটি অগোছালো ফাংশন একটি স্ক্রিনকে ধীর করে দেয়। এর প্রভাবের ব্যাপ্তি সীমিত থাকে। আপনি খুব কম মানুষের ওপর প্রভাব ফেলেন এবং তা কাটিয়ে উঠতে খরচও কম হয়।
কিন্তু আপনি যখন বড় হন, একজন স্বতন্ত্র ইঞ্জিনিয়ার হিসেবে বা একটি কোম্পানি হিসেবে, আপনার সিদ্ধান্তগুলো আরও বেশি সিস্টেমকে প্রভাবিত করে। বড় পরিসরে নেওয়া সেই একই সিদ্ধান্ত কয়েক সপ্তাহ সময় নষ্ট করতে পারে। এই কারণেই আপনাকে এখনই সুচিন্তিত সিদ্ধান্ত নিতে শিখতে হবে, এর মূল্য চড়া হওয়ার আগেই।
তিনটি সাধারণ ফাঁদ সম্পর্কে ভাবুন:
এমন একটি প্ল্যাটফর্ম ব্যবহার করা যা আপনার ডিপেন্ডেন্সিগুলো সাপোর্ট করে না, তা ইঞ্জিনিয়ারিংয়ের ডজন ডজন বা শত শত ঘণ্টা নষ্ট করতে পারে। সেই সময়গুলো শুধু টাইপ করার জন্য নয়। সেগুলো ব্যয় হয় অদ্ভুত কম্প্যাটিবিলিটি ইস্যু ডিবাগ করতে, ট্রানজিটিভ লাইব্রেরি প্যাচ করতে এবং স্টেকহোল্ডারদের বোঝাতে যে কেন একটি সাধারণ ফিচার তৈরি করতে পুরো একটি কোয়ার্টার লেগে গেল।
প্রোডাক্টের শুরুর দিকে সেশন-ভিত্তিক অথেন্টিকেশন থেকে JWT-তে চলে আসা পরবর্তীতে একটি ব্যয়বহুল রিরাইট থেকে বাঁচায়। যখন আপনার হাজার হাজার ইউজার থাকে তখন লগইন লজিক রিফ্যাক্টর করা অনেক সহজ, কিন্তু যখন আপনার লক্ষ লক্ষ ইউজার থাকে এবং ডাউনটাইম মানেই বড় আর্থিক ক্ষতি, তখন এটি অনেক কঠিন।
আপনার সেরা অনুমানের দ্বিগুণ সময় নির্ধারণ করা তখনই কার্যকর হয় যখন আপনি সেই বাফারটি কোয়ালিটি বজায় রাখার জন্য ব্যবহার করেন। সোশ্যাল মিডিয়া স্ক্রল করার জন্য শিডিউল বাড়িয়ে দেওয়া হলো অপচয়। আর টেস্ট লেখা, এজ কেস রিভিউ করা এবং অবজারভেবিলিটি যাচাই করার জন্য সময় বাড়ানো হলো বিনিয়োগ।
এখানকার প্যাটার্নটি সহজ: টেকনিক্যাল ডেট (technical debt) চক্রবৃদ্ধি হারে বাড়ে। মূল পরিমাণ ছোট থাকতেই তা পরিশোধ করে ফেলুন।
কাটঅফ ডেট এবং নিয়ন্ত্রণের বিভ্রম
ডেডলাইন সবখানেই আছে। রিলিজ ডেট, ডেমো ডেট, কোড ফ্রিজ। বড় কোম্পানিগুলোতে এগুলো প্রায়ই টেকনিক্যাল প্রয়োজনের চেয়ে মনস্তাত্ত্বিক উদ্দেশ্যেই বেশি ব্যবহৃত হয়। এগুলো জটিলতার ওপর নিয়ন্ত্রণের একটি অনুভূতি তৈরি করে যা আসলে কেউ পুরোপুরি বোঝে না।
এর পার্শ্বপ্রতিক্রিয়াটি অনুমানযোগ্য। কাটঅফ বা ডেডলাইন যত কাছে আসে, কোয়ালিটি তত কমে যায়। টিমগুলো টেস্ট বাদ দিয়ে দেয়, এরর হ্যান্ডলিং কমেন্ট আউট করে দেয় এবং এমন কোড শিপ করে যা কেউ মেইনটেইন করতে চায় না। ডেডলাইন পূরণ হয়। ক্যালেন্ডার দেখতে পরিষ্কার থাকে। কিন্তু প্রোডাক্টটি আরও খারাপ হয়ে যায়।
এটি ঘটে কারণ ইঞ্জিনিয়াররা নিখুঁত কোড এবং মার্জিত আর্কিটেকচার পছন্দ করেন। এটি আমাদের স্বভাব। কিন্তু নিখুঁত উত্তর সবসময় থাকে না। সঠিক সিদ্ধান্ত হলো সেটি যা আপনার টিমের বর্তমান অবস্থার সাথে সামঞ্জস্যপূর্ণ। তিনজনের একটি স্টার্টআপের জন্য সেই একই আনুষ্ঠানিকতার প্রয়োজন নেই যা একটি নিয়ন্ত্রিত হেলথকেয়ার প্ল্যাটফর্মের প্রয়োজন হয়। আপনি আপনার বর্তমান অবস্থান অনুযায়ী তৈরি করবেন, পাঁচ বছর আগে হাজার মানুষের একটি ইঞ্জিনিয়ারিং অর্গানাইজেশন কোথায় ছিল তা দেখে নয়।
যখন প্রবৃদ্ধি পুরনো নিয়মগুলো ভেঙে ফেলে
এখানে এমন কিছু আছে যা লিডারশিপ প্রায়ই মিস করে। কোম্পানি যত বড় হয়, ডেডলাইনকেও তত বাড়াতে হয়। প্রসেসগুলো বিস্তৃত হয়। নতুন মানুষ যোগ দেয় এবং তাদের অনবোর্ডিং প্রয়োজন হয়। কাজ বহুগুণ বেড়ে যায় কারণ আরও বেশি প্রোডাক্ট তৈরি হয়। কমপ্লায়েন্স রিকয়ারমেন্টগুলো স্তূপাকারে জমা হয়—অভ্যন্তরীণ নিরাপত্তা পর্যালোচনা, বাহ্যিক অডিট, ডেটা গভর্নেন্স চেক। কাজের পরিধি বাড়ে, কিন্তু ফিনিশ লাইনটি আগের মতোই স্থির থাকে।
কাজের চাপ বাড়িয়ে একই ডেডলাইন ব্যবহার করলে টিম দ্রুততর হয় না। বরং তারা অগোছালো হয়ে পড়ে। কাজের ফাঁকি দেওয়া হয়। ডকুমেন্টেশন হারিয়ে যায়। ইনসিডেন্ট রেসপন্স পুরোপুরি রিঅ্যাক্টিভ হয়ে পড়ে। যে ইঞ্জিনিয়াররা একসময় ক্লিন কোড শিপ করতেন, তারা এখন কেবল সাময়িক সমাধান বা 'ব্যান্ডেজ' শিপ করছেন কারণ ক্যালেন্ডার নমনীয় হতে নারাজ।
যদি একটি কোম্পানি বড় পরিসরে গতি চায়, তবে তাদের হয় কাজের সমান্তরাল ট্র্যাক যোগ করতে হবে অথবা সময়সীমা বাড়াতে হবে। ক্রমবর্ধমান ব্যাকলগকে এমন একটি স্প্রিন্টে সংকুচিত করা সম্ভব নয় যা মাত্র তিনজন নতুন কর্মী নিয়োগের সময়ও যথেষ্ট কঠিন মনে হয়েছিল।
বাফার রাখা বা সময়ের মার্জিন রাখা
একটি অভ্যাস যা আপনাকে মানসিকভাবে সুস্থ রাখবে: ধরে নিন যে কিছু না কিছু ভুল হবেই। এটি হতাশাবাদ নয়। এটি বাস্তববাদ।
সিস্টেম ফেইল করে। থার্ড-পার্টি API ল্যাগ করে। প্রোডাক্ট ম্যানেজার গতকাল একজন গ্রাহকের সাথে কথা বলার কারণে রিকয়ারমেন্ট বদলে যায়। যখন আপনি সম্ভাব্য বাধা বা ঘর্ষণের কথা মাথায় রেখে পরিকল্পনা করেন, তখন আপনার ডেডলাইনগুলো বাস্তবসম্মত থাকে। আপনি গতি এবং কোয়ালিটির মধ্যে বেছে নেওয়ার ক্ষমতা অর্জন করেন। সেই বাফার ছাড়া, প্রতিবার সিদ্ধান্ত আপনার হয়ে অন্য কেউ নিয়ে নেবে। আপনি গতি বেছে নিতে বাধ্য হবেন, যার মানে হলো আপনি কোয়ালিটি বিসর্জন দিতে বাধ্য হবেন।
সেই বাফারটিই হলো শেখার জায়গা। যদি প্রতিটি ঘণ্টা শুধুমাত্র ফিচারের কাজে ব্যয় করা হয়, তবে বিল্ড পাইপলাইন উন্নত করা, কুয়েরি লেয়ার রিফ্যাক্টর করা বা API কন্ট্রাক্ট ডকুমেন্ট করার মতো কাজের জন্য কারও হাতে সুযোগ থাকবে না। টিম চিরকাল তাদের বর্তমান গতিতেই আটকে থাকবে।
একটি ভুলের বদলে অন্য একটি ভুল
আমরা বর্তমানে একটি অদ্ভুত বিনিময়ের দিকে দ্রুত ধাবিত হচ্ছি। আমরা মানুষের ভুলের পরিবর্তে নন-ডিটারমিনিস্টিক সফটওয়্যার এরর (non-deterministic software errors) গ্রহণ করছি। লার্জ ল্যাঙ্গুয়েজ মডেলগুলো যেকোনো জুনিয়র ইঞ্জিনিয়ারের চেয়ে দ্রুত বয়লারপ্লেট (boilerplate) তৈরি করতে পারে, টেস্ট সাজেস্ট করতে পারে এবং ডকুমেন্টেশনের খসড়া তৈরি করতে পারে। কিন্তু তারা অত্যন্ত আত্মবিশ্বাসের সাথে এগুলো করে, এবং এমনভাবে ভুল করে যা...