پروجیکٹ مینیجرز (اور وہ لوگ جو مالک بننے کا خواب دیکھتے ہیں) کے لیے وقف ہیں۔
بہت سارے کوڈ لکھنا مشکل ہے، لیکن لوگوں کو سنبھالنا اور بھی مشکل ہے! لہذا آپ کو دونوں کو کرنے کا طریقہ سیکھنے کے لیے صرف اس کتاب کی ضرورت ہے۔
کیا مضحکہ خیز کہانیوں اور سنجیدہ اسباق کو یکجا کرنا ممکن ہے؟ مائیکل لوپ (جسے تنگ حلقوں میں رینڈز کے نام سے بھی جانا جاتا ہے) کامیاب ہوئے۔ آپ کو ناقابل یقین حد تک فائدہ مند (افسانہ کے باوجود) تجربات کے ساتھ غیر حقیقی لوگوں کے بارے میں خیالی کہانیاں ملیں گی۔ اس طرح رینڈز بڑے آئی ٹی کارپوریشنز میں کام کرنے کے سالوں میں حاصل کیے گئے اپنے متنوع، بعض اوقات عجیب و غریب تجربات شیئر کرتے ہیں: Apple، Pinterest، Palantir، Netscape، Symantec، وغیرہ۔
کیا آپ پروجیکٹ مینیجر ہیں؟ یا یہ سمجھنا چاہتے ہیں کہ آپ کا باس سارا دن کیا کرتا ہے؟ رینڈز آپ کو سکھائیں گے کہ کس طرح پھولے ہوئے ترکیوں کی زہریلی دنیا میں زندہ رہنا ہے اور غیر فعال طور پر بھڑک اٹھے لوگوں کے عمومی جنون میں پنپنا ہے۔ پاگل دماغوں کی اس عجیب کمیونٹی میں اجنبی مخلوقات بھی ہیں - مینیجرز جنہوں نے، ایک صوفیانہ تنظیمی رسم کے ذریعے، بہت سے لوگوں کے منصوبوں، خیالات اور بینک اکاؤنٹس پر اقتدار حاصل کیا ہے۔
یہ کتاب کسی بھی انتظامی یا قیادت کے نسخے کے برعکس ہے۔ مائیکل لوپ کچھ بھی نہیں چھپاتا، وہ صرف اس طرح بتاتا ہے جیسے یہ ہے (شاید تمام کہانیوں کو عام نہیں کیا جانا چاہئے: پی)۔ لیکن صرف اسی طریقے سے آپ سمجھ پائیں گے کہ ایسے باس کے ساتھ کیسے زندہ رہنا ہے، گیکس اور بیوقوفوں کا انتظام کیسے کرنا ہے، اور "اس لاتعداد پروجیکٹ" کو خوش کن انجام تک کیسے پہنچانا ہے!
اقتباس۔ انجینئرنگ ذہنیت
خیالات: کیا آپ کو کوڈ لکھنا جاری رکھنا چاہیے؟
مینیجرز کے قواعد پر رینڈز کی کتاب جدید انتظامی "مسٹ ڈوز" کی ایک بہت ہی مختصر فہرست پر مشتمل ہے۔ اس فہرست کی لغویت اس حقیقت سے پیدا ہوتی ہے کہ "لازمی" کا تصور ایک قسم کا مطلق ہے، اور جب بات لوگوں کی ہو، تو بہت کم مطلق تصورات ہوتے ہیں۔ ایک ملازم کے لیے انتظام کا کامیاب طریقہ دوسرے کے لیے ایک حقیقی تباہی ہو گا۔ یہ سوچ مینیجر کی "ضروری ہے" کی فہرست میں پہلی چیز ہے:
لچکدار رہو!
یہ سوچنا کہ آپ سب کچھ پہلے ہی جانتے ہیں ایک بہت برا خیال ہے۔ ایسی صورت حال میں جہاں صرف ایک مستقل حقیقت یہ ہے کہ دنیا مسلسل بدل رہی ہے، لچک ہی واحد صحیح پوزیشن بن جاتی ہے۔
حیرت انگیز طور پر، فہرست میں دوسرا آئٹم حیرت انگیز طور پر لچکدار ہے۔ تاہم، یہ نقطہ میرا ذاتی پسندیدہ ہے کیونکہ مجھے یقین ہے کہ یہ انتظامی ترقی کی بنیاد بنانے میں مدد کرتا ہے۔ یہ پیراگراف پڑھتا ہے:
کوڈ لکھنا بند کرو!
نظریہ میں، اگر آپ مینیجر بننا چاہتے ہیں، تو آپ کو ان لوگوں پر بھروسہ کرنا سیکھنا ہوگا جو آپ کے لیے کام کرتے ہیں اور کوڈنگ کو مکمل طور پر ان کے حوالے کر دیتے ہیں۔ یہ مشورہ عام طور پر ہضم کرنا مشکل ہوتا ہے، خاص طور پر نئے ٹکسال والے مینیجرز کے لیے۔ غالباً ان کے مینیجر بننے کی ایک وجہ ترقی میں ان کی پیداواری صلاحیت ہے، اور جب چیزیں غلط ہو جاتی ہیں، تو ان کا پہلا ردعمل ان مہارتوں پر واپس آنا ہوتا ہے جس پر انہیں مکمل اعتماد ہوتا ہے، جو کہ کوڈ لکھنے کی ان کی صلاحیت ہے۔
جب میں دیکھتا ہوں کہ ایک نیا مینیجر کوڈ لکھنے میں "ڈوب جاتا ہے" تو میں اس سے کہتا ہوں: "ہم جانتے ہیں کہ آپ کوڈ لکھ سکتے ہیں۔ سوال یہ ہے کہ کیا آپ قیادت کر سکتے ہیں؟ اب آپ اکیلے اپنے لیے ذمہ دار نہیں ہیں، آپ پوری ٹیم کے لیے ذمہ دار ہیں۔ اور میں اس بات کو یقینی بنانا چاہتا ہوں کہ آپ کو کوڈ لکھنے کی ضرورت کے بغیر، آپ اپنی ٹیم کو خود ہی مسائل حل کرنے کے لیے تیار کر سکتے ہیں۔ آپ کا کام یہ معلوم کرنا ہے کہ اپنے آپ کو کیسے پیمانہ بنایا جائے۔ میں نہیں چاہتا کہ آپ صرف ایک بنیں، میں چاہتا ہوں کہ آپ جیسے بہت سے لوگ ہوں۔
اچھا مشورہ، ٹھیک ہے؟ پیمانہ۔ انتظام ذمہ داری۔ اس طرح کے عام buzzwords. یہ افسوس کی بات ہے کہ مشورہ غلط ہے۔
غلط؟
ہاں۔ مشورہ غلط ہے! مکمل طور پر غلط نہیں، لیکن اتنا غلط ہے کہ مجھے کچھ سابق ساتھیوں کو فون کرنا پڑا اور معذرت کرنا پڑی: "میرا وہ پسندیدہ بیان یاد ہے کہ آپ کو کوڈ لکھنا کیسے روکنا چاہیے؟ یہ غلط ہے! ہاں... دوبارہ پروگرامنگ شروع کریں۔ ازگر اور روبی کے ساتھ شروع کریں۔ ہاں، میں سنجیدہ ہوں! آپ کا کیریئر اس پر منحصر ہے!
جب میں نے بورلینڈ میں ایک سافٹ ویئر ڈویلپر کے طور پر اپنا کیریئر شروع کیا تو میں نے Paradox Windows ٹیم میں کام کیا، جو کہ ایک بہت بڑی ٹیم تھی۔ صرف 13 ایپلیکیشن ڈویلپر تھے۔ اگر آپ دیگر ٹیموں کے لوگوں کو شامل کرتے ہیں جو اس پروجیکٹ کے لیے اہم ٹیکنالوجیز پر مسلسل کام کر رہے تھے، جیسے کہ بنیادی ڈیٹا بیس انجن اور بنیادی ایپلیکیشن سروسز، تو آپ کو اس پروڈکٹ کی ترقی میں براہ راست 50 انجینئرز ملیں گے۔
کوئی دوسری ٹیم جس کے لیے میں نے کبھی کام نہیں کیا وہ اس سائز کے قریب بھی نہیں آتا۔ درحقیقت، ہر گزرتے سال کے ساتھ، میں جس ٹیم پر کام کرتا ہوں اس میں لوگوں کی تعداد بتدریج کم ہوتی جا رہی ہے۔ کیا ہو رہا ہے؟ کیا ہم ڈویلپرز اجتماعی طور پر ہوشیار اور ہوشیار ہو رہے ہیں؟ نہیں، ہم صرف بوجھ بانٹ رہے ہیں۔
پچھلے 20 سالوں سے ڈویلپر کیا کر رہے ہیں؟ اس وقت کے دوران ہم نے کوڈ کا ایک شیٹ لوڈ لکھا۔ کوڈ کا سمندر! ہم نے اتنا کوڈ لکھا کہ ہم نے فیصلہ کیا کہ ہر چیز کو آسان بنانا اور اوپن سورس جانا اچھا خیال ہوگا۔
خوش قسمتی سے انٹرنیٹ کی بدولت یہ عمل اب ممکن حد تک آسان ہو گیا ہے۔ اگر آپ سافٹ ویئر ڈویلپر ہیں، تو آپ اسے ابھی چیک کر سکتے ہیں! گوگل یا گیتھب پر اپنا نام تلاش کریں اور آپ کو وہ کوڈ نظر آئے گا جسے آپ طویل عرصے سے بھول چکے ہیں، لیکن جسے کوئی بھی تلاش کر سکتا ہے۔ ڈراونا، ٹھیک ہے؟ کیا آپ نہیں جانتے تھے کہ کوڈ ہمیشہ زندہ رہتا ہے؟ ہاں، وہ ہمیشہ زندہ رہتا ہے۔
ضابطہ ہمیشہ زندہ رہتا ہے۔ اور اچھا کوڈ نہ صرف ہمیشہ زندہ رہتا ہے، یہ بڑھتا ہے کیونکہ جو لوگ اس کی قدر کرتے ہیں وہ اس بات کو یقینی بناتے ہیں کہ یہ تازہ رہے۔ اعلیٰ معیار کے، اچھی طرح سے برقرار رکھنے والے کوڈ کا یہ ڈھیر اوسط انجینئرنگ ٹیم کے سائز کو کم کرنے میں مدد کرتا ہے کیونکہ یہ ہمیں نیا کوڈ لکھنے کے بجائے موجودہ کوڈ پر توجہ مرکوز کرنے اور کم لوگوں کے ساتھ اور کم وقت میں کام کرنے کی اجازت دیتا ہے۔
استدلال کی یہ لائن افسردہ کن لگتی ہے، لیکن خیال یہ ہے کہ ہم سب صرف انضمام آٹومیٹا کا ایک گروپ ہیں جو ڈکٹ ٹیپ کا استعمال کرتے ہوئے موجودہ چیزوں کے مختلف بٹس کو ایک ساتھ جوڑنے کے لیے ایک ہی چیز کا تھوڑا سا مختلف ورژن تخلیق کرتے ہیں۔ یہ سینئر ایگزیکٹوز کے درمیان سوچ کی ایک کلاسک لائن ہے جو آؤٹ سورسنگ کو پسند کرتے ہیں۔ "کوئی بھی شخص جو گوگل کو استعمال کرنا جانتا ہے اور اس کے پاس ڈکٹ ٹیپ ہے وہ یہ کر سکتا ہے! تو پھر ہم اپنی مشینوں کو بہت زیادہ پیسے کیوں دے رہے ہیں؟"
ہم ان انتظامی لوگوں کو واقعی بڑی رقم دیتے ہیں، لیکن وہ ایسی بکواس سوچتے ہیں۔ ایک بار پھر، میرا اہم نکتہ یہ ہے کہ ہمارے سیارے پر بہت سے شاندار اور بہت محنتی ڈویلپرز ہیں۔ وہ واقعی شاندار اور محنتی ہیں، حالانکہ انہوں نے تسلیم شدہ یونیورسٹیوں میں بیٹھ کر ایک منٹ بھی نہیں گزارا ہے۔ اوہ ہاں، اب ان میں سے زیادہ سے زیادہ ہیں!
میں یہ تجویز نہیں کرتا کہ آپ اپنی جگہ کے بارے میں صرف اس لیے پریشان ہونا شروع کر دیں کہ کچھ شاندار ساتھی مبینہ طور پر اس کا شکار کر رہے ہیں۔ میرا مشورہ ہے کہ آپ اس کے بارے میں فکر کرنا شروع کر دیں کیونکہ سافٹ ویئر ڈویلپمنٹ کا ارتقا شاید آپ سے زیادہ تیزی سے آگے بڑھ رہا ہے۔ آپ دس سال سے کام کر رہے ہیں، ان میں سے پانچ بطور مینیجر، اور آپ سوچتے ہیں: "میں پہلے ہی جانتا ہوں کہ سافٹ ویئر کیسے تیار کیا جاتا ہے۔" جی ہاں، آپ جانتے ہیں. الوداع…
کوڈ لکھنا بند کرو، لیکن...
اگر آپ میرے اصل مشورے پر عمل کرتے ہیں اور کوڈ لکھنا بند کر دیتے ہیں، تو آپ تخلیق کے عمل میں رضاکارانہ طور پر حصہ لینا بھی بند کر دیں گے۔ یہ اس وجہ سے ہے کہ میں فعال طور پر آؤٹ سورسنگ کا استعمال نہیں کرتا ہوں۔ آٹو میٹا تخلیق نہیں کرتے، وہ پیدا کرتے ہیں۔ اچھی طرح سے ڈیزائن کیے گئے عمل بہت سارے پیسے بچاتے ہیں، لیکن وہ ہماری دنیا میں کوئی نئی چیز نہیں لاتے ہیں۔
اگر آپ کے پاس ایک چھوٹی ٹیم ہے جو تھوڑے پیسوں کے لیے بہت کچھ کر رہی ہے، تو کوڈ لکھنا بند کرنے کا خیال میرے لیے کیریئر کا ایک برا فیصلہ لگتا ہے۔ یہاں تک کہ عفریت کمپنیوں میں ان کے لامتناہی ضوابط، عمل اور پالیسیوں کے ساتھ، آپ کو یہ بھولنے کا کوئی حق نہیں ہے کہ خود سافٹ ویئر کیسے تیار کریں۔ اور سافٹ ویئر کی ترقی مسلسل بدل رہی ہے۔ یہ ابھی بدل رہا ہے۔ آپ کے پیروں کے نیچے! اس سیکنڈ میں!
آپ کو اعتراض ہے۔ سمجھیں۔ آئیے سنتے ہیں۔
"رینڈز، میں ڈائریکٹر کی کرسی پر جا رہا ہوں! اگر میں کوڈ لکھتا رہوں تو کوئی بھی یقین نہیں کرے گا کہ میں ترقی کر سکتا ہوں۔
میں آپ سے یہ پوچھنا چاہتا ہوں: جب سے آپ اپنی "میں سی ای او بننے جا رہا ہوں!" کرسی پر بیٹھے ہیں، کیا آپ نے محسوس کیا ہے کہ آپ کی کمپنی کے اندر بھی سافٹ ویئر ڈویلپمنٹ کا منظرنامہ بدل رہا ہے؟ اگر آپ کا جواب ہاں میں ہے، تو میں آپ سے ایک اور سوال پوچھوں گا: یہ کیسے بدل رہا ہے اور آپ ان تبدیلیوں کے بارے میں کیا کرنے جا رہے ہیں؟ اگر آپ نے میرے پہلے سوال کا جواب "نہیں" میں دیا، تو آپ کو ایک مختلف کرسی پر جانے کی ضرورت ہے، کیونکہ (میں شرط لگاتا ہوں کہ) سافٹ ویئر ڈویلپمنٹ کا میدان اسی سیکنڈ میں بدل رہا ہے۔ اگر آپ آہستہ آہستہ لیکن یقینی طور پر سافٹ ویئر تیار کرنے کا طریقہ بھول جاتے ہیں تو آپ کیسے بڑھیں گے؟
میرا مشورہ یہ ہے کہ اپنی اگلی پروڈکٹ کے لیے بہت ساری خصوصیات کو لاگو کرنے کا عہد نہ کریں۔ آپ کی ٹیم کس طرح سافٹ ویئر بنا رہی ہے اس کے اوپر رہنے کے لیے آپ کو مسلسل اقدامات کرنے کی ضرورت ہے۔ آپ یہ کام بطور ڈائریکٹر اور نائب صدر دونوں کر سکتے ہیں۔ اس کے علاوہ کچھ اور؟
"اوہ، رینڈز! لیکن کسی کو ثالث بننا ہے! کسی کو بڑی تصویر دیکھنا ہے۔ اگر میں کوڈ لکھتا ہوں، تو میں نقطہ نظر کھو دوں گا۔"
آپ کو ابھی بھی ریفری بننا ہے، آپ کو ابھی بھی فیصلے نشر کرنے ہیں، اور آپ کو اب بھی ہر سوموار کی صبح اپنے ایک انجینئر کے ساتھ عمارت کے چاروں طرف چہل قدمی کرنی پڑتی ہے تاکہ اس کا ہفتہ وار "ہم سب برباد ہو جائیں" کا 30 کا نعرہ سنیں۔ منٹ. لیکن اس سب سے آگے، آپ کو انجینئرنگ کی ذہنیت کو برقرار رکھنا ہوگا، اور ایسا کرنے کے لیے آپ کو کل وقتی پروگرامر بننے کی ضرورت نہیں ہے۔
انجینئرنگ ذہنیت کو برقرار رکھنے کے لیے میری تجاویز:
- ترقی کے ماحول کا استعمال کریں۔ اس کا مطلب ہے کہ آپ کو اپنی ٹیم کے ٹولز سے واقف ہونا چاہیے، بشمول کوڈ بلڈ سسٹم، ورژن کنٹرول، اور پروگرامنگ لینگویج۔ نتیجے کے طور پر، آپ اس زبان میں ماہر ہو جائیں گے جو آپ کی ٹیم مصنوعات کی ترقی کے بارے میں بات کرتے وقت استعمال کرتی ہے۔ یہ آپ کو اپنے پسندیدہ ٹیکسٹ ایڈیٹر کا استعمال جاری رکھنے کی بھی اجازت دے گا، جو بالکل کام کر رہا ہے۔
- آپ کو کسی بھی وقت کسی بھی سطح پر اپنی مصنوعات کی وضاحت کرنے والا ایک تفصیلی آرکیٹیکچرل خاکہ تیار کرنے کے قابل ہونا چاہیے۔ اب میرا مطلب تین خلیوں اور دو تیروں والا آسان ورژن نہیں ہے۔ آپ کو پروڈکٹ کا تفصیلی خاکہ جاننا چاہیے۔ سب سے مشکل۔ نہ صرف کوئی پیارا خاکہ، بلکہ ایک ایسا خاکہ جس کی وضاحت کرنا مشکل ہے۔ یہ پروڈکٹ کی مکمل تفہیم کے لیے موزوں نقشہ ہونا چاہیے۔ یہ مسلسل بدل رہا ہے، اور آپ کو ہمیشہ معلوم ہونا چاہیے کہ کچھ تبدیلیاں کیوں ہوئیں۔
- افعال میں سے ایک کے نفاذ کو سنبھال لیں۔ میں لفظی طور پر یہ لکھ رہا ہوں کیونکہ اس نقطہ میں بہت سے پوشیدہ خطرات ہیں، لیکن مجھے واقعی یقین نہیں ہے کہ آپ کم از کم ایک خصوصیت کو لاگو کرنے کا عہد کیے بغیر پوائنٹ #1 اور پوائنٹ #2 کو پورا کر سکتے ہیں۔ کسی ایک خصوصیت کو خود نافذ کرنے سے، آپ نہ صرف ترقی کے عمل میں فعال طور پر شامل ہوں گے، بلکہ یہ آپ کو وقتاً فوقتاً "ہر چیز کے انچارج مینیجر" کے کردار سے "ایک کو لاگو کرنے کے انچارج مینیجر" کے کردار میں تبدیل کرنے کی بھی اجازت دے گا۔ افعال کی." یہ عاجزانہ اور غیر شائستہ رویہ آپ کو چھوٹے فیصلوں کی اہمیت کی یاد دلائے گا۔
- میں اب بھی ہر طرف کانپ رہا ہوں۔ ایسا لگتا ہے کہ کوئی پہلے ہی مجھ پر چیخ رہا ہے: "منیجر جس نے فنکشن کے نفاذ کو خود پر لے لیا؟! (اور میں اس سے متفق ہوں!) جی ہاں، آپ اب بھی مینیجر ہیں، جس کا مطلب ہے کہ یہ کوئی چھوٹا سا فنکشن ہونا چاہیے، ٹھیک ہے؟ ہاں، آپ کو ابھی بہت کچھ کرنا ہے۔ اگر آپ صرف فنکشن کے نفاذ کو نہیں لے سکتے ہیں، تو میرے پاس آپ کے لیے کچھ اضافی مشورہ ہے: کچھ کیڑے ٹھیک کریں۔ اس صورت میں، آپ تخلیق کی خوشی محسوس نہیں کریں گے، لیکن آپ کو اس بات کا اندازہ ہوگا کہ پروڈکٹ کیسے بنتی ہے، جس کا مطلب ہے کہ آپ کبھی بھی کام سے باہر نہیں رہیں گے۔
- یونٹ ٹیسٹ لکھیں۔ میں اب بھی یہ پروڈکشن سائیکل میں دیر سے کرتا ہوں جب لوگ پاگل ہونے لگتے ہیں۔ اسے اپنی پروڈکٹ کے لیے ہیلتھ چیک لسٹ سمجھیں۔ یہ کثرت سے کریں۔
دوبارہ اعتراض؟
"رینڈز، اگر میں کوڈ لکھتا ہوں، تو میں اپنی ٹیم کو الجھا دوں گا۔ وہ نہیں جانیں گے کہ میں کون ہوں - مینیجر یا ڈویلپر۔
Хорошо.
ہاں، میں نے کہا، "ٹھیک ہے!" مجھے خوشی ہے کہ آپ سوچتے ہیں کہ آپ صرف ڈویلپر تالاب میں تیراکی کرکے اپنی ٹیم کو الجھا سکتے ہیں۔ یہ آسان ہے: سافٹ ویئر ڈویلپمنٹ میں مختلف کرداروں کے درمیان حدیں فی الحال بہت دھندلی ہیں۔ UI لوگ وہ کام کرتے ہیں جسے بڑے پیمانے پر JavaScript اور CSS پروگرامنگ کہا جا سکتا ہے۔ ڈویلپرز صارف کے تجربے کے ڈیزائن کے بارے میں زیادہ سے زیادہ سیکھ رہے ہیں۔ لوگ ایک دوسرے کے ساتھ بات چیت کرتے ہیں اور کیڑوں کے بارے میں، دوسرے لوگوں کے کوڈ کی چوری کے بارے میں، اور اس حقیقت کے بارے میں بھی جانتے ہیں کہ مینیجر کے لیے اس بڑے پیمانے پر، عالمی، کراس پولینٹنگ انفارمیشن بچنالیا میں حصہ نہ لینے کی کوئی معقول وجہ نہیں ہے۔
اس کے علاوہ، کیا آپ کسی ایسی ٹیم کا حصہ بننا چاہتے ہیں جو آسانی سے تبدیل کیے جانے والے اجزاء پر مشتمل ہو؟ یہ صرف آپ کی ٹیم کو مزید فرتیلا نہیں بنائے گا، یہ ٹیم کے ہر رکن کو پروڈکٹ اور کمپنی کو مختلف زاویوں سے دیکھنے کا موقع فراہم کرے گا۔ آپ فرینک کا احترام کیسے کر سکتے ہیں، تعمیرات کے انچارج ایک پرسکون آدمی، اس کی تعمیر کے اسکرپٹ کی سادہ خوبصورتی کو دیکھنے کے بعد، اس سے زیادہ کسی اور چیز کا؟
میں نہیں چاہتا کہ آپ کی ٹیم الجھن اور افراتفری کا شکار ہو۔ اس کے برعکس، میں چاہتا ہوں کہ آپ کی ٹیم زیادہ مؤثر طریقے سے بات چیت کرے۔ مجھے یقین ہے کہ اگر آپ پروڈکٹ بنانے اور خصوصیات پر کام کرنے میں شامل ہیں، تو آپ اپنی ٹیم کے قریب ہوں گے۔ اور زیادہ اہم بات یہ ہے کہ آپ اپنی تنظیم کے اندر سافٹ ویئر ڈویلپمنٹ کے عمل میں مسلسل تبدیلیوں کے قریب ہوں گے۔
ترقی کرنا بند نہ کریں۔
بورلینڈ میں میرے ایک ساتھی نے ایک بار اسے "کوڈر" کہنے پر مجھ پر زبانی حملہ کیا۔
"رینڈز، کوڈر ایک بے دماغ مشین ہے! بندر! کوڈر بیکار کوڈ کی بورنگ لائنیں لکھنے کے علاوہ کوئی اہم کام نہیں کرتا ہے۔ میں کوڈر نہیں ہوں، میں ایک سافٹ ویئر ڈویلپر ہوں!"
وہ ٹھیک تھی، وہ نئے سی ای اوز کو میرے ابتدائی مشورے سے نفرت کرتی: "کوڈ لکھنا بند کرو!" اس لیے نہیں کہ میں یہ تجویز کر رہا ہوں کہ وہ کوڈر ہیں، بلکہ زیادہ اس لیے کہ میں یہ تجویز کر رہا ہوں کہ وہ اپنے کام کے سب سے اہم حصوں میں سے ایک کو نظر انداز کرنا شروع کر دیں: سافٹ ویئر ڈویلپمنٹ۔
لہذا میں نے اپنے مشورے کو اپ ڈیٹ کیا ہے۔ اگر آپ ایک اچھا لیڈر بننا چاہتے ہیں تو آپ کوڈ لکھنا بند کر سکتے ہیں، لیکن...
لچکدار بنیں۔ یاد رکھیں کہ انجینئر بننے کا کیا مطلب ہے اور سافٹ ویئر تیار کرنا بند نہ کریں۔
مصنف کے بارے میں
مائیکل لوپ ایک تجربہ کار سافٹ ویئر ڈویلپر ہے جس نے ابھی تک سلیکن ویلی نہیں چھوڑی ہے۔ گزشتہ 20 سالوں کے دوران، مائیکل نے ایپل، نیٹ اسکیپ، سیمنٹیک، بورلینڈ، پالانٹیر، پنٹیرسٹ سمیت متعدد اختراعی کمپنیوں کے لیے کام کیا ہے، اور ایک ایسے اسٹارٹ اپ میں بھی حصہ لیا جو آہستہ آہستہ فراموشی میں چلا گیا۔
کام سے باہر، مائیکل رینڈز کے تخلص کے تحت ٹیکنالوجی اور مینجمنٹ کے بارے میں ایک مشہور بلاگ چلاتا ہے، جہاں وہ قارئین کے ساتھ نظم و نسق کے شعبے میں خیالات پر تبادلہ خیال کرتا ہے، نبض پر انگلی رکھنے کی مسلسل ضرورت کے بارے میں تشویش کا اظہار کرتا ہے، اور وضاحت کرتا ہے کہ باوجود اس کے ایک پروڈکٹ بنانے کے لیے فراخ انعامات، آپ کی کامیابی آپ کی ٹیم کی بدولت ہی ممکن ہے۔ بلاگ یہاں پایا جا سکتا ہے .
مائیکل اپنے خاندان کے ساتھ ریڈ ووڈ، کیلیفورنیا میں رہتا ہے۔ وہ ہمیشہ ماؤنٹین بائیک، ہاکی کھیلنے اور ریڈ وائن پینے کے لیے وقت نکالتا ہے، کیونکہ صحت مند رہنا مصروف رہنے سے زیادہ اہم ہے۔
»کتاب کے بارے میں مزید تفصیلات یہاں پر دیکھی جا سکتی ہیں۔
»
»
Khabrozhiteley کے لیے کوپن کا استعمال کرتے ہوئے 20% ڈسکاؤنٹ - لوگوں کا انتظام کرنا
کتاب کے کاغذی ورژن کی ادائیگی پر، کتاب کا الیکٹرانک ورژن ای میل کے ذریعے بھیجا جائے گا۔
PS: کتاب کی قیمت کا 7% نئی کمپیوٹر کتابوں کے ترجمے پر جائے گا، کتابوں کی فہرست پرنٹنگ ہاؤس کے حوالے .
ماخذ: www.habr.com