Ett tomt repo och ingen beställare: därför är helgprojekt värda tiden

Klockan är nio en lördag. Kaffet är hällt, kalendern är tom och ingen väntar på ett svar. Det enda kravet på det du tänker bygga är att du själv är nyfiken på det. Inget ärende, ingen sprint, ingen som ska godkänna.

Det är den bästa labbmiljön som finns. Flera av sakerna på den här sajten — reaktionerna under inläggen, Väntetidskalkylatorn, AGENTS.md-generatorn — började inte som uppdrag. De började som helgprojekt. Det här inlägget handlar om varför, och om reglerna som gör att ett helgprojekt faktiskt blir klart i stället för att bli ännu en katalog i ~/projects.

Varför helgen och inte arbetsveckan

Arbetsveckan har en beställare. Det är hela poängen med den, och det är också det som gör den dålig på en viss sorts lärande. Tre saker som helgen har och veckan saknar:

• Ingen kravspec. Du får byta mål halvvägs. Det du trodde var intressant på lördag morgon är ofta något annat vid lunch, och det är okej. Ingen har lovat någon någonting.
• Ingen som betalar för tiden. Det låter som en nackdel. Det är motsatsen. När ingen betalar behöver du inte motivera varför du provar ett verktyg du inte behöver, eller läser en README ända till slutet.
• Rätten att kasta. Ett helgprojekt som slutar med att du raderar katalogen och behåller insikten är ett lyckat helgprojekt. I ett uppdrag heter samma sak ”en misslyckad spike” och kräver en förklaring.

Vad som följer med till måndagen

Poängen med ett helgprojekt är inte projektet. Det är det som sitter kvar när det är klart.

• Ny teknik i skarpt läge. Att läsa om Upstash Redis är en sak. Att ha kopplat en till ett Vercel-projekt, sett miljövariablerna dyka upp och deployat en funktion som räknar rätt när två personer klickar samtidigt är en annan. Nästa gång en kund frågar ”hur svårt är det” har du ett ärligt svar i stället för en gissning.
• En känsla för var tiden går. Bygger du något från tomt repo till drift på en helg märker du precis var friktionen sitter: i konfigurationen, i deployen, i att hitta rätt sida i dokumentationen. Det är samma friktion utvecklare möter varje dag i en plattform, bara i miniatyr. Det är svårt att hitta en bättre skola i developer experienceDeveloper experience (DX)Developer experience (DX) är summan av hur det känns och hur lång tid det tar för utvecklare att göra sitt jobb: starta en tjänst, hitta dokumentation, få feedback från tester och deploya till produktion.Läs mer i ordlistan →.
• Något att peka på. En länk är värd mer än en åsikt. ”Vi tycker att AI-assisterad utveckling fungerar” är ett påstående. QRGeno är ett bevis, med kod och drift och allt.

AI flyttade gränsen för vad en helg räcker till

För några år sedan var en helg lagom för ett proof of concept: något som körde lokalt och visade en idé. Nu räcker samma tid ofta till idé, arkitektur, kod, deploy och ett inlägg om det. Inte för att koden skriver sig själv, utan för att de tråkiga sträckorna — boilerplate, konfiguration, att komma ihåg exakt hur ett API såg ut — går fortare med en agent i terminalen.

Det ändrar vad ett helgprojekt kan vara. Det som förut stannade i en anteckning kan bli något som ligger ute, med en adress, som andra kan använda. Och det ger en bonus: du lär dig hur du själv arbetar bäst med AI utan att en kund betalar för lärotiden.

Reglerna som gör att det blir klart

Alla har en katalog med halvfärdiga helgprojekt. Det är inte ett tecken på dålig disciplin utan på att projekten saknade ett slut. Det här är reglerna vi försöker hålla oss till:

• Bestäm slutet innan du börjar. ”Klart” betyder något konkret: en deploy, en länk, ett skärmklipp, ett inlägg. Inte ”när det känns bra”. Sätt målet så lågt att söndag kväll räcker.
• Lägg det där det syns. Ett projekt som bara finns på din egen dator är lätt att lämna. Ett som ligger ute, hur fult det än är, drar i dig att göra det lite bättre.
• Skriv ner det du lärde dig. Tre rader räcker. Vad överraskade, vad tog tid, vad skulle du göra annorlunda. Det är oftast de raderna som blir ett inlägg här.
• Avsluta med en commit, inte en TODO. Om det inte blev klart: committa där du är och skriv i README vad nästa steg är. Det är skillnaden mellan ett projekt som går att plocka upp och ett som går att glömma.

Fällorna

Helgprojekt har en baksida, och den är värd att säga rakt ut.

• Det får vara dåligt. Ett helgprojekt är inte en produkt. Inga tester, ingen felhantering, hårdkodade värden — helt okej, så länge du vet om det och inte tar med det till jobbet på måndag utan att städa.
• Det får ligga. Vissa helger vill man inte bygga något alls. Den som bygger av dåligt samvete bygger sämre än den som bygger av nyfikenhet. Helgen är också till för att inte sitta vid en dator.
• Det får förbli hobby. Inte varje helgprojekt ska bli ett företag. Den dag ett projekt kräver att du får betalt för att fortsätta har det slutat vara ett helgprojekt, och då förtjänar det en riktig plan i stället för lördagar.

Så börjar du

1. Välj något du är nyfiken på, inte något du borde lära dig. Nyfikenhet håller till söndag, ”borde” tar slut vid lunch.
2. Gör det litet. Ett verktyg, en funktion, en sida. Om du inte kan beskriva slutet i en mening är det för stort.
3. Bygg med det du vill lära dig, inte det du redan kan. Annars är det jobb.
4. Lägg ut det. En länk, ett repo, ett inlägg. Klart betyder synligt.
5. Skriv tre rader om vad du lärde dig. Stäng sedan datorn.

Vårt korta svar

Helgen är den enda labbmiljön där ingen har beställt något. Använd den till projekt som är små nog att bli klara till söndag kväll, synliga nog att någon kan klicka på dem och ärliga nog att du lär dig något. Och vissa helger: bygg ingenting alls.

Det här inlägget skrevs för övrigt en lördag.