इस हफ्ते कुछ छोटा शिप करें

अधिकतर लोग जो ट्यूटोरियल लूप में फंसे हैं, उनके पास कोई स्किल प्रॉब्लम नहीं है। उनके पास शिपिंग की समस्या है। आप Python के चालीस घंटे कंटेंट देख सकते हैं और फिर भी उस पल जम जाते हैं जब आप अपने लिए कुछ बनाने बैठते हैं, क्योंकि ट्यूटोरियल आपके लिए हर फैसला हटा देते हैं। यह गाइड एक जबरदस्ती वाली चीज है: कुछ छोटा चुनें, उसे खत्म करें, किसी के सामने रखें, इसी हफ्ते।

एक प्रोजेक्ट चुनें जिसे आप सप्ताहांत में खत्म कर सकें

यहाँ की विफलता का तरीका स्कोप है। लोग तय करते हैं कि उनका पहला प्रोजेक्ट auth, billing और एक डैशबोर्ड के साथ एक SaaS ऐप होना चाहिए। यह एक छः महीने का प्रोजेक्ट है जो सप्ताहांत जैसा दिखता है।

इसके बजाय एक ऐसी चीज चुनें जिसका एक स्पष्ट कार्य हो:

• एक CLI tool जो EXIF date के आधार पर फोल्डर में फाइलों का नाम बदले
• एक script जो एक public API को scrape करे और आपको एक दैनिक सारांश ईमेल करे
• एक Flask ऐप जिसमें एक फॉर्म और एक आउटपुट पेज हो
• एक browser extension जो किसी भी पेज पर एक कीवर्ड को highlight करे जो आप विजिट करते हैं

कोई भी कोड लिखने से पहले स्कोप को एक वाक्य में लिखें। अगर वाक्य में एक बार से अधिक "and" की जरूरत है, तो उसे काटें। "एक tool जो मेरे खर्चों को ट्रैक करता है और उन्हें categorize भी करता है और उन्हें chart भी करता है" तीन प्रोजेक्ट हैं। पहले tracker को शिप करें।

एक असली deadline और असली audience सेट करें

एक deadline जिसका कोई परिणाम नहीं है, deadline नहीं है। एक दोस्त को बताएँ, Discord सर्वर में पोस्ट करें, या शुक्रवार को किसी सहकर्मी को इसका demo देने के लिए प्रतिबद्ध हों। Audience deadline से अधिक महत्वपूर्ण है — यह जानना कि कोई व्यक्ति वास्तव में इस चीज को देखेगा, इस बात को बदल देता है कि आप इसे कैसे बनाते हैं। आप आर्किटेक्चर को gold-plate करना बंद करते हैं और happy path को सही तरीके से काम करना सुनिश्चित करने पर ध्यान देते हैं।

अपने आप को एक संख्या दें, एक feel नहीं। "मैं इस पर तब काम करूँगा जब मेरे पास समय हो" कुछ नहीं देता। "दो घंटे आज रात, दो घंटे कल, शनिवार सुबह को शिप करो" एक प्रोजेक्ट देता है।

पहले ugly version बनाएँ

फोल्डर स्ट्रक्चर की बहस को छोड़ दें, CSS framework चुनने को छोड़ दें, Postgres और SQLite के बीच तय करने को छोड़ दें एक tool के लिए जो चालीस rows स्टोर करेगा। एक file लिखें। print() statements का उपयोग करें logger की जगह। अगर आपको बस इतना ही चाहिए तो Python list का उपयोग करें database की जगह।

# expenses.py - ugly version, और वह ठीक है
import csv
from datetime import date

def add_expense(amount, category):
    with open('expenses.csv', 'a', newline='') as f:
        writer = csv.writer(f)
        writer.writerow([date.today().isoformat(), amount, category])

add_expense(12.50, 'coffee')

यह एक काम करने वाला expense tracker है। यह scalable नहीं है, इसमें कोई tests नहीं हैं, और यह आपको कल कुछ ऐसा इस्तेमाल करने के लिए 90% तक ले जाएगा जिसे आप वास्तव में use कर सकते हैं। आप एक काम करने वाली ugly चीज को refactor कर सकते हैं। आप एक beautiful चीज को refactor नहीं कर सकते जो exist नहीं करती।

इसे कहीं deploy करें, भले ही बुरी तरह से

आपके laptop पर एक प्रोजेक्ट shipped नहीं माना जाता। इसे internet के सामने या किसी व्यक्ति के सामने रखें जो इसे खुद चला सके।

• CLI tool: इसे एक public GitHub repo में push करें एक दो-पैराग्राफ README के साथ जो सटीक install और run commands दिखाए
• Web app: Render, Fly.io, या एक $5 DigitalOcean droplet में deploy करें — एक project के लिए जिसमें एक user है, Kubernetes options की तुलना करने में तीन दिन न खर्च करें
• Script: एक cron job या GitHub Action सेट करें ताकि यह आपको छुए बिना चले

Deployment friction कहीं अधिक side projects को मार देता है किसी भी technical challenge से। अगर git push को एक platform जैसे Render में करना अभी बहुत अधिक है, तो बस इसे locally चलते हुए एक 90-सेकंड का Loom video रिकॉर्ड करें और भेजें। बात यह है कि बाहरी proof कि यह काम करता है, बुनियादी ढांचे की परिपक्वता नहीं।

लिखें कि क्या टूटा

Ship करने के बाद, पंद्रह मिनट तीन चीजें लिखने में खर्च करें जो गलत गईं और आपने उन्हें कैसे ठीक किया। किसी और के लिए नहीं — अपने लिए। यह असली सीखना है। ट्यूटोरियल ने आपको syntax सिखाया। टूटा हुआ pip install, CORS error, आधी रात में off-by-one date bug — वे आपको सिखाते हैं कि software वास्तव में कैसे व्यवहार करता है।

इन नोट्स को एक single running file में रखें। पाँच या छः छोटे projects के बाद, आप देखेंगे कि समान categories की bugs दोबारा दिख रही हैं, और यह आपका असली curriculum है: वह gaps जो tutorials कभी cover नहीं करते हैं।

फिर अगली चीज चुनें, थोड़ी बड़ी

एक CLI script से एक distributed system में न कूदें। एक बार में complexity का एक dimension जोड़ें: अगले project में CSV की जगह एक database होगा, या एक basic test suite, या एक दूसरा user। छोटे, compounding steps एक ambitious rewrite को हराते हैं जो तीसरे हफ्ते में रुक जाता है।

अगर आप इसके बाद structured next steps चाहते हैं, तो Korra Studio के Python और DevOps segments बिल्कुल deployment और tooling gaps को cover करते हैं जो लोगों के पहले shipped project के बाद उन्हें परेशान करते हैं।