آپ کا کام صرف کوڈ لکھنا نہیں ہے۔ یہ فیصلے کرنا ہے۔ آپ ان سے سیکھتے ہیں۔ وقت کے ساتھ ساتھ آپ کی غلطیاں کم ہوتی جاتی ہیں۔ آخر کار، آپ دوسروں کی اسی دھند سے گزرنے میں رہنمائی کرتے ہیں۔ وہ سفر—صرف منطق (logic) لکھنے سے لے کر نتائج کی ذمہ داری لینے تک—وہ چیز ہے جو ایک ایسے شخص کو جو صرف کوڈ ٹائپ کرتا ہے، اس سے الگ کرتی ہے جو سسٹم بناتا ہے۔

آپ ہر روز انتخاب کرتے ہیں۔ کچھ فیصلے معمولی محسوس ہوتے ہیں، جیسے کسی بٹن کا رنگ چننا۔ دوسرے پورے پروڈکٹ کی بنیاد بدل دیتے ہیں۔ اصل مہارت یہ پہچاننے میں ہے کہ یہ دونوں ایک دوسرے سے جڑے ہوئے ہیں۔ لاپرواہی سے کیا گیا ایک چھوٹا سا فیصلہ بعد میں ایک بڑی رکاوٹ بن سکتا ہے، جبکہ شروع میں کیا گیا ایک مشکل فیصلہ اکثر ماضی میں دیکھنے پر ذہانت معلوم ہوتا ہے۔

ابتدائی فیصلوں کا اثر (Blast Radius)

جب آپ شروعات کر رہے ہوتے ہیں، تو آپ کی غلطیوں کی گونج ایک چھوٹے سے کمرے تک محدود ہوتی ہے۔ ایک غلط commit مقامی build کو توڑ دیتا ہے۔ ایک ناقص function ایک اسکرین کو سست کر دیتا ہے۔ اس کا اثر (blast radius) محدود رہتا ہے۔ آپ بہت کم لوگوں کو متاثر کرتے ہیں، اور اس کی بحالی پر بہت کم خرچ آتا ہے۔

لیکن جیسے جیسے آپ ترقی کرتے ہیں، چاہے بطور انفرادی انجینئر یا بطور کمپنی، آپ کے فیصلے مزید کئی سسٹمز پر اثر انداز ہوتے ہیں۔ بڑے پیمانے پر کیا گیا وہی فیصلہ ہفتوں کا نقصان کر سکتا ہے۔ یہی وجہ ہے کہ آپ کو اب سے ہی حساب کتاب کے ساتھ فیصلے کرنا سیکھنا چاہیے، اس سے پہلے کہ اس کی قیمت بہت زیادہ ہو جائے۔

تین عام جالوں کے بارے میں سوچیں:

  • ایسا پلیٹ فارم استعمال کرنا جسے آپ کی dependencies سپورٹ نہ کریں، انجینئرنگ کے درجنوں یا سینکڑوں گھنٹے ضائع کر سکتا ہے۔ وہ گھنٹے صرف ٹائپنگ میں نہیں گزرتے۔ بلکہ وہ عجیب و غریب مطابقت (compatibility) کے مسائل حل کرنے، transitive libraries کو ٹھیک کرنے، اور اسٹیک ہولڈرز کو یہ سمجھانے میں گزرتے ہیں کہ ایک سادہ سا فیچر ایک مکمل سہ ماہی (quarter) کیوں لے گیا۔

  • پروڈکٹ کی زندگی کے ابتدائی مرحلے میں session-based authentication سے JWTs پر منتقل ہونا بعد میں ہونے والی مہنگی rewrite سے بچاتا ہے۔ جب آپ کے پاس ہزاروں صارفین ہوں تو لاگ ان لاجک کو refactor کرنا بہت آسان ہوتا ہے، اس کے مقابلے میں جب آپ کے پاس لاکھوں صارفین ہوں اور downtime کا مطلب اصل رقم کا نقصان ہو۔

  • وقت کا اندازہ اپنے بہترین اندازے سے دوگنا لگانا صرف اس صورت میں کام کرتا ہے اگر آپ اس اضافی وقت (buffer) کو معیار (quality) کے تحفظ کے لیے استعمال کریں۔ صرف سوشل میڈیا اسکرول کرنے کے لیے شیڈول میں وقت بڑھانا فضول ہے۔ اسے ٹیسٹ لکھنے، edge cases کا جائزہ لینے، اور observability کی تصدیق کے لیے بڑھانا ایک سرمایہ کاری ہے۔

یہاں پیٹرن سادہ ہے: technical debt بڑھتا چلا جاتا ہے۔ جب اصل رقم (principal) کم ہو، تبھی اسے ادا کر دیں۔

ڈیڈ لائنز اور کنٹرول کا وہم

ڈیڈ لائنز ہر جگہ ہیں۔ ریلیز کی تاریخیں، ڈیمو کی تاریخیں، code freezes۔ بڑی کمپنیوں میں یہ اکثر تکنیکی مقصد سے زیادہ نفسیاتی مقصد پورا کرتی ہیں۔ یہ پیچیدگیوں پر کنٹرول کا ایک ایسا احساس پیدا کرتی ہیں جسے کوئی بھی مکمل طور پر نہیں سمجھتا۔

اس کا ضمنی اثر (side effect) قابلِ پیش گوئی ہے۔ جیسے جیسے ڈیڈ لائن قریب آتی ہے، معیار گر جاتا ہے۔ ٹیمیں ٹیسٹ ختم کر دیتی ہیں، error handling کو کمنٹ آؤٹ کر دیتی ہیں، اور ایسا کوڈ ریلیز کر دیتی ہیں جسے کوئی برقرار (maintain) نہیں رکھنا چاہتا۔ ڈیڈ لائن پوری ہو جاتی ہے۔ کیلنڈر صاف نظر آتا ہے۔ لیکن پروڈکٹ خراب ہو جاتا ہے۔

ایسا اس لیے ہوتا ہے کیونکہ انجینئرز مکمل کوڈ اور بہترین آرکیٹیکچر (architecture) پسند کرتے ہیں۔ یہ ہماری فطرت میں ہے۔ لیکن ایک مکمل جواب ہمیشہ موجود نہیں ہوتا۔ صحیح انتخاب وہ ہے جو آپ کی ٹیم کی موجودہ حالت کے مطابق ہو۔ تین افراد کے اسٹارٹ اپ کو اس طرح کی رسمی کارروائیوں کی ضرورت نہیں ہوتی جیسی ایک ریگولیٹڈ ہیلتھ کیئر پلیٹ فارم کو ہوتی ہے۔ آپ اس مقام کے لیے تعمیر کرتے ہیں جہاں آپ موجود ہیں، نہ کہ اس مقام کے لیے جہاں پانچ سال پہلے ایک ہزار افراد پر مشتمل انجینئرنگ تنظیم تھی۔

جب ترقی پرانے اصولوں کو توڑ دیتی ہے

یہاں ایک ایسی چیز ہے جسے قیادت (leadership) اکثر نظر انداز کر دیتی ہے۔ جیسے جیسے کمپنی بڑھتی ہے، ڈیڈ لائنز کو بھی بڑھنا چاہیے۔ عمل (processes) پھیلتے ہیں۔ نئے لوگ شامل ہوتے ہیں اور انہیں آن بورڈنگ (onboarding) کی ضرورت ہوتی ہے۔ کام بڑھتے جاتے ہیں کیونکہ مزید پروڈکٹس موجود ہوتے ہیں۔ تعمیل (compliance) کی ضروریات بڑھتی جاتی ہیں—اندرونی سیکیورٹی ریویوز، بیرونی آڈٹ، ڈیٹا گورننس چیکس۔ سطح کا پھیلاؤ بڑھتا ہے، لیکن فنش لائن (finish line) وہیں جمی رہتی ہے۔

زیادہ کام کے ساتھ وہی پرانی ڈیڈ لائنز استعمال کرنے سے ٹیم تیز نہیں ہوتی۔ بلکہ وہ لاپرواہ ہو جاتی ہے۔ کام میں کوتاہیاں کی جاتی ہیں۔ دستاویزات (documentation) غائب ہو جاتی ہیں۔ حادثات کا ردعمل (incident response) محض ری ایکٹو (reactive) ہو کر رہ جاتا ہے۔ وہی انجینئرز جو کبھی صاف ستھرا کوڈ ریلیز کرتے تھے، اب صرف وقتی حل (bandages) فراہم کرتے ہیں کیونکہ کیلنڈر لچک دکھانے سے انکار کر دیتا ہے۔

اگر کوئی کمپنی بڑے پیمانے پر رفتار چاہتی ہے، تو اسے یا تو کام کے متوازی ٹریکس (parallel tracks) شامل کرنے ہوں گے یا ٹائم لائنز کو بڑھانا ہوگا۔ آپ ایک بڑھتے ہوئے بیک لاگ (backlog) کو اس اسپرنٹ (sprint) میں نہیں سمیٹ سکتے جو تین ہائرنگز پہلے تنگ محسوس ہوتا تھا۔

بفر (Buffer) کا استعمال

ایک عادت جو آپ کو ذہنی طور پر مستحکم رکھے گی: یہ فرض کر لیں کہ کچھ نہ کچھ غلط ہو جائے گا۔ یہ مایوسی نہیں ہے۔ یہ حقیقت پسندی ہے۔

سسٹمز فیل ہوتے ہیں۔ تھرڈ پارٹی APIs سست ہو جاتی ہیں۔ ضروریات بدل جاتی ہیں کیونکہ کل ایک پروڈکٹ مینیجر نے کسی کسٹمر سے بات کی ہوتی ہے۔ جب آپ مشکلات (friction) کے لیے منصوبہ بندی کرتے ہیں، تو آپ کی ڈیڈ لائنز ایماندار رہتی ہیں۔ آپ رفتار اور معیار کے درمیان انتخاب کرنے کی صلاحیت حاصل کرتے ہیں۔ اس بفر کے بغیر، ہر بار انتخاب آپ کے لیے پہلے ہی کر دیا جاتا ہے۔ آپ کو رفتار کا انتخاب کرنے پر مجبور کیا جاتا ہے، جس کا مطلب ہے کہ آپ کو معیار کی قربانی دینی پڑتی ہے۔

That buffer is also where learning lives. If every hour is allocated to feature work, no one has space to improve the build pipeline, refactor the query layer, or document the API contract. The team stays stuck at its current velocity forever.

Replacing One Error for Another

We are currently rushing into a strange trade. We are replacing human errors with non-deterministic software errors. Large language models can generate boilerplate, suggest tests, and draft documentation faster than any junior engineer. But they do it with confidence, and they do it wrong in ways that are