ایک پروجیکٹ پر جاوا ڈویلپر کے مخصوص کام

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

1. نئے حل تیار کرنا

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

2. نئی فعالیت لکھنا

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

3. تحریری ٹیسٹ

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

4. کیڑے تلاش کرنا اور درست کرنا

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

5. کوڈ کا جائزہ

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

6. کوڈ کا تجزیہ

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

7. ریفیکٹرنگ کوڈ

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

8. تحریری دستاویزات

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

9. مختلف ملاقاتیں۔

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

10. انٹرویوز کا انعقاد/ پاس کرنا

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