نوسکھئیے پروگرامرز کی طرف سے کی جانے والی عام غلطیوں کا تجزیہ، pt. 2

ہیلو پھر، سب! ہم ان مسائل پر غور کرتے رہیں گے جن کا سامنا ایک نوجوان اور نادان پروگرامر کو اپنی پہلی ملازمت میں کرنا پڑ سکتا ہے۔ پہلا حصہ یہاں پایا جا سکتا ہے ۔ آئیے جاری رکھیں۔

13. کوڈنگ طرز کے رہنما خطوط کی تعمیل کرنے میں ناکامی۔

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

14. غلطیوں سے حوصلہ شکنی

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

15. تھریڈ سیفٹی کو نافذ کرنے میں ناکامی۔

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

16. زیادہ کام کرنا

فلم "فائٹ کلب" (1999) سے شاید ہر ابتدائی سوچتا ہے کہ رات کو کام کرنے سے، وہ مزید کاموں کو مکمل کرنا شروع کر دے گا اور اسے زیادہ ذمہ داری سونپی جائے گی۔ میں بھی ایسا ہی سوچتا تھا لیکن اب نہیں۔ میں نے دیکھا کہ ایک نقطہ ایسا آتا ہے جب آپ اپنی حد کو مارتے ہیں، جب آپ مناسب طریقے سے سوچنا چھوڑ دیتے ہیں۔ آپ کافی مدھم ہونے لگتے ہیں اور ذہنی دھند کا تجربہ کرتے ہیں۔ وہ کام کرنے میں ایک گھنٹہ لگتا ہے جو آپ 10 منٹ میں کر سکتے ہیں اگر آپ کا دماغ تازہ ہو۔ تقریباً بغیر کسی استثناء کے، تھکاوٹ کی اس لکیر کو عبور کرنے کے بعد، آپ کو کچھ ایسی پریشانی کا سامنا کرنا پڑتا ہے جو ناقابل تسخیر معلوم ہوتا ہے۔ لیکن جب آپ اگلی صبح کام پر آتے ہیں تو آپ اسے پلک جھپکتے ہی حل کر دیتے ہیں۔ لہٰذا جب آپ محسوس کریں کہ آپ اس مقام پر پہنچ گئے ہیں، تو دیر تک نہ رہیں۔ بس گھر جاؤ اور اچھا آرام کرو۔ بہر حال، اگر آپ رات گئے تک اپنی میز پر رہیں گے، تو نہ صرف آپ عذاب کے ان گھنٹوں کے دوران خاص طور پر شاندار نتائج حاصل نہیں کر پائیں گے، بلکہ ساتھ ہی ساتھ آپ کو اگلے کام کے دن سے پہلے ناقص (ناکافی) آرام کا خطرہ ہے، جب آپ ایک بار پھر بگاڑ دیں گے۔ اپنی صحت کے بارے میں سوچیں: کیا آپ کے کیریئر کے آغاز میں اس کو اس طرح کمزور کرنا مناسب ہے؟ مجھے نہیں لگتا. بیمار ہونا ایک مہنگا وقت ہے۔ اور اپنے آجر کے بارے میں سوچیں۔ اپنے آپ کو زیادہ کام کرنے سے، آپ چیزوں کو نہ صرف اپنے لیے، بلکہ اپنے آجر کے لیے بھی بدتر بناتے ہیں۔ کس کو ایسے ملازم کی ضرورت ہے جو مستقل طور پر سو رہا ہو، جو تھکن کی وجہ سے آسان ترتیب دینے والے الگورتھم کو نافذ نہیں کر سکتا؟ ہاں، بلاشبہ ایسے اوقات ہوتے ہیں جب آپ کے پاس ایک گرم آخری تاریخ ہوتی ہے، ایسے وقت ہوتے ہیں جب سب کچھ غلط ہو جاتا ہے، اور ایسے اوقات جب - اور یہ میرا ذاتی پسندیدہ ہوتا ہے - "ہمیں کل اس کی ضرورت ہوتی ہے"۔ لیکن یہ حالات عام طور پر نایاب ہوتے ہیں، اور ایک بار جب آپ ان سے گزر جاتے ہیں، تو آپ کو بیٹھ کر غور سے غور کرنے کی ضرورت ہے کہ یہ کیسے ہو سکتے ہیں اور مستقبل میں ان سے کیسے بچنا ہے۔

17. انگریزی کی مہارت کو نظر انداز کرنا

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

18. جدید ٹیکنالوجی کا حصول

جیسے ہی ڈویلپرز اپنے راستے پر چلنا شروع کرتے ہیں، وہ اکثر جدید ترین ٹیکنالوجیز کو برقرار رکھنے کی کوشش کرتے ہیں۔ کیا ایسا کرنا صحیح ہے؟ ایک طرف، ہاں: جدید ترین ٹیکنالوجیز، منصوبے... لیکن کیا اسے اولین ترجیح بنانا اس کے قابل ہے؟ شاید اپنے شعبے کے ماہر کے لیے "کلاسک ٹول کٹ" کا پیچھا کرنا بہتر ہے؟ نیا یقیناً اچھا ہے، لیکن آپ کو اپنے فیلڈ کی بنیادی ٹیکنالوجیز کو نہیں بھولنا چاہیے۔ اور تب ہی، جب آپ نے بنیادی باتوں کا تھوڑا سا تجربہ اور گہرا علم حاصل کر لیا ہو، آپ کچھ نیا کرنے کی کوشش کر سکتے ہیں۔ اس بات پر بھی غور کریں کہ نئی ٹیکنالوجیز کچھ لطیف طریقوں سے بہتر ہو سکتی ہیں، لیکن وہ دوسروں میں فوائد کھو سکتی ہیں۔ جب تک کوئی نیا ڈویلپر ان تجارتی معاہدوں کو نہیں سمجھتا، اس وقت تک جانچے گئے حلوں پر قائم رہنا بہتر ہے۔ مثال کے طور پر، اگر کوئی پروگرامر کوئی ایسی ایپلی کیشن تیار کر رہا ہے جو کچھ ڈیٹا کے ساتھ تعامل کرتا ہے، تو جدید ترین NoSQL حل استعمال کرنے میں جلدی نہ کریں کیونکہ یہ فیشن میں ہے۔ ایک عام آزمایا ہوا اور سچا SQL ڈیٹا بیس (MySQL، PostrgreSQL، وغیرہ) میں ممکنہ طور پر کسی بھی ممکنہ مسائل کے لیے StackOverFlow پر تفصیلی دستاویزات اور حل موجود ہیں :)

19. ایک ساتھ کئی مختلف ٹیکنالوجیز اور/یا زبانیں سیکھنا

ہم نے اوپر فیشن ایبل ٹیکنالوجیز سیکھنے کی کوشش کرنے والوں کے بارے میں بات کی۔ ٹھیک ہے، بیک وقت بہت سی ٹیکنالوجیز یا زبانوں کا مطالعہ کرنے کے بارے میں کیا خیال ہے؟ ظاہر ہے، آپ نے ایسے پروگرامرز کے بارے میں سنا ہے جو ایک سے زیادہ پروگرامنگ زبان جانتے ہیں اور بہت سی ٹیکنالوجیز میں مہارت حاصل کر چکے ہیں۔ لیکن میں جلدی سے اس بات کی نشاندہی کروں گا کہ یہ لوگ پروگرامنگ میں نئے نہیں ہیں۔ یہ وہ لوگ ہیں جن کے پیچھے کئی سالوں کا تجربہ ہے۔ انہوں نے اپنی اصل ٹیکنالوجی میں مہارت حاصل کی ہے اور پھر مزید آگے بڑھ گئے ہیں۔ ایک ہی وقت میں ہر چیز پر عبور حاصل کرنے کی کوشش کرنے والوں کو بہترین کہاوت یاد رکھنی چاہئے: "دو خرگوشوں کا پیچھا کرو اور تم دونوں میں سے کسی کو نہیں پکڑو گے۔" اس کا نتیجہ یہ ہو سکتا ہے کہ آپ کسی بھی موضوع پر اچھی طرح عبور حاصل نہیں کر پائیں گے، بلکہ صرف سطحی طور پر مضامین سیکھیں گے۔ ایک ایسے ماہر کی زیادہ مانگ ہوگی جو کسی ایک زبان کو گہرائی سے جانتا ہو اس کے مقابلے میں جو ہر چیز کے بارے میں تھوڑا سا جانتا ہو۔ لہذا اگر آپ بہت سی زبانیں اور ٹیکنالوجیز جاننا چاہتے ہیں، تو آپ کو ان سے سمجھداری سے رجوع کرنے کی ضرورت ہے۔ شروع کرنے کے لیے، آپ کو ایک بنیادی، بنیادی زبان کا انتخاب کرنا ہوگا جسے آپ کو گہرائی سے سیکھنا چاہیے۔ اور تب ہی آپ کو دوسرے شعبوں کا مطالعہ شروع کرنا چاہیے۔ مثال کے طور پر، جاوا گرو بنیں، پھر ازگر کو دوسری زبان کے طور پر سیکھیں۔ اس کے بعد، آپ فرنٹ اینڈ کے لیے ری ایکٹ/اینگولر کے بارے میں کچھ سیکھ سکتے ہیں۔ اس معاملے میں، ہم ان ٹیکنالوجیز کے بارے میں بات کر رہے ہیں جو قابل تبادلہ نہیں ہیں، جیسے کہ C# اور Java، بلکہ آپ کے کیریئر کے مواقع کو بڑھاتے ہوئے تکمیلی ہیں۔ لیکن میں ایک بار پھر دہراتا ہوں: آپ کو ایک ساتھ سب کچھ سیکھنے کی کوشش نہیں کرنی چاہیے۔ آپ کو ترتیب وار جانا ہوگا۔ ایک وقت میں ایک خرگوش پکڑو، تو بات کرنے کے لیے۔

20. غلط طریقے سے وضع کردہ اہداف

آپ اپنے لیے اہداف کیسے طے کرتے ہیں؟ ایک ٹھنڈا ڈویلپر بنیں؟ اسے ایک بار اور ہمیشہ کے لیے یاد رکھیں: آپ کو ٹھوس اہداف مقرر کرنے کی ضرورت ہے، یا دوسرے لفظوں میں - قابل حصول اہداف۔ میں کس بارے میں بات کر رہا ہوں؟ مثال کے طور پر، آپ نے اپنے آپ کو ہدف مقرر کیا: "میں امیر بننا چاہتا ہوں"۔ لیکن آپ کو کیسے پتہ چلے گا کہ آپ نے یہ مقصد حاصل کر لیا ہے؟ یا آپ کیسے اندازہ لگاتے ہیں کہ آپ اسے حاصل کرنے کے کتنے قریب ہیں؟ ٹھیک ہے، اگر آپ "میں ایک ملین ڈالر کمانا چاہتا ہوں" کا ہدف طے کرتے ہیں، تو یہ قدرے واضح ہے، ہے نا؟ ایک بار جب آپ نے $10,000 کما لیے ہیں، تو آپ $10,000 اپنے ہدف کے قریب پہنچ گئے ہیں — صرف $990,000 جانا باقی ہے۔ حاصل کرنے کے لیے ابھی بہت کچھ باقی ہے، لیکن آپ اپنی ترقی کو محسوس کر سکتے ہیں اور سمجھ سکتے ہیں کہ فنش لائن کہاں ہے، اس لیے آپ آگے بڑھنے کے لیے حوصلہ افزائی کریں گے۔ اپنے کیریئر کے لحاظ سے، اپنے آپ کو ایک زیادہ ٹھوس مقصد قائم کرنے کے بارے میں کیا خیال ہے؟ مثال کے طور پر: میں ٹیم لیڈ بننا چاہتا ہوں۔ یا ایک سینئر دیو۔ یا بالآخر ایک معمار۔ ٹھیک ہے، ہر بڑے کام کو چھوٹے ذیلی کاموں میں تقسیم کرنے کی ضرورت ہے۔ آپ اپنے کیریئر کے آغاز میں ٹیم لیڈ نہیں بنتے ہیں۔ اگر ممکن ہو اور مناسب ہو تو آخری تاریخ مقرر کریں، اور موجودہ مرحلے پر توجہ دیں۔

1. اگر ہم سینئر ڈویلپر بننے کے بارے میں بات کر رہے ہیں، تو پہلا چھوٹا مقصد کسی کمپنی میں ایک انٹرن شپ یا جونیئر ڈویلپر کے طور پر نوکری تلاش کرنا ہوگا۔
2. اگلا، آپ مخصوص ٹیکنالوجیز کے بارے میں اپنے علم کو گہرا کرنے کے لیے اہداف مقرر کر سکتے ہیں۔ جاوا کے حوالے سے، آپ اوریکل کے لیول 1 سرٹیفیکیشن کے لیے تیاری کر سکتے ہیں۔ ہم اپنی تیاری کے لیے ایک ٹائم فریم قائم کرتے ہیں اور ہدف سے نمٹتے ہیں۔
3. پھر، مثال کے طور پر، آپ اپنی انگریزی کو ایک درجے تک بہتر بنانے کا ہدف مقرر کر سکتے ہیں (کہیں، B1 سے B2 تک)۔ ہم ایک سیکھنے کا منصوبہ بناتے ہیں، وقت طے کرتے ہیں، اور مقصد کی طرف بڑھتے ہیں۔

اس طرح ہم اپنے حتمی مقصد کو مرحلہ وار حاصل کر سکتے ہیں (سافٹ ویئر ڈیولپمنٹ کا تجربہ حاصل کرتے ہوئے)۔

21. تھیوری بغیر پریکٹس کے

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

22. حد سے زیادہ کمال پرستی

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

23. فن تعمیر کے بارے میں سوچنے میں ناکامی۔

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

24. امپوسٹر سنڈروم

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

25. شاذ و نادر ہی عہد کرنا

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