स्टार्टअप में आपका पहला महीना एक छाप छोड़ जाता है। यहाँ कोई धीमी शुरुआत नहीं होती, और न ही आईटी द्वारा लैपटॉप उपलब्ध कराने के इंतज़ार में ओरिएंटेशन वीडियो देखने वाला कोई हफ्ता होता है। पहले ही दिन, आपसे ऐसी चीज़ें बनाने, उन्हें बिगाड़ने और ठीक करने की उम्मीद की जाती है जिनका वास्तविक लोग उपयोग करेंगे। Treevah में शामिल होने के बाद मैंने यह बात जल्दी ही सीख ली, जो नौकरी चाहने वालों को उनके आवेदनों को व्यवस्थित करने में मदद करने वाले टूल्स बनाती है। शुरुआती चरण के वातावरण में बिताए तीस दिनों ने मुझे सॉफ्टवेयर डेवलपमेंट के बारे में उतना सिखाया जितना कोई क्लासरूम या प्रतियोगिता कभी नहीं सिखा सकती थी।
लय निरंतर और अथक है
Treevah में, काम आपके सेटल होने का इंतज़ार नहीं करता। टीम प्रोडक्ट को अल्फा से बीटा और अंततः प्रोडक्शन में ले जाने के लिए प्रयास कर रही है, जिसका अर्थ है कि हर कार्य का महत्व है। यहाँ केवल दिखावटी काम करने या ऐसे असाइनमेंट करने की कोई जगह नहीं है जो किसी प्रोफेसर के इनबॉक्स में पड़े रहें। जब आप कोई फीचर लॉन्च करते हैं, तो वह सीधे उन उपयोगकर्ताओं के पास जाता है जो अपनी अगली भूमिका की तलाश के दौरान डेडलाइन, इंटरव्यू और फॉलो-अप्स को ट्रैक करने की कोशिश कर रहे होते हैं।
इसकी रफ्तार थका देने वाली है। आप हर दिन तेज़ी से आगे बढ़ते हैं, और काम का बोझ आपकी उम्मीद से कहीं ज़्यादा तेज़ी से बढ़ता है। डेडलाइन केवल अमूर्त नहीं हैं; वे उन मील के पत्थरों से जुड़ी हैं जो यह तय करते हैं कि कंपनी अधिक नौकरी चाहने वालों की सेवा कर पाएगी या वर्तमान अनुभव की कमियों को दूर कर पाएगी। यह भारीपन आपको थका देता है। लेकिन यह एक ऐसी स्पष्टता भी पैदा करता है जो बड़े संगठनों में मिलना मुश्किल है। जब मैं कोई कार्य पूरा करता हूँ, तो मैं जो कुछ भी बनाता हूँ और उस व्यक्ति के बीच एक सीधा संबंध देख सकता हूँ जिसे अब अपनी नौकरी की तलाश को प्रबंधित करने में आसानी हो रही है। स्वामित्व का यह अहसास दुर्लभ है, और यही थकान को सार्थक बनाता है।
प्रोडक्शन में कौशल तेजी से निखरते हैं
इस गर्मी से पहले, मेरी अधिकांश ऊर्जा पब्लिक स्पीकिंग और हैकथॉन की ओर जाती थी। दोनों ने मुझे दबाव में त्वरित निर्णय लेना और विचारों को प्रस्तुत करना सिखाया। विशेष रूप से हैकथॉन आपको घंटों में काम करने वाले डेमो तैयार करने के लिए प्रशिक्षित करते हैं। लेकिन एक वीकेंड प्रोजेक्ट जो जजों को प्रभावित करता है, और प्रोडक्शन कोड जिसे सैकड़ों वास्तविक उपयोगकर्ताओं के साथ तालमेल बिठाकर जीवित रहना पड़ता है, उसके बीच एक अंतर है।
Treevah में वेब डेवलपमेंट पर ध्यान केंद्रित करते हुए एक महीना बिताने से वह अंतर मिट गया। स्कूल में, प्रोजेक्ट्स कुछ सीमाओं के साथ आते हैं। उनका दायरा निश्चित होता है, आवश्यकताएं परोसी जाती हैं, और यदि आपका डेटाबेस स्कीमा विफल हो जाता है, तो आप प्रेजेंटेशन स्लाइड में उसका बहाना बना सकते हैं। एक स्टार्टअप के भीतर, आपके स्कीमा को टिकना होगा क्योंकि वास्तविक नौकरी चाहने वाले इसमें वास्तविक एप्लिकेशन डेटा स्टोर कर रहे हैं। फीडबैक लूप तत्काल और कठोर होता है। जब कोई पेज धीरे लोड होता है या कोई फॉर्म सेव नहीं हो पाता, तो किसी को आपके ग्रेड की परवाह नहीं होती; उन्हें इस बात की परवाह होती है कि क्या उन्होंने अभी एक अवसर खो दिया है।
वह दबाव विकास के लिए मजबूर करता है। आप साफ-सुथरा कोड लिखना इसलिए सीखते हैं क्योंकि कोई मापदंड इसकी मांग नहीं करता, बल्कि इसलिए क्योंकि आधी रात को उसे डीबग करने वाले आप ही होंगे। आप कोड रिव्यू के दौरान अधिक सटीक प्रश्न पूछना सीखते हैं क्योंकि एक खराब बिल्ड को डिप्लॉय करने का मतलब है कि वास्तविक उपयोगकर्ता एक बाधा का सामना करेंगे। यहाँ के अवसर स्कूल प्रोजेक्ट्स की तुलना में कहीं अधिक प्रभावशाली होते हैं। गलतियों की कीमत अधिक होती है, और इसलिए सबक भी गहरे होते हैं।
बग्स की कड़वी सच्चाई
यदि कोई एक मिथक है जिसे मैं मिटाना चाहूँगा, तो वह यह विचार है कि हर सॉफ्टवेयर बग एक नाटकीय तार्किक विफलता है। कुछ तो होते ही हैं। लेकिन Treevah में मुझे जिन बग्स का सामना करना पड़ा, उनमें से कई परेशान करने वाले रूप से छोटे थे। वे सामने ही छिपे रहते थे और मेरे जीवन के घंटों बर्बाद कर देते थे।
दो पैटर्न बार-बार दिखाई दे रहे थे। पहला था डुप्लिकेट CSS नियम। जब कई डेवलपर्स कई स्प्रिंट्स में एक ही कंपोनेंट पर काम करते हैं, तो स्टाइलशीट बढ़ जाती है। एक व्यक्ति मार्जिन यूटिलिटी क्लास जोड़ता है जबकि दूसरा कंपोनेंट फ़ाइल में एक वैल्यू को हार्डकोड कर देता है। अलग-अलग तौर पर कोई भी गलत नहीं है। लेकिन साथ मिलकर वे लेआउट शिफ्ट्स या स्पेसिफिसिटी वॉर (specificity wars) पैदा करते हैं जो एक बटन को Chrome पर ठीक और Safari पर टूटा हुआ दिखाते हैं। उन्हें ढूँढने का मतलब है ब्राउज़र देव टूल्स खोलना और सुंदर एल्गोरिथम लॉजिक पढ़ने के बजाय कंप्यूटेड स्टाइल्स को लाइन दर लाइन खंगालना।
दूसरा था तत्वों (elements) को उनके पैरेंट डिव्स (parent divs) के बाहर परिभाषित करना। एक मोडल ट्रिगर या ड्रॉपडाउन DOM में गलत नोड पर जुड़ सकता है। स्क्रीन लगभग सही दिखती है, इसलिए आप मान लेते हैं कि संरचना सही है। फिर एक z-index संघर्ष (conflict) दिखाई देता है, या एक क्लिक इवेंट गलत हैंडलर तक पहुँच जाता है, और अचानक एक उपयोगकर्ता उस पॉपअप को नहीं हटा पाता जो उनके एप्लिकेशन फॉर्म को ढक रहा होता है। ये कंप्यूटर साइंस की पहेलियाँ नहीं हैं। ये स्थानिक और संरचनात्मक गलतियाँ हैं जो तेज़ गति से काम करते समय बढ़ जाती हैं।
इनमें से कुछ बग्स को खोजने में हफ़्तों लग गए। मैं कोड को घूरता रहता, खुद को यकीन दिलाता कि लॉजिक सही है, और ऐसे बंद रास्तों पर भटकता जाता जिनका कोई अंत नहीं था। हताशा वास्तविक होती है। आपको लगता है कि आप कुछ स्पष्ट चीज़ मिस कर रहे हैं, और आप वास्तव में कर रहे होते हैं। लेकिन अंततः एक डुप्लिकेट नियम या गलत जगह लगे क्लोजिंग टैग को ढूंढ निकालने का संतोष आश्चर्यजनक रूप से