Ship Something Small This Week

De meeste mensen die vast zitten in tutorialloops hebben geen vaardighedenproblem. Ze hebben een shippingproblem. Je kunt veertig uur Python-content kijken en toch bevriezen op het moment dat je gaat bouwen, omdat tutorials elk besluit voor je verwijderen. Deze gids is een dwingende functie: kies iets kleins, maak het af, zet het voor iemand neer, deze week.

Kies een project dat je in een weekend kunt afmaken

De foutmodus hier is scope. Mensen beslissen dat hun eerste project een SaaS-app met authenticatie, billing en een dashboard moet zijn. Dat is een project van zes maanden vermomd als een weekendproject.

Kies in plaats daarvan iets met één duidelijke functie:

• Een CLI-tool die bestanden in een map hernoemt op basis van EXIF-datum
• Een script dat een openbare API scrapet en je dagelijks een samenvatting e-mailt
• Een Flask-app met één formulier en één uitvoerpagina
• Een browserextensie die een sleutelwoord op elke pagina die je bezoekt markeert

Schrijf de scope in één zin op voordat je code schrijft. Als de zin meer dan eenmaal "en" nodig heeft, snij het weg. "Een tool die mijn uitgaven bijhoudt en ook categoriseert en ook in grafieken weergeeft" zijn drie projecten. Ship eerst de tracker.

Stel een echte deadline en een echt publiek in

Een deadline zonder gevolgen is geen deadline. Vertel het een vriend, post in een Discord-server, of zeg toe het vrijdag aan een collega te laten zien. Het publiek is belangrijker dan de deadline — weten dat iemand het echt gaat bekijken verandert hoe je het bouwt. Je stopt met architecture vergulden en begint ervoor te zorgen dat het gelukkige pad daadwerkelijk werkt.

Gef jezelf een getal, geen gevoel. "Ik werk eraan als ik tijd heb" levert niets op. "Twee uur vanavond, twee uur morgen, ship zaterdagochtend" levert een project op.

Bouw eerst de lelijke versie

Sla de mapstructuurdebatten over, sla het kiezen van een CSS-framework over, sla het kiezen tussen Postgres en SQLite voor een tool die veertig rijen opslaat over. Schrijf één bestand. Gebruik print()-statements in plaats van een logger. Gebruik een Python-lijst in plaats van een database als dat alles is wat je nodig hebt.

# expenses.py - ugly version, and that's fine
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')

Dat is een werkende uitgavenvolgger. Het is niet schaalbaar, het heeft geen tests, en het brengt je 90% van de manier naar iets dat je morgen daadwerkelijk kunt gebruiken. Je kunt iets lelijks dat werkt refactoren. Je kunt geen mooi iets refactoren dat niet bestaat.

Deploy het ergens, zelfs slecht

Een project op je laptop telt niet als verzonden. Zet het op het internet of voor iemand die het zelf uitvoert.

• CLI-tool: push naar een openbare GitHub-repo met een README van twee alinea's met exacte installatie- en uitvoeringsopdrachten
• Webapp: deploy naar Render, Fly.io, of een $5 DigitalOcean-droplet — besteed geen drie dagen aan het vergelijken van Kubernetes-opties voor een project met één gebruiker
• Script: zet een cron job of GitHub Action in zodat het zonder jouw tussenkomst draait

Deploymentwrijving doodt meer side projects dan enige technische uitdaging. Als git push naar een platform als Render te veel is op dit moment, maak dan gewoon een 90-secondenvideo met Loom van het lokaal draaiend en stuur die. Het punt is extern bewijs dat het werkt, niet infrastructuurrijpheid.

Schrijf op wat kapot ging

Na het verzenden, besteed vijftien minuten aan het opschrijven van drie dingen die fout gingen en hoe je ze hebt opgelost. Niet voor iemand anders — voor jezelf. Dit is het echte leren. De tutorial onderwees je syntaxis. De onderbroken pip install, de CORS-fout, de off-by-one datumbug om middernacht — die leren je hoe software echt werkt.

Bewaar deze notities in één doorlopend bestand. Na vijf of zes kleine projecten zie je dezelfde bugcategorieën steeds terugkomen, en dat is je echte curriculum: de gaten die tutorials nooit dekken.

Kies dan het volgende, iets groter

Spring niet van een CLI-script naar een gedistribueerd systeem. Voeg één complexiteitsdimensie tegelijk toe: het volgende project krijgt een database in plaats van een CSV, of een basistestsuite, of een tweede gebruiker. Kleine, samengestelde stappen verslaan één ambitieus herschrijven dat in week drie stilvalt.

Als je na dit artikel gestructureerde volgende stappen wilt, behandelen de Python- en DevOps-segmenten van Korra Studio precies de deployment- en toolinggaten die mensen doorgaans hebben na hun eerste verzonden project.