ایک اسٹارٹ اپ میں آپ کا پہلا مہینہ ایک گہرا اثر چھوڑتا ہے۔ وہاں کوئی سست آغاز نہیں ہوتا، اور نہ ہی آئی ٹی (IT) کی جانب سے لیپ ٹاپ فراہم کرنے کے انتظار میں اورینٹیشن ویڈیوز دیکھنے کا کوئی ہفتہ ہوتا ہے۔ پہلے ہی دن، آپ سے یہ توقع کی جاتی ہے کہ آپ ایسی چیزیں بنائیں، توڑیں اور ٹھیک کریں جنہیں اصل لوگ استعمال کریں گے۔ میں نے یہ بات Treevah میں شامل ہونے کے بعد جلد ہی سیکھ لی، جو کہ ملازمت کے متلاشیوں کو ان کی درخواستوں کو منظم کرنے میں مدد دینے کے لیے ٹولز بنانے والی ایک کمپنی ہے۔ ابتدائی مرحلے کے ماحول میں تیس دن گزارنے نے مجھے سافٹ ویئر ڈویلپمنٹ کے بارے میں اس سے کہیں زیادہ سکھایا جو کوئی کلاس روم یا مقابلہ کبھی سکھا سکتا تھا۔
رفتار مسلسل اور بے رحم ہے
Treevah میں، کام آپ کے سیٹل ہونے کا انتظار نہیں کرتا۔ ٹیم پروڈکٹ کو alpha سے beta اور آخر کار production تک لے جانے کے لیے کوشاں ہے، جس کا مطلب ہے کہ ہر کام کی اپنی اہمیت ہے۔ وہاں کسی عارضی کام یا ایسے اسائنمنٹس کے لیے کوئی جگہ نہیں ہے جو کسی پروفیسر کے ان باکس میں پڑے رہ جائیں۔ جب آپ کوئی فیچر لانچ کرتے ہیں، تو وہ براہ راست ان صارفین تک پہنچتا ہے جو اپنی اگلی ملازمت کی تلاش کے دوران ڈیڈ لائنز، انٹرویوز اور فالو اپس کو ٹریک کرنے کی کوشش کر رہے ہوتے ہیں۔
اس کی رفتار تھکا دینے والی ہے۔ آپ ہر روز تیزی سے کام کرتے ہیں، اور کام کا بوجھ آپ کی توقع سے کہیں زیادہ تیزی سے بڑھتا ہے۔ ڈیڈ لائنز محض خیالی نہیں ہوتیں؛ وہ ان سنگ میلوں سے جڑی ہوتی ہیں جو یہ طے کرتے ہیں کہ آیا کمپنی مزید ملازمت کے متلاشیوں کی خدمت کر سکتی ہے یا موجودہ تجربے میں موجود خامیوں کو دور کر سکتی ہے۔ یہ بوجھ آپ کو تھکا دیتا ہے۔ لیکن یہ ایک ایسی وضاحت بھی پیدا کرتا ہے جو بڑی تنظیموں میں ملنا مشکل ہے۔ جب میں کوئی کام مکمل کرتا ہوں، تو میں اس چیز کے درمیان ایک سیدھا تعلق دیکھ سکتا ہوں جو میں نے بنائی ہے اور اس شخص کے درمیان جو اب اپنی ملازمت کی تلاش کو منظم کرنے میں آسانی محسوس کر رہا ہے۔ ملکیت کا یہ احساس نایاب ہے، اور یہی چیز تھکن کو بھی بامعنی بنا دیتی ہے۔
پروڈکشن میں مہارتیں تیزی سے بڑھتی ہیں
اس موسم گرما سے پہلے، میری زیادہ تر توانائی پبلک سپیکنگ اور ہیکاتھونز (hackathons) کی طرف تھی۔ دونوں نے مجھے دباؤ میں فوری طور پر سوچنے اور خیالات کو پیش کرنے کا طریقہ سکھایا۔ ہیکاتھونز خاص طور پر آپ کو چند گھنٹوں میں کام کرنے والے ڈیمو تیار کرنے کی تربیت دیتے ہیں۔ لیکن ایک ویک اینڈ پر کیے جانے والے پروجیکٹ، جو ججز کو متاثر کرتا ہے، اور پروڈکشن کوڈ، جسے سینکڑوں اصل صارفین کے ساتھ مقابلہ کرنا ہوتا ہے، میں ایک بڑا فرق ہے۔
Treevah میں ویب ڈویلپمنٹ پر توجہ مرکوز کرتے ہوئے ایک مہینہ گزارنے نے اس فرق کو ختم کر دیا۔ اسکول میں، پروجیکٹس حفاظتی حدود کے ساتھ آتے ہیں۔ اس کا دائرہ کار مقرر ہوتا ہے، ضروریات بہت آسان طریقے سے فراہم کی جاتی ہیں، اور اگر آپ کا ڈیٹا بیس اسکیما (database schema) ناکام ہو جائے، تو آپ اسے پریزنٹیشن سلائیڈ میں بیان کر کے بچ نکل سکتے ہیں۔ ایک اسٹارٹ اپ کے اندر، آپ کے اسکیما کو برقرار رہنا پڑتا ہے کیونکہ اصل ملازمت کے متلاشی اس میں اصل درخواست کا ڈیٹا محفوظ کر رہے ہوتے ہیں۔ فیڈ بیک لوپ فوری اور بے رحم ہوتا ہے۔ جب کوئی پیج آہستہ لوڈ ہوتا ہے یا کوئی فارم محفوظ ہونے میں ناکام رہتا ہے، تو کسی کو آپ کے گریڈ کی پرواہ نہیں ہوتی؛ انہیں اس بات کی فکر ہوتی ہے کہ کہیں وہ کوئی اہم موقع تو نہیں کھو بیٹھے۔
یہ دباؤ ترقی کرنے پر مجبور کرتا ہے۔ آپ صاف ستھرا کوڈ لکھنا اس لیے سیکھتے ہیں کیونکہ کوئی معیار ایسا نہیں مانگ رہا، بلکہ اس لیے کہ آدھی رات کو اسے ڈی بگ (debug) کرنے والے آپ ہی ہوں گے۔ آپ کوڈ ریویو کے دوران زیادہ گہرے سوالات پوچھنا سیکھتے ہیں کیونکہ ایک خراب بلڈ (build) کو ڈیپلائے کرنے کا مطلب ہے کہ اصل صارفین کو رکاوٹ کا سامنا کرنا پڑے گا۔ یہاں مواقع اسکول کے پروجیکٹس کے مقابلے میں زیادہ سخت اثر ڈالتے ہیں۔ غلطیوں کی قیمت زیادہ ہوتی ہے، اور اسی لیے سبق ذہن نشین ہو جاتے ہیں۔
بگس (Bugs) کی عاجزی سکھانے والی حقیقت
اگر کوئی ایسی غلط فہمی ہے جسے میں جڑ سے ختم کرنا چاہوں گا، تو وہ یہ ہے کہ ہر سافٹ ویئر بگ ایک ڈرامائی منطقی ناکامی ہے۔ کچھ بگس ایسے ہوتے ہیں، یقیناً۔ لیکن Treevah میں مجھے جن بگس کا سامنا کرنا پڑا، ان میں سے بہت سے حیرت انگیز طور پر معمولی تھے۔ وہ بالکل سامنے چھپے ہوئے تھے اور میری زندگی کے کئی گھنٹے ضائع کر گئے۔
دو پیٹرن بار بار سامنے آ رہے تھے۔ پہلا ڈپلیکیٹ CSS رولز تھے۔ جب متعدد ڈویلپرز کئی اسپرنٹس (sprints) کے دوران ایک ہی کمپوننٹ پر کام کرتے ہیں، تو اسٹائل شیٹس بڑھتی جاتی ہیں۔ ایک شخص مارجن یوٹیلیٹی کلاس (margin utility class) شامل کرتا ہے جبکہ دوسرا کمپوننٹ فائل میں ایک ویلیو ہارڈ کوڈ (hardcode) کر دیتا ہے۔ ان میں سے کوئی بھی اکیلے میں غلط نہیں ہے۔ لیکن مل کر وہ لے آؤٹ شفٹس (layout shifts) یا سپیسیفیسیٹی وارز (specificity wars) پیدا کرتے ہیں جو ایک بٹن کو Chrome پر ٹھیک اور Safari پر خراب دکھاتے ہیں۔ اس کا سراغ لگانے کا مطلب ہے براؤزر ڈیولپمنٹ ٹولز کھولنا اور خوبصورت الگورتھمک منطق پڑھنے کے بجائے، کمپیوٹڈ اسٹائلز (computed styles) کو لائن بہ لائن دیکھنا۔
دوسرا یہ تھا کہ ایلیمنٹس کو ان کے پیرنٹ divs سے باہر ڈیفائن کرنا۔ ایک ماڈل ٹرگر (modal trigger) یا ڈراپ ڈاؤن (dropdown) DOM میں غلط نوڈ (node) کے ساتھ جڑ سکتا ہے۔ اسکرین تقریباً ٹھیک نظر آتی ہے، اس لیے آپ فرض کر لیتے ہیں کہ ڈھانچہ درست ہے۔ پھر ایک z-index کا تصادم ظاہر ہوتا ہے، یا کلک ایونٹ غلط ہینڈلر (handler) تک پہنچ جاتا ہے، اور اچانک ایک صارف اس پاپ اپ کو ختم نہیں کر پاتا جو اس کے درخواست فارم کو ڈھانپ رہا ہوتا ہے۔ یہ کمپیوٹر سائنس کی پہیلیاں نہیں ہیں۔ یہ مکانی اور ساختی غلطیاں ہیں جو تیزی سے کام کرتے وقت بڑھتی جاتی ہیں۔
ان میں سے کچھ بگ (bugs) کو ڈھونڈنے میں ہفتوں لگ گئے۔ میں کوڈ کو گھورتا رہتا، خود کو یقین دلاتا کہ منطق درست ہے، اور ایسے بنجر راستوں پر بھٹکتا رہتا جن کا کوئی سرا نہ ملتا۔ مایوسی بالکل حقیقی ہوتی ہے۔ آپ کو ایسا محسوس ہوتا ہے کہ آپ سے کوئی واضح سی چیز چھوٹ رہی ہے، اور حقیقت میں ایسا ہی ہوتا ہے۔ لیکن آخر کار کسی دوہرے اصول یا غلط جگہ پر لگے ہوئے کلوزنگ ٹیگ کو پہچان لینے کا اطمینان حیرت انگیز طور پر