لائبریری بنانے کے لیے پڑھنا بند کریں۔ مسئلہ حل کرنے کے لیے پڑھنا شروع کریں۔

زیادہ تر انجینئرنگ ریڈنگ لسٹوں کا مرکز علم جمع کرنا ہوتا ہے۔ جدید انجینئرنگ رکاوٹوں (bottlenecks) کو حل کرنے پر انعام دیتی ہے۔

حال ہی میں ایک جونیئر انجینئر نے مجھے "انجینئرز کے لیے ٹاپ 10 کتابیں" کی ایک فہرست دکھائی۔ یہ دس سال پہلے کی فہرستوں جیسی ہی لگ رہی تھی۔ یہ اسی پرانے مفروضے پر مبنی تھی۔

مفروضہ یہ ہے کہ کافی کتابیں پڑھنے سے آپ ایک بہتر انجینئر بن جاتے ہیں۔ اعلیٰ کارکردگی دکھانے والی ٹیمیں اس طرح نہیں سیکھتیں۔

بہترین انجینئرز رکاوٹوں (constraints) کے گرد سیکھنے کے منصوبے بناتے ہیں۔

معیاری ریڈنگ لسٹیں یہ فرض کرتی ہیں کہ تمام علم کی اہمیت ہوتی ہے۔ حقیقت میں، انجینئرنگ کی اہمیت سیاق و سباق (context) پر منحصر ہوتی ہے۔

• ڈیٹا بیس کے مسائل کا سامنا کرنے والے بیک اینڈ انجینئر کو Agile پر کتاب کی ضرورت نہیں ہے۔ • AI inference پر بہت زیادہ خرچ کرنے والی ٹیم کو کسی عام مہارت (craftsmanship) کی کتاب کی ضرورت نہیں ہے۔ • لیٹنسی (latency) کے مسائل کا سامنا کرنے والے اسٹارٹ اپ کو لیڈرشپ فریم ورک کی ضرورت نہیں ہے۔

ان لوگوں کو اپنے سامنے موجود مخصوص رکاوٹ کے حل کی ضرورت ہوتی ہے۔ ریڈنگ لسٹیں مکمل ہونے (completeness) کے لیے بنائی جاتی ہیں۔ انجینئرنگ مطابقت (relevance) پر انعام دیتی ہے۔

ڈیٹا بیس اور نیٹ ورکنگ جیسے بنیادی اصول اب بھی اہمیت رکھتے ہیں۔ لیکن اب یہ کافی نہیں ہیں۔

جدید سسٹمز نئی رکاوٹیں لاتے ہیں۔ AI inference کی لاگت اس کی ایک بڑی مثال ہے۔ روایتی فہرستیں شاذ و نادر ہی ان مسائل کا احاطہ کرتی ہیں۔

چیلنج اب صرف درست سافٹ ویئر لکھنا نہیں ہے۔ چیلنج پروببیلسٹک (probabilistic) اجزاء پر قابل اعتماد سسٹمز بنانا ہے۔

ماضی میں، انجینئرز ڈٹرمنسٹک (deterministic) سسٹمز کے ساتھ کام کرتے تھے۔ ایک ہی ان پٹ سے ایک ہی آؤٹ پٹ حاصل ہوتا تھا۔

آج، سسٹمز مختلف طریقے سے کام کرتے ہیں۔ ایک پرامپٹ (prompt) مختلف جوابات دیتا ہے۔ ایک ایجنٹ مختلف راستے اختیار کرتا ہے۔ ماڈل اپ گریڈ آپ کے کوڈ کو تبدیل کیے بغیر رویے کو بدل دیتا ہے۔

نئے سوالات یہ ہیں: • آپ معیار کا جائزہ کیسے لیتے ہیں؟ • آپ ان تبدیلیوں کو کیسے سنبھالتے ہیں؟

یہ کوئی استثنائی صورتحال (edge cases) نہیں ہیں۔ یہ روزمرہ کے انجینئرنگ کے کام ہیں۔

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

• اگر لیٹنسی (latency) زیادہ ہے، تو بیچنگ (batching) کا مطالعہ کریں۔ • اگر سیاق و سباق (context) کا مسئلہ ہے، تو ریٹریول (retrieval) کا مطالعہ کریں۔ • اگر ایجنٹس ناکام ہو رہے ہیں، تو ایویلیوایشن (evaluation) کا مطالعہ کریں۔

یہ سیکھنے کے عمل کو براہ راست پروڈکشن سے جوڑ دیتا ہے۔ علم ایک طاقتور ذریعہ (leverage) بن جاتا ہے۔

اس لرننگ لوپ (learning loop) کو استعمال کریں:

  1. رکاوٹ کی شناخت کریں۔
  2. اس مسئلے کے لیے مخصوص ذریعہ تلاش کریں۔
  3. حل کا اطلاق کریں۔

ریڈنگ لسٹ مکمل کرنے کی کوشش کرنا چھوڑ دیں۔ سسٹم کو بہتر بنانے کی کوشش شروع کریں۔

اپنی اگلی کتاب پڑھنے سے پہلے، یہ پوچھیں: میرے سسٹم میں سب سے بڑی محدودیت کیا ہے؟

کیا یہ لیٹنسی، لاگت، بھروسہ مندی، یا مشاہدہ پذیری ہے؟

اس رکاوٹ کو ختم کرنے والا ذریعہ تلاش کریں۔ انجینئرنگ مطالعہ کا کوئی مقابلہ نہیں ہے۔ یہ رکاوٹوں کو حل کرنے کا ایک پیشہ ہے۔

سسٹم طے کرتا ہے کہ آپ کو آگے کیا سیکھنا چاہیے۔

ماخذ: https://dev.to/neilton_rocha_dev/stop-reading-to-build-a-library-start-reading-to-solve-a-problem-55ag