- बड़े तकनीकी प्रोजेक्ट्स पर काम करते समय motivation बनाए रखने और अंत तक पहुँचना के लिए रोज़मर्रा के दिखाई देने वाले नतीजे महत्वपूर्ण होते हैं
- प्रोजेक्ट को बड़े और अस्पष्ट हिस्सों की बजाय नज़र आने वाली छोटी इकाइयों में बाँटा जाता है, और हर चरण में वास्तविक प्रगति की पुष्टि करने का तरीका चुना जाता है
- शुरुआती चरण में कसे हुए feedback loop के साथ जल्दी demo बनाना immersion और self-motivation के लिए बहुत मददगार होता है
- पहले अपने लिए ज़रूरी features विकसित करना और वास्तविक उपयोग के ज़रिए उन्हें लगातार बेहतर बनाना प्रभावी होता है
- पूर्णता से अधिक प्रगति को महत्व देना, और बार-बार छोटी सफलताओं का अनुभव हासिल करना, लंबे प्रोजेक्ट को पूरा करने तक ले जाता है
शुरुआत में
- बड़े प्रोजेक्ट की शुरुआत करते समय सबसे बड़ी चुनौती यह तय करना होती है कि शुरू कहाँ से करें
- अगर सभी components को एक साथ सोचा जाए, तो सब कुछ इतना धुंधला लग सकता है कि रुचि जल्दी कम हो जाए
- व्यवहारिक रूप से जल्दी नतीजे दिखाने वाली छोटी इकाई से शुरुआत करना महत्वपूर्ण है
- हर subproject स्वतंत्र होना चाहिए और पूरा होने के स्पष्ट संकेत देने चाहिए
- अनुभव बढ़ने के साथ प्रोजेक्ट की कुल रूपरेखा और subcomponents को बेहतर समझा जा सकता है
शुरुआती परिणाम बनाना
- शुरुआती काम में बाहरी तौर पर दिखने वाला हिस्सा कम होता है, इसलिए प्रगति नज़र नहीं आ सकती
- ऐसे समय में automated tests (जैसे unit tests) का सही इस्तेमाल करके दिखाई देने वाले परिणाम हासिल करना महत्वपूर्ण है
- उदाहरण के लिए, terminal parser बनाते समय input string के parsing result को test के ज़रिए तुरंत देखा जा सकता है
- बार-बार tests pass होने का अनुभव अपने आप में उपलब्धि का एहसास देता है
- इन छोटी सफलताओं के ज़रिए पूरे प्रोजेक्ट की प्रगति के वस्तुनिष्ठ प्रमाण लगातार जुटाए जा सकते हैं
जल्दी demo बनाना
- शुरुआती लक्ष्य परफेक्ट subcomponent नहीं, बल्कि demo के लिए पर्याप्त implementation होना चाहिए
- लंबे समय में ज़रूरी जटिलताओं (जैसे database, advanced data structures आदि) को फिलहाल टालकर सरल implementation के साथ तेज़ी से आगे बढ़ना प्राथमिकता होनी चाहिए
- 'पूर्णता प्रगति की दुश्मन बन सकती है' — इसे हमेशा याद रखना चाहिए
- हफ्ते में एक-दो बार सरल demo बनाना लक्ष्य होना चाहिए
- अपूर्ण demo भी खुद देखकर सहज feedback पाया जा सकता है, और यह motivation में बहुत मदद करता है
अपने लिए development
- खासकर personal projects में, पहले वही features implement करना महत्वपूर्ण है जिनकी खुद को ज़रूरत है, और उन्हें स्वयं अपनाकर इस्तेमाल करने की प्रक्रिया अहम होती है
- खुद इस्तेमाल करते हुए कमियों को महसूस करना, वास्तव में ज़रूरी features पर ध्यान देकर सुधार करना, और एक असली user के नज़रिए से प्रोजेक्ट को विकसित करना संभव होता है
- शुरुआती उपयोग में असुविधाएँ या bugs सामने आते हैं, लेकिन वे अगला काम क्या होना चाहिए यह साफ़ कर देते हैं
- अपने लिखे software का उपयोग करने का गर्व प्रोजेक्ट को जारी रखने में मदद करता है
- शुरुआत में अनावश्यक features (scroll, mouse selection, tab आदि) को पूरी तरह छोड़ दिया जाता है
पूरे प्रोजेक्ट को पैकेज करने का तरीका
- पूरी समस्या को नज़र आने वाली छोटी समस्याओं में बाँटें। हर समस्या ऐसी होनी चाहिए जिसमें वास्तविक परिणाम की पुष्टि की जा सके
- हर छोटी समस्या को demo बनाने के लिए पर्याप्त स्तर तक ही हल करें और फिर अगली समस्या पर बढ़ें
- जितनी जल्दी हो सके काम करने वाला demo बनाएँ, और उसके बाद बार-बार features जोड़ें
- प्राथमिकता से ऐसे features implement करें जो खुद के उपयोग के लिए सार्थक हों
- ज़रूरत पड़ने पर हर component को बार-बार बेहतर बनाते हुए इस प्रक्रिया को दोहराएँ
निष्कर्ष
- ऊपर बताए गए तरीके से व्यक्ति, समूह, काम और पढ़ाई जैसे विभिन्न प्रोजेक्ट्स में खुद को प्रेरित रखते हुए उन्हें पूरा किया जा सकता है
- ध्यान deployment या tooling से अधिक इस बात पर है कि कौन-सा तरीका लगातार motivation बनाए रखने में मदद करता है
- यह ज़रूरी नहीं कि एक ही तरीका सब पर लागू हो, लेकिन दिखाई देने वाली प्रगति लंबे प्रोजेक्ट को पूरा करने की सबसे बड़ी ताकत बनती है
- अपनी रुचि और motivation के तरीके को समझकर उसके अनुरूप work process बनाना महत्वपूर्ण है
1 टिप्पणियां
Hacker News टिप्पणियाँ
मैं लेख में दी गई हर बात से सहमत हूँ, और एक बात और जोड़ना चाहता हूँ: तेज़ feedback loop का महत्व
अगर आप बदलाव करें और तुरंत उसका नतीजा देख सकें, तो यह सच में बहुत motivating होता है
कोड के साथ खेलते हुए छोटे बदलाव करना और उनके असर को देखना ऐसा अनुभव है जिसमें बहुत-सी समस्याएँ गायब हो जाती हैं या आसानी से हल होने वाले रूप में बदल जाती हैं
बड़े प्रोजेक्ट्स में setup और run करना जितना आसान था, उसका project problems (bugs, deadlines miss होना आदि) की मात्रा से साफ़ संबंध था
यह टॉक feedback loop के बारे में है
YouTube लिंक
मैं जिन bugs को ढूँढता हूँ, उनके लिए e2e tests लगाने पर विचार कर रहा हूँ ताकि यह पक्का हो सके कि वे सच में ठीक हो गए हैं
जब आप कुछ आज़माना या ठीक करना चाहते हैं, और सिर्फ setup में ही कई घंटे लग जाते हैं, तो सारा मन उतर जाता है और अंत में आप उसे टाल देते हैं
इसीलिए मुझे lisp जैसी REPL वाली languages पसंद हैं
तुरंत result देखने से एक तरह की instant satisfaction मिलती है
जैसे ही motivation खोती है, वह project गायब हो जाता है
इसलिए development को अपने-आप में एक enjoyable experience बनाना लगभग सबसे महत्वपूर्ण बात है
मुझे लगता है कि अनुभव कभी-कभी उल्टा बाधा बन जाता है
मैंने अक्सर senior engineers को perfect चीज़ बनाने के लिए बहुत गहराई में जाते देखा है, लेकिन जब demo दिखाने की बारी आती है तो नतीजा खास नहीं होता
implementation भले अच्छी हो, feature या product खुद ही पूरी तरह फीका होता है
कभी-कभी मन करता है कि दिमाग बंद करके बस थोड़ा घटिया code लिख दूँ
पहले मैं बहुत से toy projects बनाता था, और कभी-कभी पूरा source code एक ही file में ठूँस देता था
modularization जैसी चीज़ों की परवाह नहीं करता था, फिर भी मज़ा आता था और चीज़ें चलती थीं
लेकिन अब एक toy project भी पूरा करना बहुत मुश्किल हो गया है
शायद ऐसा इसलिए होता है क्योंकि एक बार कर लेने के बाद आदमी हर तरह की बेकार extra features भी जोड़ना चाहता है
उदाहरण के लिए, Advent of Code जैसी coding challenges में शुरुआती problems आसान होती हैं, और सिर्फ बाद में optimization या complex algorithms की ज़रूरत पड़ती है
या pico-8 जैसे constrained environment में आप बहुत लंबा coding session कर ही नहीं सकते
या hackathon और game jam जैसे time-limited माहौल में काम करना भी मददगार हो सकता है
कम experience वाले लोग पुरानी languages की उबाऊ 'best practices' भूलकर ज़्यादा आज़ादी से चीज़ें आज़मा सकते हैं
DB tables मैं खुद design करता हूँ, और implementation का हिस्सा LLM को काफ़ी खुलकर दे देता हूँ
यह बात खास लगी कि शुरुआती sub-projects का उद्देश्य 'finished sub-component' बनाना नहीं, बल्कि ऐसा sub-component बनाना है जो अगले चरण में बढ़ने लायक 'काफ़ी अच्छा' हो
इस तरह काम करने के लिए यह समझना पड़ता है कि कुछ न कुछ 'छोड़ना' होगा
दूसरे लोगों ने कहा कि ऐसे mode में वे code modularization को नज़रअंदाज़ कर देते हैं, लेकिन मेरे लिए code को साफ़-सुथरा रखना ही संतोष और motivation देता है
इसलिए मैं algorithms, data structures, performance जैसी चीज़ों को 'छोड़ने' वाला हूँ
आख़िरकार बात यह है कि कुछ न कुछ तो निश्चित ही छोड़ना पड़ेगा, लेकिन अगर वही चीज़ आपको motivation देती है, तो उसे नहीं छोड़ना चाहिए
demo software develop करने (programming) और उसे शब्दों में समझाने (documentation) के बीच का चरण बन जाता है
demo के ज़रिए मैं लगातार अपनी इस परिकल्पना को जाँच सकता हूँ कि मेरा project क्या करना चाहिए, और यह एक तरह का feedback mechanism बन जाता है
demos टिके रहते हैं, इसलिए जब आप किसी feature को तोड़ देते हैं तो उसे तुरंत देख सकते हैं और ठीक करने का loop जारी रख सकते हैं
मैं अपने game engine development में व्यक्तिगत रूप से इसी तरह काम कर रहा हूँ
demo example github लिंक
काश यह तरीका सामान्य समझ का हिस्सा बन जाए
ऐसा लगा कि focus personal projects पर ज़्यादा है
मैं यह जानना चाहता हूँ कि बड़े technical team projects में सबको एक ही लक्ष्य की ओर काम करवाने और कामों को सही तरीके से पूरा करने का अच्छा तरीका क्या है
करीब 15 साल काम करने के बाद भी मैंने ऐसा कोई technical project नहीं देखा जो budget overrun, schedule overrun, features की कमी, या burnout के बिना पूरा हुआ हो
अगर इसके उलट ऐसे बड़े projects के सफल उदाहरण हैं, तो पढ़ने लायक links या recommendations साझा किए जाएँ तो अच्छा होगा
budget overrun तो तब तक आम बात है जब तक सचमुच पैसे पूरी तरह खत्म न हो जाएँ
अधिकतर मामलों में यह बस इतना होता है कि किसी का estimate ग़लत निकला और वह शिकायत कर रहा है
schedule overrun भी ऐसा ही है; जब तक कोई सच में सख़्त deadline न हो, यह बहुत गंभीर बात नहीं है
असल में बड़े marketing campaign जैसी schedule-linked घटनाओं की planning project के लगभग अंत तक नहीं करनी चाहिए
features की कमी भी आखिरकार expectations का मामला है
असली समस्या है 'लोगों का पूरी तरह थक जाना और burnout में चले जाना'
कम-से-कम इस एक चीज़ से तो हर हाल में बचना चाहिए
व्यक्तिगत रूप से, Scaled Agile Framework के प्रति मेरा झुकाव धीरे-धीरे बढ़ा है
मैं इसे एक framework की तरह, यानी हालात के हिसाब से ढालकर इस्तेमाल करने वाले एक तरह के 'strawman' की तरह लेता हूँ
इससे मुझे मूल स्रोतों में और गहराई से जाने और अपने निष्कर्ष खुद निकालने में मदद मिली
मैंने सीखा है कि असली सफलता की शुरुआत 'हम यह बना क्यों रहे हैं, इसे स्पष्ट रूप से समझने' से होती है
अगर लक्ष्य स्पष्ट न हो, तो आप priorities तय नहीं कर सकते और न ही यह समझ सकते हैं कि शुरुआत कहाँ से करनी है
यह स्पष्टता 'क्या और कब बनाना है' तय करने में बहुत मदद करती है, और कभी-कभी 'बिलकुल न बनाने' का फैसला लेने में भी
इसके बाद अगली महत्वपूर्ण चीज़ है 'empathy'
आपको ग्राहक के नज़रिए से जाकर उनकी समस्या को पूरी तरह समझना और उसका समाधान देना होता है
इसका मतलब सिर्फ ग्राहक की हर माँग मान लेना नहीं है, बल्कि उनके मूल pain points को सही तरह समझकर सचमुच मूल्यवान चीज़ पहुँचाना है
ज़्यादातर projects के fail होने की असली वजह यह है कि teams 'गलत चीज़' बनाने में बहुत समय लगा देती हैं
अगर लगातार उन चीज़ों पर ध्यान रहे जो सच में ज़रूरी हैं, जिन्हें लोग वास्तव में चाहते हैं या जिनके लिए भुगतान करने को तैयार हैं, तो कहीं ज़्यादा projects सफलतापूर्वक पूरे हो सकते हैं
बड़े project को देखकर analysis paralysis में फँस जाने वाले लोग सच में बहुत होते हैं
वास्तव में मुश्किल काम है उसे खत्म करना
अगर आप ऐसा software बनाते हैं जिसे आप खुद इस्तेमाल करेंगे, तो आप अपनी समस्या खुद हल कर सकते हैं
खुद इस्तेमाल करते हुए आप software के bugs भी ढूँढ सकते हैं
मैंने खुद web server बनाकर इस्तेमाल करते समय सच में कई bugs पाए थे
एक focused, iterative, और हमेशा काम करने वाले परिणामों की ओर उन्मुख development culture