Individuell skriftlig reflektion

Att genomföra ett projekt och nå ett lyckat resultat betyder inte nödvändigtvis att allt gick bra på vägen. En del saker blev säkert fel. Andra saker tog onödigt lång tid. Några saker var ni osams om hur ni skulle lösa. Planeringen visade sig allt för optimistisk och du gjorde ofta vad som kändes rätt för stunden istället, och större delen av arbetet hamnade i sista veckan. Allt det där är helt okej.

Men du kommer att göra fler projekt. I de ska du inte göra om samma misstag (men kanske andra misstag). Då gäller det att komma ihåg vad du gjorde, hur du gjorde, vad resultatet blev, hur lång tid det tog, om det var tillräckligt bra eller borde gjorts bättre, om det var onödigt och tiden kunde använts bättre till något annat, hur du med allt i färskt minne tror du borde gjort istället. Och sist men inte minst svara på VARFÖR för alla punkter ovan. Varför gjorde du som du gjorde, varför tog det lång tid, varför var det inte bra nog, varför kunde tiden använts bättre, varför skulle du göra på annat sätt?

Vad är då en reflektion? En reflektion kan beskrivas med Gibbs' reflective cycle. Nedan finns en bild som är ritad utifrån en beskrivningen av Harmon, A. (2024) 'Gibbs' reflective cycle', Salem Press Encyclopedia [Preprint]. Available at: https://research.ebsco.com/linkprocessor/plink?id=cd3f7780-ce07-377a-b3fd-d30067f58070 (Accessed: 2 October 2025)

I ditt reflektionsdokument behöver du ta dig till steg 3/4 (Evaluation/Analysis) i de flesta fallen. I ett par fall ta dig till steg 5 (Conclusion).

Målet med reflektionen är att kunna läsa den när allt är glömt och ändå förstå vilka bra och dåliga saker som gjordes, och kunna dra lärdom av det. Du skriver för dig själv, för att i nästa projekt göra allt snabbare med högre kvalité. Men att skriva för sig själv kan vara svårt - i skrivande stund vet du ju allt och glömmer lätt skriva ned det. Det är inte förrän du senare läser som du undrar varför du inte skrev ned mer motiv och bakgrund. Därför kan du istället tänka dig att du skriver för dem som går kursen nästa år, och vill ge dem så mycket information och så många välmotiverade tips som möjligt. (Din reflektion kommer enbart att läsas av kurspersonal om inte Du ger den till någon annan, men tänk att den skall vara läsvärd även för en oinsatt.)

Observera till slut att reflektionsdokumentet inte är en kursvärdering, utan en slags självvärdering av ditt egna arbete och samarbete. Det är alltså vad du gjort och inte gjort, och vad du själv kan lära av det som dokumenteras.

Har du synpunkter om kursen är mycket välkommmen att skriva en kursreflektion eller vad vi kan kalla det, men skriv då ett eget dokument med det. Även kursen kan säkerligen bli både bättre och sämre, och du sitter i bästa position att tala om det.

Inlämning

Varje person skriver ett eget reflektionsdokument individuellt. Reflektionsdokumentet lämnas in via e-post till er assistent. Skicka från er LiU-mail och med ämne TDP003: Reflektionsdokument.

Krav på din individuella reflektion

• Dokumentet skrivs i dokumentmallen
• Dokumentet är färre än 2 sidor text
• Välj ut några av de mest intressant sakerna av samarbetet i kursen. Inled med att beskriva hur du och din kompis arbetat, vad har du bidragit med och vad bidrog kompisen med (steg 1 i Gibbs modell).
• För dessa saker, beskriv dina tankar och/eller känslor kring det (steg 2). Fundera sedan över vad som var bra och dåligt med det (steg 3). Beskriv sedan varför det blev på detta sätt (steg 4).
• Inkludera både positiva och negativa erfarenheter av samarbetet.
• Gör sedan samma sak för dina erfarenheter av ett urval av teknikerna ni använt. Tänk här på att tekniker inte nödvändigtvis behöver vara just Flask. Ni har lärt er många allmänna tekniker inom programmering, så som procedurell abstraktion, abstrakta datatyper och moduler.
• Två av erfarenheterna du tar upp ska analyseras på ett sätt som gör analysen användbar i framtida kurser. Du behöver alltså här ta dig till steg 5 i Gibbs modell.
• Du skall relatera minst tre erfarenheter till vad som skrivs i Code Complete. Använd korrekta källhänvisningar i Harvard-, APA- eller IEEE-stil. Eftersom boken har relativt många sidor vill vi även att referenserna tar med sidnummer. Det finns ett exempel på detta längst ned på sidan.

Riktlinjer för din individuella reflektion

• Genom hela kursen har du fört dagbok om vad du gjort. Låt den ligga till grund för reflektionen. En riktigt bra dagbok som redan innehåller reflektioner och kanske till och med referenser till Code Complete innebär att mycket lite arbete kvarstår med detta dokument.
• Inlämning sker som pdf med höga krav på språk och tydlig layout. Korrekturläs. Använd flera rubriknivåer. Sätt tydliga relevanta rubriker. Använd bilder och figurer för att förtydliga eller exemplifiera det som beskrivs i text. Numrera figurer och tabeller och hänvisa i texten så bilden ingår i den röda tråden. Formatera konsekvent kod, filnamn, eller andra typer av nyckelord med en annan font. Infoga innehållsförteckning om det är motiverat utifrån sidantalet, färre än fem sidor behöver sällan förteckning, det är lätt hitta ändå.

Ett kort exempel på en icke-perfekt reflektion med referens i löptext

Här är ett kort exempel på hur en referens i Harvard-stil kan se ut i löptext. I min påhittade reflektion har jag här en erfarenhet som jag vill knyta till vad McConnell skriver om "Intellectual Honesty" i kapitel 33.4 (sidan 826). Observera att reflektionen här har en progression där jag börjar med att beskriva vad som hände. Sedan lägger man till analys om det som hände och klättrar upp i stegen i reflektionsmodellen. Exemplet är inte perfekt heller. Du kan exempelvis se om du läser på sidan 826 i code complete att jag med fördel kunde ha varit mer självkritisk och kanske lastat mindre av detta på min partner. McConnell skriver faktiskt att det är upp till dig att också lystna på andras förklaringar och göra bedömningar av om de förstår det de pratar om eller inte. Denna del hade med fördel också kunnats knytas in innan jag kom till steg 5 i reflektionen, och hade gjort min action plan (steg 6) bättre.

Under kursens gång så visade det sig att jag och min partner inte var på riktigt samma nivå. Jag kunde mer programmering från början och desutom hamnade min partner efter på grund av sjukdom ett par veckor in i kursen. I början av arbetet ledde detta till en hel del friktion när vi programmerade tillsammans, eftersom min partner ofta fick det att framstå som att de förstod vad vi gjorde, men att det senare visade sig att de inte förstod vad det var vi gjorde. Samtidigt var jag kanske ivrig med att ta mig framåt, så jag ifrågasatte det inte. Men efter att friktionen i gruppen hade växt med tiden så tog jag upp hur jag upplevde situationen. Det visade sig då att min partner hade låtsats att de förstod för att de var oroliga över att jag skulle tröttna på dem om de var för långsamma. Vi bestämde oss för att vara mer ärliga med varandra och oss själva i framtiden. McConnell (2004, s.826) beskriver att en del av att bli en professionell programmerare är att inte låtsas som att man är en expert när man inte är det. Vidare beskriver författaren att detta handlar om intelektuell ödmjukhet och frågar hur man kan lära sig något om man låtsas som att man från början kan allting? Detta möte var kritiskt för vårt samarbete i kursen och det var mycket bra att vi hade det relativt tidigt under arbetet. Efter mötet försvann mycket av frustrationen och det var roligare att arbeta tillsammans. Men i framtiden så ser jag att det hade varit bättre att ha det här mötet så fort jag upplevde problemet, vilket är något jag ska se till att göra i framtida kurser om jag upplever liknande eller andra problem.

Sidansvarig: Pontus Haglund
Senast uppdaterad: 2025-10-03