Första gången jag stötte på programmering var i gymnasiet då min klasskamrat visade mig hur man kunde programmera i BASIC på min TI-84 Plus. Sedan dess har över tio år passerat och genom åren har jag fortsatt fördjupat mig inom programmering. Jag har insett vad som främjar min inlärning på bästa sätt och kommer i det här inlägget beskriva den inlärningsprocessen och dra paralleller till arbets- och studielivet.

Learn, Code, Get Feedback (LCGF)

För att bli världens bästa programmerare behöver man bara följa tre enkla steg. Processen  kanske påminner om LEAN Startup-metodiken men en större skillnad är att ”Measure” är utbytt mot ”Get Feedback”.

Det första steget i processen är Learn. Detta innefattar alla olika sätt som finns för att införskaffa sig kunskapen som behövs för att programmera. Det kan till exempel handla om att läsa en tutorial eller lyssna på en föreläsning.

För att befästa kunskaperna man fått i Learn-steget behöver du aktivt tillämpa dem på egen hand. Detta sker i Code-steget och det är här du utför själva programmeringen.

Det avslutande steget i cykeln är ”Get Feedback”. Liksom Learn-steget kan detta ske på ett flertal sätt. Bland de enklaste sätten hör datorns eget sätt att ge feedback när du kör din kod, kanske fungerar ditt program som du tänkt eller så kraschar det och du får en felutskrift. Andra typer av feedback kan vara statisk kodanalys, exekveringstider och kanske det bästa av allt, ett omdöme från en mer erfaren programmerare om din kod.

Feedbacken som ges kan förhoppningsvis användas för att lära dig mer om programmering och ett nytt varv i cykeln påbörjas. Efter ett antal varv i loopen har du blivit världens bästa programmerare, nice!

LCGF tillämpad i arbetslivet

När jag arbetade på Westermo använde jag, inofficiellt och outtryckligen, LCGF i stor utsträckning. Eftersom jag var blott en nätverkstekniker bland kodproffs och gavs arbetsuppgifter som innefattade programmering var jag tvungen att lära mig programmering illa kvickt.

Jag minns särskilt två milstolpar som var viktiga i min utveckling som programmerare. Den första var när jag skulle skriva ett autotest med hjälp av Westermos testramverk som var objekt-orienterat och skrivet i Python. Jag hade begränsad erfarenhet av Python och objekt-orientering hade jag läst om men aldrig förstått vad det var bra till. Som tur var fanns min kollega Tobbe tillgänglig för att hjälpa mig komma igång och när han frågade nåt i stil med ”Har du jobbat med objekt-orienterad programmering?” kunde jag ärligt svara ”Nej” och fick sedan en kort introduktion av de viktigaste koncepten. Direkt därefter fick jag själv prova mina vingar och skriva lite kod på egen hand. Då jag stötte på problem kunde jag oftast ropa på hjälp och få feedback på min kod och tips på hur jag skulle komma vidare.

Den andra milstolpen var då jag arbetade med testsystemets hantering av ”test suiter”, där en test suite är en samling av tester som ska köras. En test suite definierades i form av en textfil som kunde innehålla antingen andra test suiter eller enskilda test. ”Test suiter som består av test suiter? Oh baby that’s recursion!” kanske några tänker men det gjorde inte jag eftersom jag aldrig hört talas om rekursion. Den gången fick jag ta hjälp av min kollega Fredrik som introducerade konceptet och gav lite exempel med Quicksort bland annat. Därefter kunde jag knacka ihop en rekursiv metod som gick igenom suite-filer och hämtade ut de enskilda testerna som fanns listade. Jag fick även feedback på min lösning efter att jag tillsammans med Fredrik gått igenom koden jag skrivit. Det var en givande arbetsdag!

Min poäng är att på Westermo arbetade jag oftast i korta cykler av LCGF där jag fick en uppgift, var tvungen att lära mig nya saker från kollegor eller genom Internet, tillämpade kunskaperna genom programmering av den specifika uppgiften och kunde därefter få feedback på mitt arbete genom att be någon kika på min commit. Det är utan tvekan det mest effektiva sättet för mig att lära mig programmering på som jag någonsin upplevt. Så vad fick mig att sluta? Ett flertal faktorer bidrog till att jag inte lärde mig nya saker i samma takt och möjligheten till feedback minskade, dvs ”Learn” och ”Get Feedback”-stegen blev lidande. Detta fick mig att leta efter alternativa sysselsättningar och där hade en utbildning på LiU länge funnits med i planerna. Inom kort var jag student på civilingenjörsprogrammet i mjukvaruteknik vid Linköpings Universitet. Låt oss kika på hur LCGF tillämpas där.

LCGF tillämpad i studielivet

Många kan nog föreställa sig hur LCGF kan kopplas till studierna. Under en kurs lär man sig typiskt nya koncept och tekniker som presenteras under föreläsningar eller genom kurslitteratur. Studenten får tillämpa dessa kunskaper genom laborationer där hen oftast skriver egen kod för att lösa någon uppgift. Koden redovisas och lämnas in för granskning vilket sedan resulterar i någon form av feedback, till exempel får vi studenter betyg (Godkänd eller 3, 4, 5).

Förutom betyget finns även möjligheten för labbassistenten att ge sitt omdöme på koden. Det kan till exempel se ut som på bilden nedan, som visar feedbacken jag fick på min inlämning av ett Tetris-spel jag gjorde i Java-kursen för ganska exakt tre år sedan.

Förutom bristen på styckeindelning är jag supernöjd med den feedback jag fick och jag lärde mig nästan lika mycket från den som jag gjorde av att utföra själva uppgiften i sig. Under mina år på LiU har jag dessvärre insett att feedbacken ovan är ett undantag från hur det brukar se ut. Låt oss ta en titt på hur feedbacken såg ut från en kurs jag läste i höstas. Kursen var i princip en enda lång labbserie och jag arbetade ensam vilket bidrog till att det var extra svårt att veta om jag gjorde på rätt sätt eller inte.

Även om jag är glad över att koden bedömdes som snygg är jag ändå missnöjd över att inte få veta vad som var särskilt bra och vad som kunde gjorts bättre. Inget ont om labbassistenten i fråga, han är inte ensam om att ge sparsam feedback och är i övrigt väldigt kunnig och engagerande, men jag känner att bristen på feedback har fått min utveckling som programmerare att stagnera. Jag programmerar i princip på samma sätt som jag gjorde för tre år sen i Java-kursen och blir godkänd varje gång men jag får aldrig veta vad jag kunde gjort bättre.

Någon kanske hävdar att om den enda kommentaren var ”Snyggt!” så fanns det inget att anmärka på och jag borde vara glad istället för att gnälla. Men är det något jag lärt mig under dessa år med programmering så är det att kod aldrig är perfekt skriven. Om någon vill bevisa motsatsen är jag idel öra.

En önskan om bättring

Varför är det viktigt att jag som student får feedback på min kod? Tja, förutom den uppenbara anledningen att jag lär mig bättre så är det också ganska vanligt att mjukvaruföretag i dagsläget använder kodgranskning som en del i utvecklingsprocessen där kollegor granskar varandras kod. Att som student förberedas på att ens kod ska läsas av andra och även få kritik på den kod man producerat är inget som bör underskattas eftersom det kan vara lite känsligt till en början. När jag pushar kod på min arbetsplats kommer inte kvaliteten enbart bero på om koden ger rätt resultat utan också om vägen dit sker på rätt sätt.

Det är möjligt att det skulle kräva ökade kostnader eller åtminstone ökade resurser för att ge studenterna bättre feedback men eftersom trenden verkar vara att föreläsningar ersätts med digitala motsvarigheter (videoinspelade föreläsningar osv) är mitt förslag att de pengar som sparas där istället läggs på rättning och granskning av kodinlämningar.

Jag tycker också att det borde vara i universitetets intresse att lägga lite krut på den här delen av utbildningskvalitet, om inte annat så för att höja konkurrenskraften. Jag har till exempel sett hur en av Udacitys kurser i machine learning lockar med ”1:1 feedback” i form av kodgranskning. Ett annat alternativ om man inte vill betala är förstås Stack Exchange’s Code Review som kanske inte håller den högsta kvaliteten men ändå bidrar med något mer än ett ”Snyggt”.

Om min poäng inte varit tydlig nog hittills så kan jag försöka förtydliga min åsikt: Universitet måste ge studenterna bättre feedback på deras inlämningar. Det gäller särskilt inlämnad kod men kan även sträcka sig till rapportskrivning. Examinatorerna bör uppmuntra detaljerad feedback, följa upp vilken typ av feedback som labbassistenterna ger studenterna och sätta tydliga riktlinjer för vilken feedback som förväntas ges. Jag tycker det är motsägelsefullt att jag längtar från universitetet ut i arbetslivet för att jag ska lära mig programmering bättre. Jag pluggar mjukvaruteknik på LiU för att komma närmare målet som världens bästa programmerare, men ibland känns det som jag endast kommer komma härifrån med en civilingenjörsexamen. Vore inte det tråkigt?

Jag har inte hört så många andra dela min uppfattning i den här frågan, men jag har å andra sidan inte öppnat upp för diskussion förrän nu. Om du som student/labbassistent/examinator inte håller med mig vill jag jättegärna diskutera vidare, så det är bara till att gå loss i kommentarsfältet eller kontakta mig på annat valfritt sätt! 🙂