तेज़ी से आगे बढ़ना, और छोड़ देना

 (engineersneedart.com)
2 पॉइंट द्वारा GN⁺ 2024-09-25 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 1991 के आसपास के एक अधूरे Mac गेम को रिकवर करने की प्रक्रिया में, आइडिया को जल्दी लागू करके देखना और मज़ा या पूरा हो पाने की संभावना कम लगे तो उसे बेबाकी से छोड़ देने का development तरीका बार-बार दिखा
  • उस समय की सूची में 27 titles थे, लेकिन असल में सार्वजनिक हुए काम 5 ही थे; बाकी लगभग 18 महीनों में बनाए गए तेज़ prototypes जैसे थे
  • sprite-based games के लिए common shell की वजह से नए experiments की लागत कम हो गई थी, और sound, high score, save functions जैसी चीज़ें संभावना साबित होने के बाद तक टाल दी जाती थीं
  • kite-fighting, K-10, Thief of Baghdad जैसे experiments में आगे बढ़ना है या नहीं, यह controls के मज़े, game के purpose, और एक solo developer कितना art और implementation workload संभाल सकता है, इसके आधार पर तय होता था
  • छोड़े गए projects भी बेकार नहीं गए; Fisher–Yates shuffle, screen color depth switching, collision detection, trigonometric lookup tables जैसा code बाद के projects में फिर इस्तेमाल हुआ

पुराने Mac game project की recovery

  • लगभग 35 साल पहले लिखी गई game files को पुराने hard drive से recover करते समय, released titles की तुलना में लगभग कभी पूरे न हो पाए experimental works ज़्यादा दिलचस्प विषय बनकर रह गए
  • पहले public किए गए shareware games को disk images में बाँधकर Soft Dorothy Software — Early Shareware Projects पर अपलोड किया गया
    • ये disk images Basilisk II, Sheepshaver, MiniVMac जैसे 68K या PPC Mac emulators में drag-and-drop करके इस्तेमाल किए जा सकने वाले रूप में हैं
  • Casady & Greene ने 1991 में publish किए Glider 4.0 से जुड़े source और build tools Casady & Greene Projects disk image में शामिल हैं
  • AirBikes अगर पूरा हो जाता तो एक futuristic racing game बनता, लेकिन असल में वह अधूरा ही रह गया

27 titles में से सिर्फ 5 released

  • 1991 के आसपास बनाए गए document में हर game का creator code, नाम और status व्यवस्थित था
    • creator code, OS X से पहले के Macintosh दौर के बहुत rough bundle identifier जैसा था, और हर application के लिए unique होना ज़रूरी था
  • सूची में 27 titles थे, जिनमें से released सिर्फ 5 हुए
    • बाकी ज़्यादातर fast prototypes थे
    • ये projects लगभग 18 महीनों में बनाए गए थे
    • सूची बनते समय एक साथ 3 titles पर काम चल रहा था, ऐसा दर्ज है
  • UnMask नाम की utility भी public की गई थी, लेकिन इसे बनाने में करीब 10 मिनट लगे थे, इसलिए analysis के subject से बाहर रखने लायक माना गया

fast prototyping का तरीका

  • देर रात तक रोज़ coding करते हुए कई experiments बनाए गए, और sprite-based games के लिए common shell से नए prototypes बनाने की लागत घटाई गई
  • नए game sketches में मुख्य समय MacPaint से sprites और art बनाने में लगता था, जबकि unique input method, game mechanics और physics implementation के लिए कुछ code चाहिए होता था
  • sound, high score, saved games जैसी features शुरुआत से नहीं बनाए जाते थे; उन्हें सिर्फ उन games जिनमें बचाने लायक value हो के लिए बाद में implement करने को टाल दिया जाता था
  • core बात यह थी कि idea असल में मज़ेदार है या नहीं, इसे जल्दी validate किया जाए
    • कागज़ पर लिखा idea मज़ेदार दिखना और actual play का मज़ेदार होना अलग हो सकता है
    • controls और physics को कुछ ही दिनों में implement करके यह देखा जा सकता था कि आगे बढ़ना worth it है या नहीं

मज़ा जल्दी validate करने के criteria

  • kite-fighting game में उड़ाने वाले controls और physics कुछ ही दिनों में implement करके test किए जा सकते थे
    • अगर पतंग को control करना ही बहुत मुश्किल हो, तो game enjoy करने वाले लोग कम होने की संभावना बड़ी है
    • अगर combat elements के बिना सिर्फ पतंग उड़ाना भी मज़ेदार हो, तो संभावना है
  • arcade game Joust में enemies आने से पहले भी flap button से उड़ने वाला control अपने आप में मज़ेदार था
    • कब धीरे-धीरे पंख फड़फड़ाने हैं और कब तेज़ी से ऊपर उठने के लिए बेतहाशा button दबाना है—दोनों ने play feel बनाया
  • बिखरे हुए घर के अंदर paper airplane को floor vents से lift दिलाने वाला game भी, कमरों में आगे बढ़ना और toast आदि से बचना है—यह goal समझने से पहले ही कुछ हद तक मज़ेदार था
  • K-10, Kansas highway 10 से नाम लिया गया एक और racing game था, लेकिन prototype stage से आगे नहीं बढ़ पाया

छोड़ना है या जारी रखना है, इसका फैसला

  • कुछ games का शुरुआती implementation तो हो गया था, लेकिन आगे क्या करना है यह साफ़ नहीं था
    • सूची में कुछ games के लिए ठंडे ढंग से <no point> लिखा था
  • platform game Thief of Baghdad में magic carpet पर कूदते-भागते घूमना मज़ेदार था, लेकिन उसके बाद game का उद्देश्य अस्पष्ट था
  • अकेले develop करने की स्थिति में, potential दिखने के बावजूद ऐसे project को जारी रखना मुश्किल था जिसे पूरा होने में एक साल से ज़्यादा लगे
    • Dungeons and Dragons style का sprite-based adventure game आकर्षक था, लेकिन player weapons के हिसाब से actions, monsters, spell effects और combat system तक—काम की मात्रा बड़ी थी
    • तलवार से वार और block करने की actions बनाने के बाद, mace, bow, cloak जैसे variations भी जोड़ने पड़ते—इस तरह art burden बढ़ता जाता

फिर से निकालना, और code reuse करना

  • टाले गए games पूरी तरह dead projects नहीं होते; अगर source, resources और project files मिल जाएँ तो उन्हें फिर निकाला जा सकता है
  • Thief of Baghdad लगभग 18 महीने बाद color version के रूप में फिर शुरू हुआ और उसे Scheherazade नाम मिला; उसमें कुछ हद तक purpose भी बनने लगा
    • दूसरे attempt में भी आखिरकार वह समझाना मुश्किल charm पर्याप्त नहीं बन पाया, इसलिए उसे फिर रोक दिया गया
  • hold पर रखे projects का code बाद के काम में reuse हो सकता था
    • Fisher–Yates shuffle algorithm
    • शुरुआती Mac में monitor color depth बदलने वाला code
    • polygon-point collision code
    • fast trigonometry के लिए sine lookup table
    • dot-product और cross-product routines
  • ऐसे prototyping work को waste नहीं माना गया

Apple में भी जारी रहा iterative तरीका

  • 1990s आगे बढ़ते हुए indie Mac game developer का दौर खत्म होता सा लगा, और California जाकर Apple में काम करने का offer मिला तो उसे स्वीकार किया गया
  • Apple join करने के बाद यह समझा गया कि खाली समय में non-Apple projects नहीं किए जा सकते
    • strictly देखें तो office work के बाहर coding करने के लिए manager की written permission चाहिए थी
    • चूँकि Apple game business में नहीं था, permission मिल भी सकती थी, लेकिन request करके reject होने की possibility बोझ बनी रही
  • game से अलग work projects में भी fast prototyping method जारी रहा
    • दूसरे colleagues whiteboard पर design iterate करते और code लिखने से पहले careful planning करते थे
    • खुद पहले कूदकर compile करते हुए iterate करना पसंद करते थे
  • जल्दी code इकट्ठा करके bottleneck जल्दी ढूँढना, और ज़रूरत पड़े तो project को लगभग शुरू से फिर शुरू करना—यह तरीका दोहराया गया
    • project को करीब तीन बार शुरू करके फिर से शुरू करने के बाद भी, अक्सर उस समय तक पर्याप्त अच्छी हालत में पहुँच जाते थे जब careful design करने वाले colleagues अपना code चलाने लगते थे
  • आख़िरी code revision आम तौर पर simplification होता था, और शुरुआत से ही code को बड़े बदलावों के लिए तैयार state में treat करते हुए यह sense मिलता था कि उसे organize कैसे करना चाहिए
  • Bloom Filter recommend करने वाले colleague को यह जवाब दे पाने का अनुभव भी था कि actual data बहुत छोटा है, performance gain नगण्य है और codebase complexity ही बढ़ रही थी, इसलिए उसे पहले ही छोड़ दिया गया था

Always Be Iterating

  • retirement के समय तक ऐसा महसूस हुआ कि Apple में contributing employee और colleague रहे
  • अकेले रात भर coding करने वाले दिनों के उलट, साथ काम करने वाले engineers Apple में काम करने का सबसे अच्छा हिस्सा थे
    • साथ काम करने वालों में कुछ programmers ऐसे भी थे जो उनसे एक order of magnitude से ज़्यादा बेहतर थे
  • उन्हें लगा कि वे सबसे तेज़ programmers में से एक थे, और अगर उस हफ्ते की meeting demo के लिए prototype चाहिए हो तो दो versions बना सकने वाले व्यक्ति के करीब थे
  • बेटियों से बार-बार कही गई line A.B.I. थी
    • “Always”
    • “Be”
    • “Iterating”
    • यानी “Always Be Iterating”
  • release न हो पाए games के projects, source और tools को disk images में व्यवस्थित करके GitHub पर public किया गया
  • Volume 3 भी planned है, लेकिन हर project को “release” करने लायक state में organize करने का काम बाकी है, इसलिए public होने का समय वादा नहीं किया गया

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-09-25
Hacker News की रायें

  • 1989 के आसपास programming शुरू करने के बाद से मेरे पास छोड़े हुए projects कम से कम दर्जन भर, और ज़्यादा से ज़्यादा करीब सौ होंगे; ज़्यादातर games हैं। उनमें से अधिकतर Mac Plus या Mac LC के लिए बनाए थे, और लेख में बताए गए जैसी mechanics या art styles भी बहुत थीं
    जो गिने-चुने projects मैंने release किए या जिनमें हिस्सा लिया, वे मुझे अपने ही एक साये जैसे लगते हैं। resume और career भी वैसे ही हैं। वे ऐसे पूर्ण अस्तित्व की उंगलियों के निशान जैसे लगते हैं जो उन सपनों की ज़िंदगी जी रहा था जो शुरुआती सफलता जमा करने का मौका न मिलने से वास्तविक नहीं हो सकी। इसलिए मुझे लगता है कि basic income मानव क्षमता को 10 गुना या 100 गुना बढ़ा सकती है, service economy से agency और self-realization की ओर ले जा सकती है, और हर किसी को residual income बनाने में मदद कर सकती है। और मैंने Pararena सचमुच बहुत खेला था

    • मेरा विचार अलग है, और pandemic के दौरान मेरे और मेरे दोस्तों के आसपास basic income जैसी स्थिति बनने से मैं ऐसा सोचने लगा। जिन लोगों को अब काम करने की ज़रूरत नहीं रही, वे काम जारी रखने वालों की तुलना में काफी जल्दी उदास हो गए, और इससे basic income पर मेरा नजरिया बदल गया
      हो सकता है आपके आसपास ऐसा न हुआ हो, या आपके देश ने ऐसा approach न अपनाया हो। मुझे जिज्ञासा है कि कई games पर काम करने और एक पर focus करके उसे खत्म करने में क्या फर्क है। अगर basic income हो, तो क्या इतने पूरे projects निकल पाएंगे—वह भी थोड़े समय के लिए नहीं, बल्कि लगातार ऐसी चीज़ें करने लायक? parent बनने का समय या बचपन जैसे जीवन के कुछ चरणों में basic income समझ में आती है, लेकिन खुद को खोजने वाले दौर में मुझे लगता है जिम्मेदारी मदद करती है
    • basic income काम नहीं करेगी। हमारे देश में यह लगभग लागू है। काम न करने पर भी महीने के 600 euro और कई welfare benefits मिल सकते हैं, लेकिन नतीजा है EU में सबसे बड़ा public deficit, दुनिया में सबसे ऊंचे tax rates में से एक, फैला हुआ crime, उन taxes की वजह से काम करके पैसा कमाना मुश्किल, और पढ़े-लिखे लोगों का बड़ी संख्या में विदेश जाना वगैरह
    • अगर minimum wage भी ठीक से काम नहीं कर पाया, तो मुझे नहीं पता कौन-से metrics लोगों को यह भरोसा दिलाते हैं कि काम न करने वालों को पैसे देने वाली मिलती-जुलती system काम करेगी
      इस तरह की सोच समझना सचमुच मुश्किल है। जादुई basic income काम न करने वाली जनता के लिए minimum wage बन जाएगी; वह कैसे sustainable या अच्छी हो सकती है?
    • हम अलग-अलग तरह की ज़िंदगियां जी रहे हैं। मैं तो केवल उन projects में शामिल रहा हूं जिनमें product को बेहतर होता कि छोड़ ही दिया जाता। वे games नहीं थे, लेकिन release होने पर उनकी हालत ऐसी ही थी
      theoretically उन्हें ठीक से पूरा करने का विकल्प था, लेकिन अगर ऐसा करने की कोशिश की जाती तो organization दिवालिया हो जाती, इसलिए वह सिर्फ theoretically ही विकल्प था। काम में इस्तेमाल होने वाले और निजी तौर पर भी मजबूरी में इस्तेमाल करने पड़ने वाले software की हालत देखकर लगता है कि मेरे आसपास हर कोई ऐसी ही जिंदगी जी रहा है। सौभाग्य से users के पास choice नहीं है, इसलिए उन्हें खराब चीज़ खरीदनी पड़ती है या फिर कुछ भी नहीं खरीदना पड़ता। हम खराब चीज़ बेचकर भी सुरक्षित हैं
    • जो चीज़ें पूरी नहीं होतीं, उन्हें बस research कह देते हैं। मेरे पास Unreal Engine 4/5 के कई projects हैं और उन्हें कभी पूरा नहीं कर पाऊंगा, लेकिन game mechanics testing, rigging और animation, shader development, 3D assets बनाना जैसे पहलुओं से वे मज़ेदार थे

  • जिन कई कंपनियों में मैंने काम किया, वे इसी तरह चलती हैं। engineers चमकदार नया feature बनाते हैं, वह release होता है, और सब खुश होते हैं। कुछ महीनों बाद bugs का ढेर लग जाता है
    मूल creators तब तक किसी और team में जा चुके होते हैं। बहाना होता है “silos तोड़ना”, लेकिन असल में यह “सबको replaceable बनाना” जैसा होता है। project विरासत में पाने वाले engineers को तब तक maintenance और bug fixing करनी पड़ती है जब तक कोई और team उसे संभाल न ले। भयानक है

    • minimum viable product को सही product development तरीका मानकर व्यापक रूप से अपनाने से यह हमारे ही बनाए नरक जैसा हो गया है। हम किसी मूर्खतापूर्ण चीज़ की मजबूती या maintainability से नहीं, बल्कि feature list से उसकी viability आंकते हैं
      ऊपर से “minimally viable” बस “not viable” से एक कदम दूर है। हर project Icarus जैसा बन जाता है, जहां यह परखा जाता है कि पंख पिघलने से पहले सूरज के कितने करीब उड़ सकते हैं
    • मैं अक्सर मज़ाक करता हूं कि Series A के बाद की हर startup job posting product-market fit से पहले वाले “heroes” के बाद की सफाई के लिए Viscera Cleanup Detail[1] करने को कहती लगती है
      [1]: https://store.steampowered.com/app/246900/Viscera_Cleanup_De...
    • मैं company को define करने वाले feature का original author था, और जब “silos तोड़ने होंगे” सुनकर मुझे हटना पड़ा, तो कई सालों तक अपने काम को बिगड़ते देखा; इसलिए पूरी तरह सहमत हूं
      जिन लोगों ने उसे संभाला, वे decisions लेने के योग्य नहीं थे, मेरी बड़ी vision किनारे कर दी गई, उस feature को manage करने की अक्षमता देखना असहनीय था, और आज भी जब बेवकूफाना bugs आते हैं तो चिढ़ होती है। खासकर तब, जब पर्याप्त coordination time होने पर भी मैंने चेतावनी दी थी। फिर भी मैंने एक जरूरी सबक सीखा, और अगली बार मैं निश्चित रूप से कह सकता हूं कि stubborn person जैसा दिखने पर भी पीछे नहीं हटूंगा और लड़ूंगा
    • बात पूरी तरह सही है, लेकिन मुझे नहीं लगता कि original post का point या लेख का इरादा यही है। लेख असल में कई चीज़ें आज़माने, यह समझने कि वे technically possible हैं या नहीं और customers को interesting लगती हैं या नहीं, फिर उन्हें आगे बढ़ाने की सलाह जैसा है
      यह indie developers के लिए भी अच्छी तरह fit बैठता है, और कुछ हद तक बड़ी companies पर भी लागू हो सकता है। यह philosophy उन features या products की पहचान करने में अच्छी है जिन पर meaningful समय लगाया जाए। बल्कि आपने जो स्थिति बताई है, उसे original post द्वारा सुझाए गए तरीके का पालन न करने का सीधा नतीजा भी माना जा सकता है
    • आपने जो बताया है, वह इस लेख से बहुत संबंधित नहीं लगता

  • इन दिनों मैं रेट्रो डेवलपमेंट की ओर लौटकर काम कर रहा हूँ। मैं 68K Macintosh के लिए सॉफ्टवेयर बना रहा हूँ, जिस पर मैंने पहली बार programming सीखी थी
    मैंने पुरानी किताबें, comp.sys.mac.programmer की पोस्टें, और Soft Dorothy व GliderPro जैसे source code काफी खंगाले हैं। पुराने code को नई नजर से देखना अजीब-सा अनुभव है। पुराने Macs इतनी बार क्यों क्रैश होते थे, इसका कारण सिर्फ “memory protection नहीं था” वाली व्याख्या से आगे भी दिखता है। लेखक ने जैसा कहा, मुझे भी 1-bit art पसंद है, इसलिए मैं 1-bit art पोस्ट करने वाले Twitter accounts की एक सूची maintain करता हूँ। अगर कोई छूट गया हो तो बताइए: https://twitter.com/i/lists/1578111923324944397
    सीमित systems के लिए programming करने की अच्छी बात यह है कि वे आपकी choices सीमित कर देते हैं। आधुनिक अनुभव—जहाँ सही libraries जोड़ लें तो लगभग कुछ भी किया जा सकता है—से यह अच्छा break देता है। कभी-कभी मैं ऐसी दुनिया की कल्पना करता हूँ जहाँ computing power जम-सी गई हो, और अच्छी तरह समझे जा चुके systems के लिए software बस लगातार बेहतर होता जाए। Mac 68K जैसे पुराने systems में hardware की प्रगति इतनी तेज थी कि चक्कर आ जाए। 68020 या 80386 जैसे नए processor आते ही, उनकी क्षमता का सही इस्तेमाल करने वाली कोई चीज बनाने के लिए आपके पास ज्यादा से ज्यादा कुछ साल ही होते थे। बहुत देर हो जाए तो नई hardware generation के लिए बने नए software से मुकाबला करना पड़ता था

    • 30 साल से ज्यादा की hindsight के साथ अपने code को फिर से देखता हूँ तो refactor करने का मन करता है, और window event responses जैसे आम झंझटों को सरल बनाना चाहता हूँ
      Handle वगैरह संभालने के लिए wrapper functions भी बनाना चाहता हूँ। फिर भी, जैसा कहा गया, modern operating systems की तुलना में Toolbox कितना simple था, यह हैरान करता है। फिर से retro development करना सचमुच मजेदार लग रहा है
    • मैं सीमित platform Playdate के लिए 1-bit art करता हूँ। यह Macintosh Plus जितना सीमित नहीं है। Twitter पर मैं @gingerbeardman हूँ और examples यहाँ हैं: https://blog.gingerbeardman.com/2024/07/14/shibuya-pixel-art...
    • 68k Mac की dithered images की वजह से मुझे 1-bit art पसंद है। computer wallpaper के लिए मेरे पास जो कुछ photos हैं, उनमें से कुछ को भी मैंने dither कर रखा है

  • पूरा blog शानदार है। देखने लायक बहुत-सी दिलचस्प चीजें हैं
    किसी चीज को छोड़ देना भी ठीक है, छोड़े गए project से भी सीखा जा सकता है और उसके कुछ हिस्से reuse भी किए जा सकते हैं। मेरे लिए breakthrough तब आया जब मैंने तय किया कि चीज को इतना छोटा बनाऊँ कि उसे पूरा कर सकूँ। इससे खत्म करने की skill विकसित करने में मदद मिली, और यह अलग skill है जिसे सीखना मुश्किल है। क्योंकि यह बहुत लंबी और कठिन प्रक्रिया के अंत में ही घटित होती है, इसलिए हम शायद ही कभी वहाँ तक पहुँचते हैं। videogames बनाने वाले मेरे सभी दोस्त पहले अपना engine लिखना शुरू करते हैं, और level editor बनाने तक burnout हो जाते हैं। tools बनाने जैसी चीजों से वे बहुत सीखते हैं, लेकिन संयोग से वह काफी कुछ वैसा ही होता है जो उन्हें पहले से आता था, और असल game बन ही नहीं पाता। यह cathedral बनाते हुए masonry सीखने जैसा है—अंत तक पहुँचना संभव नहीं होगा। इतनी छोटी चीज से शुरू करना चाहिए कि fail होना संभव ही न हो, फिर धीरे-धीरे बड़े projects की ओर बढ़ना चाहिए

    • “videogames बनाने वाले मेरे सभी दोस्त पहले अपना engine लिखना शुरू करते हैं” — यह मैंने भी कुछ बार देखा है। मौजूदा tools इस्तेमाल करने का फैसला करने पर भी, आप आसानी से complexity की अंतहीन गहरी दलदल में फँस सकते हैं
      मैं अभी एक Unity project पर काम कर रहा हूँ, और RTS-style building placement system को सबसे अच्छे तरीके से कैसे बनाया जाए, यह सोचते-सोचते जूझ रहा था। हमेशा की तरह सीधे कूद पड़ने के बजाय, मैंने game concept को बदलने का फैसला किया ताकि player को buildings place करने की जरूरत ही न पड़े। प्रयोग करके देखा तो जो मैं बनाना चाहता था उसके लिए यह user experience उल्टा बेहतर निकला। शुरुआत में मैंने यह कहकर rationalize किया कि “अगले iteration में building system जोड़ देंगे,” लेकिन अब शायद मैं ऐसा नहीं करूँगा
      घटाना लगभग हमेशा बेहतर होता है। किसी छोटे starting point को सचमुच पूरा कर लेना अगले iteration के लिए nitromethane जैसा है। 100% तक पहुँचना जरूरी है, तभी अगली बारी बहुत बेहतर होती है। 80% पर रुकने से बस यही एहसास बचता है कि चट्टान को फिर से पहाड़ पर ऊपर धकेलना पड़ेगा
    • लगता है मैंने एक भी personal project कभी पूरा नहीं किया। कम-से-कम मेरे लिए तो यही सबसे मुश्किल skill है जिसे विकसित करना है
    • personal project को इतना छोटा करने पर ध्यान देना कि उसे सच में पूरा किया जा सके, शायद अभी मेरे लिए बिल्कुल वही चीज है जिसकी जरूरत है
    • हाल ही में मैं frontend development से accessibility की ओर आया हूँ। कुछ साल पहले मैंने कई static sites, templates और design projects बनाए थे, लेकिन अंततः वे अलग-अलग कारणों से छोड़े रह गए
      accessibility का काम शुरू करने के बाद मैंने उनमें से कई को फिर निकाला और accessible बनाकर दोबारा बनाया। कुछ बहुत पुराने Bootstrap versions इस्तेमाल कर रहे थे, इसलिए साथ में उन्हें latest Bootstrap पर upgrade भी किया। पुराने designs को accessible बनाते हुए ही मैंने सचमुच बहुत कुछ सीखा। sites और applications को evaluate करते समय क्या देखना चाहिए, इस पर मुझे काफी बेहतर perspective मिला। यह भी समझ आया कि जो चीजें मैंने बनाई थीं वे accessibility के लिहाज से कितनी कमजोर थीं
    • शुरू की गई चीजों को पूरा करने की skill productivity की चर्चाओं में गायब-सी लगती है। सोच रहा हूँ कि क्या इस पर अधिक विस्तार से समझाने वाली कोई blog post या article है

  • John के games, बचपन में Mac पर programming पहली बार सीखते समय, मेरे लिए inspiration थे। मैंने Glider बहुत खेला और Pararena उससे भी ज्यादा। उसकी गूँजती हुई startup sample अभी भी दिमाग में अटकी है
    शायद मैंने उन games के resource forks को ResEdit में खंगालने में उससे भी ज्यादा समय बिताया होगा। बहुत कुछ पूरा नहीं कर पाया, लेकिन कुछ छोटे shareware games पूरे किए और AOL पर upload किए। कुछ महीनों बाद दूर California से mailbox में cheque आया तो मैं सचमुच हैरान रह गया
    शुरुआती Mac का दौर सच में खास था, और ऐसा लगता था कि कोई solo developer, बस creativity और समय के दम पर, कुछ बनाकर दुनिया के सामने रख सकता है। ऐसी post लिखकर यादों में ले जाने के लिए धन्यवाद, और उम्मीद है कि आप retirement का आनंद ले रहे होंगे

    • शायद आपने मेरी दूसरी posts या disk image repository का README पढ़ा होगा। वह दौर खास था
      क्या वह इसलिए खास था कि शुरुआती computer users और शुरुआती developers के रूप में हमारे लिए सब कुछ नया था? या उस समय हवा में सचमुच कुछ अलग था? खुशी है कि आपको मेरे छोटे games पसंद आए। यह भी सोचता हूँ कि California से आया वह cheque, आपकी आज की career जो भी हो, क्या उसी रास्ते पर धकेलने वाला क्षण था

  • अगर इस लेख का उद्देश्य प्रोजेक्ट्स को छोड़ देने को सामान्य बनाना है, तो मुझे पक्का नहीं कि यह अच्छा विचार है। बाकी सब छोड़ भी दें, तो यह जबरदस्त समय की बर्बादी हो सकती है, और “फिर भी कुछ सीखा” कह देने भर से इसे जायज़ नहीं ठहराया जा सकता। खत्म करते हुए भी तो सीखना चाहिए, है ना

    • Smarter Every Day के एक शानदार एपिसोड में Destin एक ग्लासवर्क स्टूडियो के साथ मिलकर टूटे हुए Prince Rupert's drops को resin block के अंदर डालने का काम करता है
      यह ऐसा काम था जो किसी ने पहले नहीं किया था, इसलिए वे आगे बढ़ते हुए तरीका खोजते हैं, और बीच में काफ़ी गलतियां करते हैं। वीडियो में जिन बातों पर ज़ोर दिया गया है, उनमें से एक यह है कि जब ऐसा होता है तो टीम बस रुककर वही चीज़ फिर से करने की कोशिश नहीं करती। वे आगे बढ़ते रहते हैं, उसे पूरी तरह खराब कर देते हैं, और सामग्री के साथ खुलकर प्रयोग करने का मौका बना लेते हैं
      वह इस बात पर लंबी चर्चा करता है कि यह कितना बेहतरीन है। अगर वे एक तैयार और polished product बनाने के रास्ते पर होते, तो जो प्रयोग वे नहीं कर पाते, उन्हें आज़ादी से करके वे इस्तेमाल की जा रही सामग्री के व्यवहार के बारे में और सीखने का बेजोड़ मौका इस्तेमाल कर रहे होते हैं। जो चीज़ पहले ही कचरा बन चुकी हो, उसे और बिगाड़ना मुश्किल है, इसलिए इसे अब और जोखिम लेने जैसा मानना भी थोड़ा अजीब है
      मुझे लगता है कि यह बात सही है कि सिर्फ सफलता को अहमियत देने के बजाय सीखने और प्रयोग को अहमियत देने वाली सोच, अपने काम में वाकई बेहतरीन बनने के सबसे अच्छे तरीकों में से एक है
    • उसने असल में कुछ चीज़ें पूरी भी की हैं। मुख्य बात analysis paralysis से बचना और लगातार सोचते रहने के बजाय “पहले करके देखना” है। यह action bias है और sunk cost को ठुकराने वाला रवैया है
    • यह लेख को गलत पढ़ना है। लेख तेज iterative prototyping के ज़रिए discovery के ज्यादा करीब है, जिसमें fatal flaws को शुरुआती दौर में जल्दी पकड़ना भी शामिल है
    • मुझे लगता है शीर्षक अच्छा नहीं है। सीख इससे ज्यादा “जो भी आइडिया आए, उस पर काम करो, लेकिन तैयार होने से पहले कुछ भी release मत करो। कुछ project शायद कभी तैयार न हों, और यह ठीक है। 30 साल बाद याद के तौर पर GitHub पर डाल सकते हो” जैसी है
      ChatGPT ने इसे “तेजी से बनाओ, और कभी release मत करो। जब तक release करने का समय न आ जाए” के रूप में summarize किया
    • मुझे लगता है project का मर जाना healthy है। यह किसी एक ढांचे में फंसे रहने के बजाय दूसरा project शुरू करने का समय खाली कर देता है
      कभी-कभी हम ऐसे project को पकड़े रहते हैं जो कहीं नहीं जा रहा होता, और सोचते हैं कि अगर काफी मेहनत करें तो वह कहीं न कहीं पहुंचेगा, लेकिन उसमें न मज़ा होता है और न कुछ नया सीखने को मिलता है। “इसे खत्म करना है, खत्म करना है” सोचकर खुद को धकेलते रहते हैं, और जब “क्यों?” पूछते हैं तो अक्सर वजह पूरा न कर पाने का डर होती है, या शायद यह डर कि कहीं मुश्किल phase और failed project वाले phase में फर्क न कर पाएं। किसी भी स्थिति में, fail होने पर मैंने बहुत बार आज़ादी महसूस की है। यह फिर से शुरू करने का मौका बन जाता है

  • स्क्रीनशॉट में कुछ pixel art वाकई शानदार हैं

  • व्यक्तिगत रूप से, मैंने छोटी चीज़ें release करके और फिर iterate या discard करते हुए कहीं ज्यादा सीखा और कमाया है

  • मुझे यह तरीका पसंद है और दिलचस्प लगता है, लेकिन organization level पर यह ज्यादा मुश्किल दिखता है। projects और technologies के बारे में हम जो बहुत-सी बातें खोजते हैं, वे उस scale पर feasibility से जुड़ी होती हैं जहां असली project काम करता है, और छोटे experiments में वे जरूरी नहीं कि सामने आएं
    कभी-कभी समस्या technology की नहीं होती, बल्कि “क्या हम यहां के ज्यादातर developers को यह समझा सकते हैं कि इस तरीके से कैसे काम करना है” जैसी होती है। इसका मतलब यह नहीं कि हमें ऐसे प्रयास और नहीं करने चाहिए। छोटे projects आज़माते हुए कुछ चीज़ें सीखी जा सकती हैं। बस यह guarantee नहीं कि वे बड़े scale पर भी काम करेंगी

  • मेरी समस्या बस समय है। ऑफिस से घर आने के बाद computer के सामने बैठना ही वह चीज़ है जो मैं सबसे कम करना चाहता हूं
    हफ्ते में दो दिन की छुट्टी भी घर के कामों से भरनी पड़ती है, इसलिए तब भी computer screen के सामने बैठने का मन नहीं करता

    • मैं junior हूं और अभी internship और उसके बाद की job खोजने की कोशिश कर रहा हूं
      जो लोग आपकी तरह कर सकते हैं, उनसे मुझे जलन होती है। अभी यह industry ऐसी cult जैसी लगती है जो सिर्फ उन लोगों को ढूंढती है जिनकी पूरी जिंदगी technology और programming ही है। ऐसा नहीं कि मुझे requirements खुद नापसंद हैं; मेरी work ethic भी है और मैं अच्छा करना चाहता हूं, लेकिन expectations पहले से कहीं ज्यादा ऊंची लगती हैं
      उम्मीद है कि इतनी job stability मिल जाएगी कि ऐसे hobbies रख सकूं जिनमें screen को घूरना न पड़े। जल्द ही metalworking आज़माना चाहता हूं