स्टार्टअपमधील तुमचा पहिला महिना एक छाप पाडतो. तिथे कामाची सुरुवात हळूहळू होत नाही, किंवा वाट पाहत असताना ओरिएंटेशन व्हिडिओ पाहण्यात जाणारा आठवडा नसतो.

स्टार्टअपमधील तुमचा पहिला महिना एक छाप सोडतो. तिथे हळूहळू शिकण्याची प्रक्रिया नसते, किंवा आयटी (IT) टीमकडून लॅपटॉप मिळेपर्यंत ओरिएंटेशन व्हिडिओ पाहण्याचे आठवडे नसतात. पहिल्याच दिवशी, तुम्ही अशा गोष्टी तयार करणे, बिघडवणे आणि दुरुस्त करणे अपेक्षित असते ज्या प्रत्यक्ष लोक वापरणार आहेत. Treevah मध्ये सामील झाल्यानंतर मला हे लवकरच समजले, ही कंपनी नोकरी शोधणाऱ्यांना त्यांचे अर्ज व्यवस्थित ठेवण्यास मदत करणारी साधने बनवते. सुरुवातीच्या टप्प्यातील वातावरणात घालवलेल्या तीस दिवसांनी मला सॉफ्टवेअर डेव्हलपमेंटबद्दल कोणत्याही वर्गापेक्षा किंवा स्पर्धेपेक्षा जास्त शिकवले.

कामाची लय अथक आहे

Treevah मध्ये, काम तुम्हाला स्थिरावण्याची वाट पाहत नाही. टीम प्रॉडक्टला अल्फा (alpha) कडून बीटा (beta) आणि शेवटी प्रोडक्शन (production) मध्ये नेण्यासाठी प्रयत्न करत आहे, याचा अर्थ प्रत्येक कामाला महत्त्व आहे. तिथे केवळ नावापुरते काम करण्यासाठी किंवा एखाद्या प्राध्यापकाच्या इनबॉक्समध्ये टाकून ठेवण्यासाठी काम करण्याची सोय नाही. जेव्हा तुम्ही एखादे फीचर (feature) रिलीज करता, तेव्हा ते थेट अशा वापरकर्त्यांकडे जाते जे आपली पुढची नोकरी शोधत असताना डेडलाईन्स, मुलाखती आणि फॉलो-अप्सचा मागोवा घेण्याचा प्रयत्न करत आहेत.

या कामाचा वेग थकवणारा आहे. तुम्ही दररोज वेगाने काम करता आणि कामाचा डोंगर तुमच्या अपेक्षेपेक्षा वेगाने वाढतो. डेडलाईन्स या केवळ अमूर्त गोष्टी नाहीत; त्या अशा टप्प्यांशी (milestones) जोडलेल्या आहेत जे ठरवतात की कंपनी अधिक नोकरी शोधणाऱ्यांना सेवा देऊ शकेल की सध्याच्या अनुभवातील त्रुटी दूर करू शकेल. हे ओझे तुम्हाला थकवते. पण यामुळे एक अशी स्पष्टता निर्माण होते जी मोठ्या संस्थांमध्ये शोधणे कठीण असते. जेव्हा मी एखादे काम पूर्ण करतो, तेव्हा मी जे बनवले आहे आणि ज्या व्यक्तीचा नोकरी शोधण्याचा प्रवास आता सोपा झाला आहे, यांच्यामध्ये मी एक थेट संबंध पाहू शकतो. मालकीची ही भावना दुर्मिळ आहे आणि ती थकवा असूनही कामाचे सार्थक करते.

प्रोडक्शनमध्ये कौशल्ये वेगाने विकसित होतात

या उन्हाळ्यापूर्वी, माझी बहुतेक ऊर्जा वक्तृत्व आणि हॅकाथॉनसाठी खर्च होत होती. या दोन्ही गोष्टींनी मला दबावाखाली विचार कसा करायचा आणि कल्पना कशा मांडायच्या हे शिकवले. विशेषतः हॅकाथॉन तुम्हाला काही तासांत काम करणारे डेमो (demos) तयार करण्याचे प्रशिक्षण देतात. परंतु, परीक्षकांना प्रभावित करणाऱ्या वीकेंड प्रोजेक्ट आणि शेकडो वास्तविक वापरकर्त्यांच्या संपर्कात आल्यावर टिकून राहणाऱ्या प्रोडक्शन कोडमध्ये मोठा फरक आहे.

Treevah मध्ये वेब डेव्हलपमेंटवर लक्ष केंद्रित करून एक महिना घालवल्यामुळे हा फरक भरून निघाला. शाळेत, प्रोजेक्ट्सना काही मर्यादा (guardrails) असतात. व्याप्ती निश्चित असते, आवश्यकता सोप्या करून दिल्या जातात आणि जर तुमचा डेटाबेस स्कीमा (database schema) बिघडला, तर तुम्ही प्रेझेंटेशन स्लाइडमध्ये त्याचे स्पष्टीकरण देऊ शकता. स्टार्टअपमध्ये, तुमचा स्कीमा टिकून राहणे आवश्यक आहे कारण वास्तविक नोकरी शोधणारे त्यात त्यांचा प्रत्यक्ष अर्ज डेटा साठवत आहेत. येथील फीडबॅक लूप (feedback loop) त्वरित आणि कठोर असतो. जेव्हा एखादे पेज लोड व्हायला उशीर होते किंवा एखादा फॉर्म सेव्ह होत नाही, तेव्हा कोणालाही तुमच्या ग्रेडची पर्वा नसते; त्यांना फक्त एवढी काळजी असते की त्यांनी एखादी संधी गमावली आहे का.

हा दबाव तुम्हाला प्रगती करण्यास भाग पाडतो. तुम्ही स्वच्छ कोड (cleaner code) लिहिण्यास शिकता, केवळ एखाद्या निकषांमुळे नाही, तर मध्यरात्री तो कोड डीबग (debug) करण्याची जबाबदारी तुमचीच असेल म्हणून. तुम्ही कोड रिव्ह्यू दरम्यान अधिक अचूक प्रश्न विचारण्यास शिकता, कारण बिघडलेले बिल्ड (broken build) तैनात करणे म्हणजे वास्तविक वापरकर्त्यांना अडथळा येणे होय. येथील संधी शाळेतील प्रोजेक्ट्सपेक्षा अधिक प्रभावी असतात. चुकांची किंमत जास्त असते आणि म्हणूनच त्यातून मिळणारे धडे कायमस्वरूपी लक्षात राहतात.

बग्सचे वास्तव आणि त्यातून मिळणारा धडा

जर मला एखादा गैरसमज नष्ट करायचा असेल, तर तो म्हणजे प्रत्येक सॉफ्टवेअर बग हा एक नाट्यमय तार्किक बिघाड असतो हा विचार. काही बग्स तसे असतातच. पण Treevah मध्ये मला आढळलेले अनेक बग्स अत्यंत किरकोळ आणि त्रासदायक होते. ते अगदी समोर असूनही दिसत नसत आणि माझ्या आयुष्यातील अनेक तास वाया घालवत होते.

दोन प्रकारचे पॅटर्न वारंवार दिसून येत होते. पहिला म्हणजे डुप्लिकेट CSS नियम. जेव्हा अनेक डेव्हलपर्स अनेक स्प्रिंट्समध्ये (sprints) एकाच कंपोनंटवर काम करतात, तेव्हा स्टाईलशीट्स वाढतात. एक व्यक्ती मार्जिन युटिलिटी क्लास (margin utility class) जोडते, तर दुसरी व्यक्ती कंपोनंट फाईलमध्ये व्हॅल्यू हार्डकोड करते. वेगळे पाहिल्यास यापैकी कोणीही चुकीचे नसते. परंतु एकत्र आल्यावर ते लेआउट शिफ्ट्स (layout shifts) किंवा स्पेसिफिसिटी वॉर्स (specificity wars) निर्माण करतात, ज्यामुळे एखादे बटण Chrome वर ठीक दिसते पण Safari वर बिघडलेले दिसते. ते शोधण्यासाठी ब्राउझर डेव्हलपर टूल्स (browser dev tools) उघडावे लागतात आणि मोहक अल्गोरिदमिक लॉजिक वाचण्याऐवजी प्रत्येक 'computed style' ओळोबाळ तपासावे लागते.

दुसरा प्रकार म्हणजे घटकांना (elements) त्यांच्या पेरेंट डिव्ह्सच्या (parent divs) बाहेर परिभाषित करणे. एखादा मॉडेल ट्रिगर (modal trigger) किंवा ड्रॉपडाउन (dropdown) DOM मधील चुकीच्या नोडला जोडला जाऊ शकतो. स्क्रीन जवळजवळ योग्य दिसते, म्हणून तुम्हाला वाटते की रचना योग्य आहे. त्यानंतर z-index संघर्ष (z-index conflict) उद्भवतो किंवा क्लिक इव्हेंट चुकीच्या हँडलरकडे जातो, आणि अचानक वापरकर्ता त्यांच्या अर्ज फॉर्मवर आलेले पॉपअप बंद करू शकत नाही. हे संगणक शास्त्रातील कोडी नाहीत. हे संरचनात्मक चुका आहेत ज्या वेगाने काम करताना अधिक प्रमाणात घडतात.

यातील काही बग्स शोधायला आठवडे लागले. मी कोडकडे टक लावून पाहायचो, लॉजिक बरोबर आहे असा स्वतःला खात्री करून घ्यायचो आणि अशा वळणांवर भटकत राहायचो ज्याचा कोणताही निष्कर्ष निघत नसे. ती हताशता खरोखर जाणवते. तुम्हाला असे वाटते की तुमच्याकडून एखादी साधी गोष्ट सुटत आहे, आणि खरंच तसंच असतं. पण शेवटी एखादा ड्युप्लिकेट नियम किंवा चुकीच्या ठिकाणी असलेला क्लोजिंग टॅग शोधल्याचे समाधान आश्चर्यकारकपणे