Kategoriarkiv: Utbildning

Kurser på Mjukvaruteknik

Inspirerad av Mayukos video i vilken hon går igenom hennes Computer Science-examen på UCSD kurs för kurs tänkte jag göra detsamma för Mjukvaruteknik (U) på LiU. Eftersom jag gick ut 2018 har det hunnit ske vissa förändringar i programmet, men de övergripande dragen är sig lika.

Termin 1

TDDE23 – Funktionell och imperativ programmering, del 1
Första kontakten med programmering på U sker i den här kursen med hjälp av programmeringsspråket Python. Jag hade redan programmerat i Python i ett par år innan jag tog den här kursen så jag tyckte den var jätterolig, men det tyckte de flesta av mina kursare också. Utöver att programmera i Python får man även lära sig om LiUs dator-miljö, och lära sig lite bash, scriptspråk och kommandoprompt i Linux, och Emacs, en texteditor som är bra men lite annorlunda.

TATA65 – Diskret matematik
En av de roligare matematik-kurserna med bra synergier till första programmeringskursen och datavetenskap i allmänhet. Fick lära sig ett och annat om permutationer och kombinationer m.m.

TDDD70 – Ingenjörsprofessionalism, del 1
Kursen Ingenjörsprofessionalism går i långsam takt över de första tre åren. I kursen tas olika ämnen upp som berör ingenjörsrollen, bland annat social kompetens, ledarskap och etik. Till varje ämne skriver man en reflekterande text om sin inställning till att vara ingenjör. En ”flumkurs” enligt vissa men de individerna brukar inte klara sig så bra med studierna i helhet så det är mer av en mognadsfråga om man gillar den här kursen eller inte.

TDDE25 – Perspektiv på data- och mjukvaruteknik
En kurs med lite av varje inom datavetenskap med roliga projekt. När jag gick kursen gjorde vi en AI till spelet XPilot, men numera kan man även programmera AIs till Starcraft II.

TDDD72 – Logik
Många nya begrepp och ett annorlunda sätt att tänka på. Logik-kursen lägger grunden för några kommande kurser som t.ex. Formella språk och automatateori och kompilatorkonstruktion så det är lika bra att lära sig den här kursen bra för det får man igen senare. Till tentan får man ta med sig ett kompendium med massa logik-regler så det krävs inte så mycket memorering, bara ett logiskt tänkande 😉

TDDE24 – Funktionell och imperativ programmering, del 2
Fortsättning på TDDE23, med ännu mera Python! Bjuder på en datortentamen på slutet där man får sitta och programmera. Jag fick ett halvt fel på den tentan, och grämer mig fortfarande över det. Vet man inte hur rekursion fungerar sen tidigare får man lära sig det i den här kursen.

Termin 2

TDDD78 – Objektorienterad programmering och Java
Bra kurs med många viktiga OOP-koncept och massa programmering i Java. Föreläsningarna var ett bra sömnpiller men laborationerna och projektet var utmanande och stimulerande, man får till exempel programmera Tetris. Mitt personliga projekt hette ”Seven Letters” och var en sorts hänga gubbe-spel. Jag hade problem med att använda designmönster i mitt projekt så jag fick bland annat ta till Singleton-mönstret. Spelet fungerade tillsammans med ordlistor från Wiktionary och kunde använda reguljära uttryck för att filtrera ord.

Skärmbild av spelet Seven Letters, med dialogrutan för konfiguration av ordlistan

I kursen används IntelliJ IDEA, en av de bästa IDE:erna på marknaden.

TDDD80 – Projekt: Mobila och sociala applikationer
En ökänd kurs pga dess historiskt höga avhopp. Den här kursen har omarbetats i flera iterationer sen jag tog den, men grundstommen är densamma: Du ska lära dig mycket om lite allt möjligt. Webb- och applikationsprogrammering, UX och användbarhetstestning, enhetstestning, kodgranskning och versionshantering. Täcker in många av de områden som man ställs inför i arbetslivet, men är väldigt individuell. Jag gjorde en Android-app som hette Poetry Party, där användarna tillsammans skriver dikter. Dessvärre avslutades projektet innan appen nådde Play Store, för koden var full av buggar.

TSEA28 – Datorteknik Y
Assembly- och lågnivåprogrammering. Har aldrig använt kunskapen jag fick under den här kursen, men den är väl allmänbildande och viktig på det sättet att man ska veta hur en dator fungerar.

TDDD85 – Formella språk och automatateori
En mysig kurs om automater och reguljära uttryck. Bra uppladdning inför kompilatorkonstruktionen om man väljer att läsa den. Likt logiken är det ett nytt sätt att tänka på.

Termin 3

TATA24 – Linjär algebra
En kurs jag la ner mycket tid på, men klarade godkänt med minsta möjliga marginal. Har inte haft mycket användning av linjär algebra i arbetslivet, men det förekommer. Dessutom ger det mycket street cred att vara bra på linalg, mest för att det är så svårt.

TDDC93 – Programutvecklingsmetodik, teori
Mjukvaruteknik är ju mer än bara programmering och i den här kursen får man lära sig lite om kravhantering, design, utvecklingsprocesser (t.ex. Scrum), testning och kvalitet. Inte den roligaste kursen, men inte heller den svåraste. Har man jobbat på ett mjukvaruföretag tidigare, till exempel på ett sommarjobb mellan år 1 och 2 så är den här kursen en bit kaka.

TDDD86 – Datastrukturer, algoritmer och programmeringsparadigm
En stor kurs som täcker in många olika moment, men den absolut roligaste under mina första tre år på programmet. I kursen lär man sig att man inte kan vara naiv om man vill lösa svåra problem, då får man istället vara smart och använda rätt algoritm för jobbet. Man skriver en del C++ och inser att det är språk som har det mesta men som man hoppas slippa i arbetslivet. Jag låg sömnlös några nätter över att jag inte kunde lösa Rotate to root, en kluring om hur binära sökträd ska balanseras, men med lite tips och idéer från min medkursare löste det sig till slut och jag rekommenderar alla att lösa lite Kattis-problem eller liknande för att stimulera intellektet.

TATB04 – Inledande matematisk analys
I den här kursen får man lära sig att skriva matematik på ett korrekt sätt enligt MAI, matematiska institutionen på LiU. Det finns oftast bara ett rätt sätt och det är lika bra att lära sig det här från början så slipper man det fruktlösa käbblet under tentavisningen senare, som annars kommer låta såhär:

Student: Men det är ju uppenbart vad jag menar här!
Examinator: Fast vi är ju inte tankeläsare, därför får du 0 poäng på uppgiften.

Termin 4

TATA41 – Envariabelanalys 1
En rolig men utmanande matematikkurs. Här får du derivera och integrera (glöm inte +C) och enda sättet att lyckas, om man inte är ett matematiskt geni, är mängdträning.

TDDB68 – Processprogrammering och operativsystem
En rolig och allmänbildande kurs med en svår laborationsserie (dubbelpekare är inte intuitivt). Trådar och processer, minneshantering och filsystem och mycket mer. Viktig kurs för att bli en bra programmerare. Minns att jag tyckte om kurslitteraturen Operating system concepts, AKA dinosaurieboken. Mycket memorering till tentan!

TDDE35 – Storskaliga distribuerade system och nätverk
Eftersom jag läst två år nätverksteknik på MDH innan jag började på LiU tyckte jag den här kursen var ganska lätt och rolig, men generellt är den ganska utmanande med mycket att lära sig och göra. Att lyckas väl i den här kursen är nyckeln till framgång, det var så för mig iaf då jag fick möjlighet att vara labbassistent för labbserien under ett par år framöver och sedan skrev exjobb med Niklas som examinator vilket ledde till två publicerade artiklar. Det finns ju dock andra vägar till framgång, men god kunskap om nätverk behövs i princip alltid, så plugga hårt under den här kursen!

TATA91 – En- och flervariabelanalys
På min tid läste vi TATA90 istället för TATA91, och en skillnad är att Taylor- och Maclaurin-utvecklingar är med i TATA91 men var inte med i TATA90. Hursomhelst tyckte jag att den här kursen var rolig och var den enda kursen på MAI som jag fick 5:a i, ett av mina stoltaste ögonblick som student. Jag minns dock att jag spenderade påskledigheten med att plugga den här kursen, och jag minns inget av det jag lärde mig och har inte behövt använda det i arbetslivet heller. Men att lösa matematiska problem ger en inre tillfredsställelse och att applicera det i verkligheten är sekundärt.

Termin 5

TDAB01 – Sannolikhetslära och statistik
En kurs som jag bedömer som ganska svår, jag fick skriva tentan tre gånger innan jag äntligen blev godkänd, men då var jag å andra sidan bara en poäng ifrån 5:a. Det kan helt enkelt vara så att när den här kursen klickar så är det ganska logiskt och trevligt med sannolikhetslära och statistik. Viktig kurs för de som går vidare med maskininlärning tror jag, själv har jag sällan behövt använda mina kunskaper i statistik, men grundläggande kunskaper är viktiga för att förstå omvärlden och inse att människor är typiskt dåliga på att tolka statistik.

TDDC17 – Artificiell intelligens
Bra balans mellan teori (inte så intressant) och praktik (lite mer intressant). Jag fastnade aldrig för AI, men det är ju ett hett ämne så man får väl vara nöjd att det ingick i utbildningen för allmänbildningens skull.

TDDD92 – Artificiell intelligens – projekt
Jag skrev en individuell rapport om Monte Carlo tree search (MCTS) och hade ingen aning om vad jag skrev om, men fick ändå 4:a i betyg på rapporten och 5:a i kursen tack vare ett bra projektarbete, min grupp gjorde en AI för generella spel med hjälp av GVG AI. Nuförtiden tror jag de flesta gör en AI till Starcraft II. Lärde mig att även om plugget ibland känns hopplöst så löser sig det oftast bra om man ringer en vän och ber om hjälp. Blev inte mer intresserad av AI efter kursen, snarare tvärtom.

TDDD37 – Databasteknik
Relativt enkel kurs om SQL och databaser, men lär ut viktiga koncept för att designa en databas på ett korrekt och effektivt sätt.

TFYA87 – Fysik och mekanik
Skrev 0 poäng första försöket på tentan, vilket fick mig att inse att det inte fungerar att bara skriva ner anteckningar från föreläsningar och lektioner och sen komma till tentan och hoppas att man kan få poäng under tentan genom att kolla upp formler i formelsamlingen. Tog revansch genom att spendera en sommar med att faktiskt lära mig lite om fysik, som trots allt är intressant när man väl ger det chansen. Bra kurs om man ska jobba med 3D och spel kanske, men för egen del har jag inte haft någon användning av den och minns mest små fragment av hur man räknar ut tröghetsmoment.

Termin 6

TDDD96 – Kandidatprojekt i programvaruutveckling
Äntligen någonting som är på riktigt! Jag fick göra kandidatprojektet som ensam U:are tillsammans med 8 andra D:are och insåg att de är lite annorlunda men mycket trevliga. Vi gjorde en gullig liten webbapp kallad Knekt och skrev en finfin rapport om det.

TSKS24 – Signaler och bilder
På min tid läste vi TSKS21 – Signaler, information och bilder istället för den här. Jag vet inte varför de tog bort informations-biten som var den roligaste, men kanske för att det är tillräckligt svårt med bara signaler och bilder som det är. Jag minns att jag pluggade relativt mycket inför den här kursen och det var mycket att komma ihåg till tentan och jag har glömt i princip allting. Men nog är det väl så att faltning i tidsdomänen motsvarar multiplikation i frekvensdomänen (se faltningsteoremet). Gillar man den här kursen kanske man skulle läst Y eller D istället för U.

TSRT19 – Reglerteknik
Roliga laborationer och svår teori, en väldigt ingenjörs-nördig kurs. Har inte behövt PID-reglering sedan jag läste klart den här kursen, men reglerteknik har en viss charm.

Master-kurser (Termin 7-10)

När du klarat av de tre första åren har du förmodligen fått en känsla för vad du tycker är roligt och du vill läsa mer om, så jag behöver inte beskriva kurserna i detalj här. Jag läste mest kurser som handlade om programmering och mjukvara och valde profilen ”Storskalig mjukvaruutveckling”. För mer information om U-programmets masterprofiler, se följande länk.

LiUtopia

Att plugga sker i alla möjliga former och en typisk uppdelning är att arbeta i grupp eller att arbeta ensam. Även om grupparbete är den form som gett mig mest glädje under min studietid, tack vare den sociala aspekten, har jag ofta behövt en stor dos ensamarbete för att förstå kursmaterialet bra nog för att klara tentorna. Att kunna fördjupa mig i det jag finner svårast genom att läsa och se på videoföreläsningar är aktiviteter som lämpar sig bäst att utföras på egen hand med så få störningsmoment som möjligt. Ensamarbete kräver andra typer av resurser jämfört med grupparbete och i det här inlägget tänkte jag framföra några av utmaningarna solopluggandet medför och även presentera vad jag tror är den ultimata lösningen på problemen.

Problemformulering

Att jobba hemifrån kan tyckas vara en bra miljö för att arbeta ostört på egen hand, åtminstone om man bor utan livliga sambos iller husdjur. Dessvärre är det en inte helt perfekt lösning för mig då bristen på disciplin och den goda tillgången på distraktioner som datorer, disk och dammsugare får mig att lätt smita undan från plugget för att göra roligare saker. Istället söker jag mig vidare utanför lägenheten och då oftast till campus som är min de facto arbetsplats. Hur bra är universitetet på att tillgodose mina behov? Helt okej, men jämfört med LiUs tillgång och kvalitet på grupprum finns det brister. Det finns förstås stora valmöjligheter för var man kan slå sig ner för att plugga på campus. Jag brukar ta plats i Café Java, Key-huset eller kanske A-huset om jag känner mig äventyrlig.

Ett oundvikligt problem med dessa platser är ljudvolymen. Det är surret från läskkylen, klinket på pianot och de omåttligt glada tjoandet från ekonomerna som gör att studieron blir lidande. Inte varje dag, men ofta. Någon kanske tror att jag glömt bort bibliotekets tysta läsesal. Till er vill jag säga att med tanke på att salen utrustats med decibel-mätare och inretts med bilder på sovande tigrar (som man inte vill väcka och därför bör vara tyst?) så kanske salen trots namnet inte är så tyst ändå. Det säger sig självt egentligen att ett rum för ca 30 studenter aldrig kan vara tyst. Dörrar och ryggsäckar öppnas och stängs, det knattras på tangentbord, hostas och rosslas och alltid är det någon som tycker det är okej att viska med sin kompis.

Ett helt annat problem jag erfarit är oron för stöld. När jag pluggar uppstår lätt behovet av fikapaus eller toabesök. Då uppstår dilemmat om huruvida man vågar lämna laptop och väska utom synhåll under de 5-10 minuter som man är borta. Sannolikheten att någon skulle stjäla mina saker medan jag är borta bedömer jag vara väldigt liten, men inte obefintlig. Den risken är jag oftast inte villig att ta och därför blir det kanske något färre fikapauser än det hade kunnat bli, vilket både jag och caféerna förlorar på.

Ett par andra mindre irritationsmoment jag stött på är den låga temperaturen i vissa salar, vilket jag nämnt tidigare, och att starkt solljus tvingar mig till att maxa ljusstyrkan på min laptop vilket kraftigt begränsar batteritiden.

Nu har jag gnällt utförligt och länge och kanske är det uppenbart att det jag efterfrågar är mitt eget kontor. Men är det inte orimligt att ge tusentals studenter tillgång till personliga kontor? Ja det är det nog, men det är också det som gör det här till en spännande och rolig utmaning.

En gyllene chans

LiU har den här våren påbörjat rivningen av Origo, en av byggnaderna på Campus Valla. Detta för att ge plats åt en ny byggnad, Studenthus Valla/Origo II, som planeras bli en byggnad som täcker nästan alla behov en student kan ha; bibliotek, Studenthälsan, studentfik och förstås studieplatser.

En illustration av LiUs nya byggnad Studenthus Valla

Illustration: White arkitekter

I de preliminära ritningarna har jag inte sett några förslag som löser problemen jag tidigare listade men eftersom huset inte har byggts än finns det förstås tid för ändring. Därför går vi nu raskt vidare till mitt förslag om bättre studieplatser, vilket presenteras i form av en så kallad user story.

En dag på Campus Valla

Klockan är 8:08 och denna tisdags datum är den 14e april 2020. Tina har parkerat cykeln och går med raska steg mot universitetets modernaste byggnad som skimrar i vårsolen. Efter att ha tagit sig två trappor upp kommer hon fram till studentcellerna. Tina har bokat cell 7 och tar fram sitt LiU-kort som hon blippar mot cellens låsterminal. Dörren glider upp och hon möter sin arbetsplats för dagen. Rummet är två meter brett och tre meter långt. Längs bort i rummet finns en stol och skrivbord och en enkel men bekväm soffa står mot rummets vänstra sida. Tina stiger in i rummet och hänger av sig ytterkläderna. Dörren stängs och på dess insida finns en tryckkänslig skärm som hälsar henne välkommen och presenterar ett antal val. Tina anger önskad rumstemperatur till 21° C och justerar det elektrokromatiska fönstret så att precis lagom mycket solljus kommer in. På skärmen finns det alternativ av olika ljudslingor för rummets högtalare att spela, bland annat fågelsång och åskstorm, men Tina väljer till slut havsbrus. Hon aktiverar även pomodoro-läget vilket gör att en vänlig röst påminner henne om att ta en kort paus (som hon ägnar åt armhävningar) efter varje arbetspass à 25 minuter.

Efter två timmars plugg av flervariabelanalys är det hög tid för fika. Eftersom cellen endast kan låsas upp av Tina under de timmar hon bokat den lämnar hon helt sonika sina tillhörigheter i cellen för att springa ner till studentfiket några trappor ner. Fiket myllrar av kaffesugna studenter och efter en kort pratstund med Johan och Lina tassar de tillbaks till sina respektive celler. Väl tillbaka stänger hon av havsbruset och njuter kort av tystnaden innan hon sätter sig till rätta i soffhörnet med sin mekanik-bok.

Tina har pluggat effektivt hela förmiddagen och väljer att ta lunch redan 11:45 och hinner mikra sin matlåda innan den värsta lunchrushen. Hon checkar ut ur cellen vilket gör den tillgänglig för andra även fast hennes bokning gällde fram till 12:30. Efter en hel förmiddag i lugn och ro har hon gott om energi för eftermiddagens projektmöte och föreläsning. Tina finner det en smula ironiskt; Celler som historiskt sett använts för att minska en persons frihet har nu istället gett henne större frihet än hon kunnat önska.

Reflektion

Jag gillar förstås idén om det högteknologiska och mysiga enkelrummet för LiUs framtida studenter men med ett sådant här förslag känns det viktigt att tänka på dess risker och begränsningar. Den här typen av rum är självklart mer kostsamma att konstruera jämfört med att bara slänga upp ett antal bord och stolar på en öppen yta. Å andra sidan tror jag de kommer ha mycket högre användningsgrad jämfört med universitetets traditionella grupprum och om de dessutom kan höja studiekvaliteten och därmed också studieresultaten (=> färre omtentor) tror jag att ROI:n inte blir så dålig ändå.

Det kan eventuellt bli problematiskt om rummen används för annat än att studera i. Ett avskilt rum på 6m² i kombination med studenternas gränslösa fantasi vore sannerligen ett spännande socialt experiment. Men med tanke på LiUs marknadsföring ”Hooka är LiU” tror jag inte vi ska vara alltför oroliga för att universitetet får sitt eget red light district utan snarare se det som en positiv bieffekt. 😉

Kanske har du som läsare också några tankar om huruvida den här idén är bra eller dålig. Löser den mina problem på bästa sätt? Eller är mina problem ens giltiga till att börja med? Jag tar tacksamt emot alla förslag på förbättringar. Tycker du idén är fantastisk förslår jag att du vidarebefordrar den till vänner och universitetsstyrelse. Om du dessutom är LiU-student finns det ju världens möjlighet att framföra dina önskningar genom den stora studentundersökningen som pågår fram till 20e april. Undersökningen har ett väldigt blygsamt deltagarantal så det finns goda möjligheter att vara med och påverka!

Glad påsk!

Force Feedback

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”.

Learn, Code, Get Feedback. Process för att lära sig programmering.

Trestegsprocess för att lära sig programmering.

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.

Detaljerad feedback på mitt tetris-spel.

Ett exempel på bra och väldetaljerad feedback.

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.

Ett exempel på mindre bra och odetaljerad feedback.

Ett exempel på mindre bra och odetaljerad feedback.

Ä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! 🙂

Boktipset: The Psychology of Computer Programming

I höstas läste jag kursen TDDD30 Avancerad programutvecklingsmetodik. I kursen ingick att läsa The Guide to Software Engineering Body of Knowledge (SWEBOK Guide) vilken är en sorts guide till nästan varje ämne inom Software Engineering. Eftersom kursens deltagare hade olika bakgrund var det upp till varje student att själv välja vilka delar som denne skulle läsa. Jag läste förmodligen mindre än jag borde gjort, men i kapitel 11 som behandlar gruppdynamik, psykologi och kommunikation fanns en referens som väckte mitt intresse. Det var Gerald M. Weinbergs The Psychology of Computer Programming som också är ämnet för det här inlägget.

Framsida av boken The Psychology of Computer Programming

Struktur och indelning

The Psychology of Computer Programming utgavs ursprungligen år 1971 men som ni kan se på bilden läste jag silverbröllopsutgåvan, utgiven 1998, där varje kapitel utökats med författarens kommentarer som han skrivit 25 år senare. Boken är på många sätt ett historiskt dokument över hur programmering och mjukvara framställdes på 70-talet och eftersom industrin genomgått stora förändringar sedan dess uppskattas de mer aktuella tankarna från 90-talet. Allra bäst vore om det funnits en gold anniversary edition men den har tyvärr inte givits ut.

Boken är uppdelad i fyra delar som i sin tur är uppdelade i kapitel. I slutet av varje kapitel ges en bibliografi för vidare läsning och det ställs frågor till läsaren. Frågorna är riktade till antingen programmerare eller chefer som bossar över programmerare och bidrar till att läsaren kan applicera materialet till eventuella egna situationer.

Nedan följer mina personliga utsvävningar från några av bokens kapitel. Om ni tycker saker verkar tagna ur sitt sammanhang är min rekommendation att ni läser boken, den är bra!

Chapter 1: Reading programs

Redan i bokens första kapitel blir det uppenbart att boken är skriven för mer än ett halvsekel sedan. Det kodexempel som ges är skrivet i programmeringsspråket PL/I, vilket jag sedan tidigare inte ens visste var ett programmeringsspråk. Språken som används i boken är oftast FORTRAN och PL/I och det känns ibland ganska avlägset. Som tur är handlar det mesta i boken snarare om psykologi samt människor och eftersom människan inte förändrats lika mycket som programmering under de senaste 50 åren har boken åldrats med värdighet och fungerar än idag.

Chapter 2: What makes a good program?

Kapitlet tar upp och jämför faktorer som uppfyllelse av krav, leverans enligt tidplan, anpassningsförmåga och effektivitet. Weinberg levererar en rolig anekdot som cementerar det faktum att om programvaran inte fungerar är prestandan (och andra krav) irrelevanta.

Chapter 3: How can we study programming?

Ett intressant fenomen som försvårar observationsstudier är Hawthorneeffekten som innebär att subjektet för studien omedvetet förändrar sitt beteendet på grund av att hen vet om att hen blir observerad. Slutsats: Det är svårt att utföra psykologiska experiment!

Chapter 4: The programming group

Weinberg myntar i detta kapitel programmeringsmetoden egoless programming och argumenterar för hur mycket bättre allt blir om man tar bort sitt ego ur mjukvaruproduktionen. Dessutom nämner han hur John von Neumann ”was constantly asserting what a lousy programmer he was” vilket var helt annorlunda mot vem jag föreställt mig att von Neumann var. Jeff Atwood har ett läsvärt inlägg om egoless programming på sin blog coding horror.

Chapter 5: The programming team

Två intressanta uttryck i detta kapitel:

  • Parkinsonianism
    Parkinsons lag kan formuleras: ”Ett arbete kommer uppta den tid som är avsatt för ändamålet.” Det blir alltså väldigt svårt att konstruera en tidsplanering (med nödvändig ”slack” ifall något går galet, vilket det alltid gör) om arbetet kommer expandera utifrån planeringen.
  • ”Call to the cloth”
    Jag vet inte riktigt vad det betyder, men det verkar ha nåt med tro och religion att göra. Hör av dig om du kan förklara dess betydelse för mig. 🙂
    Uppdatering 2017-02-06: En av mina kunniga läsare hörde av sig och gav följande förklaring till uttrycket: ”Det betyder kallelse till präst. The cloth syftar på själva prästkåpan.” Förklaringen passar väl in i bokens kontext där Weinberg ger exempel på orsaker till förlust av gruppmedlemmar befordran, uppsägning, sjukdom etc.

Chapter 6: The programming project

Ganska ofta i boken berör Weinberg ämnet (bristen på) kvinnor i mjukvaruindustrin. Under 70-talet var könsfördelningen inom branschen ungefär som jag känner igen den idag; ca 90% män. I boken nämns som hastigast hur detta ändrats under sent 80-, tidigt 90-tal och blivit mer jämlikt. Weinberg beskriver hur det var enklare att bilda stereotyper av kvinnliga programmerare då de var få men att dessa stereotyper upplöses då de blir mindre sällsynta.

I samband med att jag läste detta såg jag även dokumentären Genusbuggen (eng. titel Code: Debugging the gender gap) som trots att den var väldigt amerikansk var klart sevärd. Detta fick mig att fundera hur könsfördelningstrenden i Sverige ser ut idag och därför gjorde jag en liten undersökning. Utifrån sökstatistik från UHR plottade jag andelen kvinnor som sökt till civilingenjörsprogram i datateknik under perioden 2008 till 2016. Resultatet finns att ta del av i ett Google Spreadsheets-dokument eller, om ni inte är intresserade av data-underlaget och interaktion med diagrammet, i bilden nedan.

Resultat över andel sökande kvinnor till civilingenjörsutbildningar i datateknik i Sverige år 2008 till 2016.

Med försiktig optimism vill jag ändå påstå att det är en positiv trend vi ser, heja heja!

Chapter 8: Personality Factors

Weinberg tar upp ett flertal typer av personlighetstester, men det är inte förrän i 25-årskommentarerna som Myers-Briggs Type Indicator (MBTI) kommer på tal, helt enkelt för att MBTI presenterade först 1980. Av en tillfällighet hade jag, i TDDD30, läst en studie om parprogrammering som kritiserat MBTI och istället rekommenderade IPIP-NEO. Personligen föredrar jag nog ändå MBTI, om inte annat så för att man på https://www.16personalities.com enkelt kan testa sig och även se vilka kändisar som delar ens personlighetstyp. Enligt mitt testresultat har jag samma typ som Neo i Matrix så helt kasst verkar inte MBTI vara. 😉

Chapter 10: Motivation, Training, and Experience

Jag gillar de frågor författaren riktar till cheferna i det här kapitlet. ”Skyddar du dina programmerare från att arbeta för mycket? Avundas du deras entusiasm till deras arbete? Uppmuntrar du dem till att arbeta på det sätt som passar dem bäst? Får de jobba hemifrån och ha flexibla arbetstider? Uppmuntrar du till fortbildning?” Vissa frågeställningar kan tyckas banala men kapitlet och stora delar av boken tydliggör skillnaderna mellan chef och programmerare och de utmaningar som kommer med dessa.

Part 4: Programming Tools (Chapter 11-13)

I bokens sista del gör sig 70-talet påmint igen: ”... although the assembly programmer may scoff at the machine-language programmer, he may be in turn the object of amusement for the user of a language with macro facilities.” Hela part 4 är väldigt old-school och låg-nivå och jag har ofta svårt att sätta mig in i situationer som handlar om hålkort, COBOL och obskyra operativsystem. Ett avsnitt ”Time sharing vs batch” minns (och förstod) jag ingenting av.

Slutord

The Psychology of Computer Programming var fram till de sista tre kapitlen, då bokens ålder blir alltför påtaglig för mig, en mycket underhållande skrift. Weinberg bjuder på en uppsjö av roliga anekdoter som får en att känna igen sig och reflektera över sitt eget och sina kollegors beteende. Den är relevant både för programmerare och chefer till programmerare och även om vissa lärdomar kan tyckas triviala (t.ex. en programmerare med tandvärk presterar inte så bra han/hon kan) finns det många viktiga aspekter att diskutera och reflektera över, för programmering handlar förstås om mycket mer än vilket språk vi skriver i.

Betyget blir tre av fem riviga rävar.

math-quiz

Den här julen har jag för första gången under min studietid på LiU haft jullov på riktigt. Med det menas att jag inte behövt plugga inför några januaritentor alls, vilken lyx!

Denna möjlighet att spendera julen med att göra precis vad jag velat har resulterat i en app jag kallar math-quiz. Framtagandet av math-quiz har inkluderat både programmering och matematik, så lustigt nog blev det inte alltför stor skillnad mot tentaplugget. Många kanske undrar varför jag valde att skapa math-quiz och hur det gick till på vägen. Därför tänkte jag försöka besvara dessa frågor med just det här inlägget.

Syfte

Något som ofta nämns i samband med civilingenjörsutbildningar är hur matematikintensiva de är. I examenskraven för civ.ing. i mjukvaruteknik står att minst 45hp kurser inom matematik eller tillämpning inom matematik ska ingå i utbildningen. I min utbildning sprids dessa 45hp ut i början på utbildningen och därmed är det examenskravet uppfyllt redan efter de första tre åren.

När jag nu gick första terminen på det fjärde året märkte jag en ganska stor förändring i det att jag inte längre läste någon mattekurs med föreläsningar, lektioner, frustration och allt det roliga som det innebär. Det var inte helt utan obehag som jag insåg att kurserna jag valt (designmönster, mjukvarutekniskt entreprenörskap, interaktionsprogrammering, etc) inte krävde några matematikkunskaper över huvud taget. Jag blev fundersam över om jag läst all matematik helt i onödan. Än värre, jag slogs av tanken att mina hårt förvärvade matematikkunskaper sakta skulle förvittra utan underhåll. ”Not on my watch” tänkte jag och började klura på hur jag kunde hålla igång mattekunskaperna på bästa sätt. Jag gillar quizar och tipspromenader så om jag kunde kombinera detta med en webb-applikation skulle det bli perfekt uppvärmning inför kurserna i webbprogrammering som jag ska läsa nu till vårterminen.

Metod

Jag började med att googla på ”JavaScript quiz library” och fick en träff på en React-baserad lösning kallad JavaScript Quiz som utgjorde en perfekt grund att bygga vidare på. React är ju dessutom väldigt poppis och jag såg fram emot att lära mig mer om det. Jag var till och med så optimistisk att jag trodde det skulle gå snabbt och enkelt att skapa min matte-quiz. I själva verket skulle det gå långsamt och svårt, men det är ju förväntat när man ger sig ut på okänd mark.

Grafer ❤

Tidigt i processen fick jag en idé om att jag ville presentera resultatet från quizen som en spindelgraf. Alltså, användaren besvarar frågor inom olika matematiska områden och får därefter en tydlig bild över dennes kunskap inom de olika områdena.

I min grupps kandidatprojekt Knekt använde vi oss av Highcharts med stor framgång. Jag körde vidare på det vinnande konceptet och efter några npm-installationer (react-highcharts för grundfunktionalitet och highcharts-more för spindeln) och en del bök lyckades jag smälla upp en fet graf som ni ser på bilden nedan.

Spindelgraf över resultatet från en omgång av math-quiz.

Inställningar

Jag ville utöka funktionaliteten från den mycket enkla JavaScript Quiz och gjorde en Settings-sida där användaren bland annat kan välja vilka matematiska områden och hur många frågor quizen ska innehålla. Detta var ganska straight-forward med undantag för att jag valde att använda mig av react-numeric-input för lite enklare hantering av antal-frågor-väljaren. Jag skriver ”ganska straight-forward”, men med mina obefintliga kunskaper inom React ger bilden nedan en rättvisare beskrivning. Det är dock förvånansvärt hur långt man kan komma med Google och Stack Overflow. 😉

I have no idea what I'm doing dog

All I want for Quiz-mas is a nice little matrix

Efter allt strul med Settings-funktionaliteten var det dags att få till lite schyssta matte-frågor. För detta krävdes ett snyggt sätt att representera matematiska formler, integraltecken och matriser. Självklart ville jag använda mig av Latex, men det skulle visa sig vara en mycket hård nöt att knäcka. Jag började med att prova react-latex och react-matrix, men det var inte alls vad jag behövde. När jag snubblade över react-katex trodde jag att jag hittat den heliga graalen. K:et i katex står för Khan som i Khan Academy som jag tidigare haft stor användning av. Deras latex-lösning skulle definitivt duga för mig, dessutom ritas formlerna snabbt utan lång väntetid. Tyvärr lyckades jag aldrig få katex att fungera på rätt sätt utan mina formler ritades ut både TeX-ifierade och som vanlig text, mycket likt detta issue på GitHub. Jag slet i en dag med det men lämnade till slut Katex för en motsvarande lösning, MathJax.

MathJax fungerade! Tyvärr sker en liten fördröjning vid utritningen och av en outgrundlig anledning minskas dess font-storlek efter första frågan så texten blir lite för liten. Men ingen mjukvara utan buggar tänkte jag och valde att släppa math-quiz lös på internet.

Framtida arbete

För dig som tycker att math-quiz verkar intressant och vill bygga vidare på det finns projektet på GitHub. Förutom att fixa visuella buggar och snygga till GUI:t vore det även nice med fler frågor och utökad funktionalitet. Har du feedback eller vill bidra till math-quiz är jag idel öra!

Slutsats

Jag är tacksam över att kunna stå på de giganters axlar som skapat React, npm och alla små fina paket för formler, grafer, etc. WebStorm är en bra IDE, webbprogrammering är svårt och solo-programmering kan vara ganska jobbigt om än lärorikt.

För övrigt tänkte jag nu försöka ha jullov på riktigt. God fortsättning!

Mjukvaruteknik vs Datateknik

En av de vanligaste frågorna jag får när jag berättar att jag pluggar Mjukvaruteknik är ”Vad är skillnaden mellan mjukvaruteknik och datateknik?” och om personen som frågar är något mer insatt kanske hen frågar ”Så mjukvaruteknik är som datateknik utan hårdvara?”. Båda frågorna är rimliga och relevanta, men då det finns markanta skillnader mellan programmen är det inte alltid helt lätt att ge ett korrekt och uttömmande svar. För de blivande studenter som undrar vilket program de ska söka vill jag med detta inlägg peka på de viktigaste skillnaderna, och slå ett slag för att Mjukvaruteknik är BÄST!

Bakgrund

Det finns en del diskussioner av varierande kvalitet om programmen på diverse forum. De bästa jag har stött på är dessa:

Flashback: #1 och #2.
Reddit: #1 och #2.

I mitt inlägg kommer jag använda vissa begrepp som kan vara okända för de som inte läser till civilingenjör på LiU, här kommer därför en kort ordlista med förklaringar:

  • D – Programbeteckning för Datateknik
  • U – Programbeteckning för Mjukvaruteknik
  • Envarre – Envariabelanalys, en matematikkurs
  • Flervarre – Flervariabelanalys, också en matematikkurs

Kurser

Ett utmärkt sätt att jämföra programmen på är att se vilka kurser som ingår. Flera kurser samläses på D och U. Detta visualiseras i Venndiagrammet.

Venn-diagram över kurser på D och U.

Venndiagrammet visar att U läser något färre kurser än D. En mer detaljerad bild ges genom tabellerna nedan. Om någon kurs låter extra intressant är det bara att googla på kurskoden så dyker dess kurshemsida upp som första träff, förmodligen.

Kurser som D och U samläser

KurskodKursnamn
TDDD86Datastrukturer, algoritmer och programmeringsparadigm
TDDC66Datorsystem och programmering
TATA65Diskret matematik
TATA41Envariabelanalys 1
TDDD73Funktionell och imperativ programmering i Python
TDDD99Ingenjörsprofessionalism
TATA79Inledande matematisk analys
TDDD96Kandidatprojekt i programvaruutveckling
TATA24Linjär algebra
TDDD78Objektorienterad programmering och Java
TDDD63Perspektiv på datateknik/datavetenskap
TDDB68Processprogrammering och operativsystem
TDDC93Programutvecklingsmetodik teori

Kurser som D läser

KurskodKursnamn
TSEA83Datorkonstruktion
TSEA82Datorteknik
TSEA22Digitalteknik
TSEA24Elektronik
TATA42Envariabelanalys 2
TATA76Flervariabelanalys
TFYA86Fysik
TDDD60Interaktiva system
TAOP33Kombinatorisk optimering gk
TSEA29Konstruktion med mikrodatorer, projektkurs
TDDD88Logik
TAMS27Matematisk statistik
TFYY68Mekanik
TSRT12Reglerteknik
TSKS10Signaler, information och kommunikation
TSDT84Signaler och system samt transformer

Kurser som U läser

KurskodKursnamn
TDDC17Artificiell intelligens
TDDD92Artificiell intelligens – projekt
TDDD37Databasteknik
TSEA28Datorteknik Y
TATA90Flervariabelanalys och differentialekvationer
TDDD85Formella språk och automatateori
TFYA87Fysik och mekanik
TDDD72Logik
TDDD80Projekt: Mobila och sociala applikationer
TSRT19Reglerteknik
TDAB01Sannolikhetslära och statistik
TSKS21Signaler, information och bilder
TDDD93Storskaliga distribuerade system och nätverk

Analys

Tabellerna ovan avslöjar flera viktiga skillnader mellan programmen. Det som ursprungligen fick mig att välja mjukvaruteknik var att D läser Datorkonstruktion, Digitalteknik och Elektronik medan U läser AI, Databasteknik och projektkursen Mobila och sociala applikationer (Android-utveckling). Jag tycker det är jätteroligt att bygga datorer, men att förstå mig på tekniken bakom lockar inte. Att däremot kunna slänga upp en databas och knåpa ihop en Android-app är både roligt och användbart.

D har bredden, U har spetsen

U är inte en lika bred utbildning som D, men den är kärnfull. Till exempel läser D separata kurser i Fysik och Mekanik medan U endast läser en kurs som kombinerar de två ämnena. Samma sak gäller för matematiken där D läser både Envariabelanalys 2 och Flervariabelanalys medan U istället läser kursen TATA90: Flervariabelanalys och differentialekvationer. I TATA90 har man plockat in de viktigaste delarna ur envarre 2 för att förstå momenten i flervarren. När vi är inne på ämnet matematik och flervariabelanalys tänkte jag visa lite statistik från tentaresultaten från respektive programs flervariabelkurs:

Tentastatistik för kursen TATA76
Tentastatistik för kursen TATA90

Slutsatsen från bilderna ovan är alltså, om du inte vill ha betyg U i flervarre, gå U. Jag är inte säker på att det här är en rättvis jämförelse, man kan ju nästan aldrig lita på statistik men TATA90 var den bästa matematikkurs jag läst. Det är ett ganska ovanligt uttalande när det kommer till flervariabelanalys skulle jag tro.

Masterprofiler

Till det fjärde och femte året följer de flesta studenterna en masterprofil, dvs specialiserar sig mot något ämne de tycker är intressant. Eftersom att D har en bredare utbildning med all elektronik och signalteori är de också kvalificerade till fler masterprofiler. U kan endast välja mellan 6 mjukvaruinriktade masterprofiler, men jag tycker det räcker till gott och väl. Vill man ha lite mer information om vilka profiler som finns kan man kika på dessa här.

Slutplädering

Hittills har jag varit ganska objektiv i inlägget, men det är slut från och med nu. Här kommer de bästa argumenten för att välja U.

U är ett kreativt program

En stor del av studierna på U går ut på att skapa saker genom mjukvara. I utbildningen ingår App-utveckling, AI-programmering (typ programmera robotar som spelar fotboll) och annat kul. Jag skulle vilja påstå att U är LiUs mest kreativa program, med brasklappen att jag har rätt dålig koll på vad som händer på Design och Produktuveckling (DPU) och Medieteknik (MT).

På U har nästan varje kurs anknytning till programmering. En viktig skillnad gentemot D är att U bakar in programmeringsmoment i kurser som annars hålls rent teoretiska, några exempel är statistikkursen där vi fick lära oss programmeringsspråket R och i fysiken fick vi använda våra kunskaper för att göra ett enkelt spel där vi programmerade fysiken. (Tyvärr ska de visst ta bort programmeringsprojektet i fysikkursen till kommande år och istället ha en större tentamen men så kan det vara när man inte vill att studenterna ska ha roligt.)

Även om allt jag skapat under mina år på LiU inte är mästerverk så är konceptet att under hela utbildningen alltid läsa minst en kurs som innehåller programmering väldigt viktigt. Programmering är ett hantverk som kräver tusentals timmar att bemästra. Som student på Mjukvaruteknik kommer du ständigt utöka och underhålla kunskaperna i programmering vilket gör U till den överlägset bästa civilingenjörsutbildningen för den som söker ett arbete som innefattar programmering.

Signaler^2

D har hela två kurser som har ”Signaler” i titeln. Min personliga åsikt är att man endast behöver genomleva en kurs i signalteori för allmänbildningens skull. Därefter kan man släppa det ämnet till förmån för roligare och mer relevanta ämnen. Som blivande student kan det vara svårt att greppa vad signalteori handlar om så låt mig ge en bild som exempel:

Spektrum av nedsamplade signaler.
Ser det här roligt ut? Isf kanske du borde läsa D eller Y. 😉

Signalteori är ett fascinerande ämne och jag är glad att det finns människor som tycker det är roligt, men det är bland det mest obegripliga jag stött på. Jag har varken gjort lumpen eller läst D, men det känns som båda ger erfarenheter av härdande karaktär. Det är inte kul när man gör det, men man kommer ur det starkare än någonsin. Jag ser på mina vänner som gjort lumpen iller läser D med stor beundran och respekt, ni är hjältar!

Mjukvaran är själen i svensk industri

Under mitt korta arbetsliv har jag haft kollegor som pluggat D, Y, TBI etc. Samtliga har arbetat med programmering och det är tveklöst en av de mest eftertraktade kompetenserna idag. Ett av mina favoritcitat från STEW 2016 kom från en av höjdarna på ett av Linköpings större företag:

It is all software. The electronics and mechanical engineers are lost!

Att läsa Mjukvaruteknik är inte bara roligt, det är också den utbildning som gör dig bäst lämpad för framtiden. THE FUTURE IS SOFTWARE!

Slutord

Att ge ett uttömmande och korrekt svar på frågan ”Vad är skillnaden mellan mjukvaruteknik och datateknik?” var svårare än jag trodde. Kanske är det här inlägget bara en ursäkt för mig att göra roliga grafer och diagram i R, men jag hoppas att det kan hjälpa någon. Om det är något du fortfarande undrar eller inte håller med om så gör din röst hörd i kommentarsfältet.

Skrytbrädan #1

Håll i hatten för nu blir det åka av! Jag tänkte skriva om mina fantastiska bedrifter och framgångar från den senaste tiden. Det är väl knappt att man får vara såhär mallig i dagens samhälle, men jag tänkte att på min egen blogg som nästan ingen läser borde det vara okej.

Statistik och sannolikhetslära – no problem!

Höstterminen 2015 läste jag kursen TDAB01, en grundkurs i statistik och sannolikhetslära. Efter en dålig start med lektionsuppgifterna lyckades jag aldrig fokusera på att lära mig och förstå materialet och då kursen var helt ny fanns inga gamla tentor att plugga in och därför var den första kuggningen i mitt studieliv ett faktum, det sved. Efter att ha pluggat ytterligare till omtentan i januari, och faktiskt lärt mig saker, var jag en ynka poäng ifrån godkänt. Close but no cigarr och jag fick vänta till augusti på nästa chans. Juli spenderades med att förstå materialet än en gång och utan att plugga jättemycket flöt nu intuitionen för statistiken i mina ådror. Nåja, tentan gick väldigt bra och jag dunkade in en stark 4:a i betyg!

Personlig tentastatistik för kursen TDAB01

Fysik och mekanik – no problem!

Tillbaka till höstterminen 2015! Efter att ha misslyckandet från TDAB01 färskt i huvudet var det dags för fysik, ett ämne som legat i dvala hos mig sedan 2007. Med en kurs som tillät en att inte behöva förstå någonting à la ”slentrianskriva anteckningar hela föreläsningen/lektionen utan eftertanke” och en totalbrist på motivation bådade det inte gott inför tentan. Det blev ett bottenrekord, 0 poäng! Jag förstod mig varken på acceleration eller friktionskraft, så illa var det. Juli spenderade jag med att lära mig grunderna i fysik på högstadie-  och gymnasienivå och insåg att fysik är ganska coolt ändå. Ensam på omtentan lyckades jag klämma till med en stabil 3:a och jag är väldigt tacksam över att slippa släpa på en 1400 sidors fysikbok i fortsättningen.

Kandidatexamen – no problem!

Min första akademiska publikation är gjord! Min kandidatgrupps rapport finns att läsa här och den handlar om hur vi utvecklat en interaktivt webbapp för kryptoanalys, Knekt, och vilka lärdomar vi kunnat dra från projektet. Jag vet att rapporter för de flesta inte är världens mest spännande läsning men låt mig säga detta: Varje gruppmedlem skrev en individuell del i rapporten och min del handlar om parprogrammering och kodgranskning. Om inte det väcker intresset vill jag tillägga att mina grafer är gjorda i ggplot2 och bakom dem ligger mycket slit. Så ge lite kärlek till figur D.3 😉

Checkpoint reached!

Tack vare en lyckosam omtenta-period i augusti har jag alltså avklarat tre kompletta år på Linköpings universitet och därmed fått en kandidatexamen på meritlistan. Detta har förstås flera fördelar, men det bästa är att jag nu kan använda detta som SMS-signal:

Jag vill passa på att tacka mina gruppkamrater från kandidatprojektet som inte bara såg till att vi lyckades väl med projektet utan att vi också hade väldigt kul på vägen! Jag vill även skicka iväg en shoutout till Khan Academy som hjälpte mig mycket med både statistiken och fysiken och som gör ett dunderjobb i att lära ut grundpelarna för att man sedan ska kunna lära sig mer avancerade koncept.

Tack för mig!

STEW 2016

This week I had the pleasure to participate in Swedsoft‘s Software Technology Exchange Workshop (STEW) and it was a blast! Or at least it was very informative, the food was great and the people were friendly. I listened to almost 20 different talks on various topics on software engineering so now I’m filled up with knowledge. 😉

To be able to digest all this knowledge I thought I could write down the most memorable notes I took and give some comments where needed. Of course, these notes, paraphrases and comments will only be a drop in the gravy ocean from STEW. Text in italics are things I thought I heard while unformatted text are my own comments and explanations.

Miscellaneous

It is all software. The electronics and mechanical engineers are lost! – Words from a CTO of a big company. Said with tongue in cheek, but gives a somewhat accurate description of how  some hardware industries are becoming more dependent on software.

Featuritis – 70-80% of features in the product are never used!

Model based [testing/development/systems engineering] – A trend during STEW was to talk about making all things model based.

5G

Sensors everywhere!

25.2 Gbit/s throughput – From an Ericsson experiment performed in Barcelona.

100x higher rate, 1000x higher volume, 5x lower latency, 100x more devices! –
Compared to, I assume, 4G.

Eiffel

The Eiffel framework was originally developed by Ericsson. It is a framework that ”enables technology agnostic enterprise scale continuous integration and delivery.”

Every change in a software project is an event.

Events hold references to other, previous events. This creates a real time directed acyclic graph.

Eiffel is used to document what we did, who did it, why we did it and how we did it.

With Eiffel you may store, analyze and visualize the documentation.

Eiffel is available on GitHub!

Jan Bosch – The hurricane

Mr Bosch spoke about speed, data and ecosystem. Focus was on speed, and he spoke very fast.

Increasing speed trumps any other R&D improvement! Speed beats efficiency every time.

Speed: … the ability to quickly respond to events, such as requests from customers, changes in the priorities of the market or new competitors, is critical to continued success. As the rate at which companies need to be able to respond is accelerating constantly, speed is a key factor. [1]
 

Facebook started in 2004 and gained 50M users in 44 months, Angry birds was released in 2009 and gained 50M users in 1 month!

Continuous delivery is for fegisar! – Not sure what this was about, but it spurred a lot of laughs.

Candy crush analyzes player behavior to increase revenue. – Is the player stuck? Is he/she likely to make a purchase to get unstuck? Use user data to your advantage!

C.I. needs to improve. […] Booking.com can rollback in 8 seconds!

You can’t just ask customers what they want and then try to give that to them. By the time you get it built, they’ll want something new.  – Steve Jobs

Bosch will release a book by Christmas, probably about speed!

[1] Bosch, Jan. ”Tutorial summary for speed, data and ecosystems: The future of software
engineering.” Software Architecture (WICSA), 2016 13th Working IEEE/IFIP Conference on. IEEE, 2016.

Summary

To summarize STEW 2016, I will give a short list of pros and cons. Although I may not be able to put it to words, my overall impression with STEW is overwhelmingly positive.

Pros

  • Great way of bringing industry and academia together.
  • As a student I got to learn things that you simply won’t get to know in school.
  • Very good fika!

Cons

  • I would love to see more ”software companies” and not just the big dragons SAAB and Ericsson. Maybe DICE, Klarna, King, Mojang or Spotify can join in on the fun?
  • It was way too cold for comfort in the lecture hall, Vallfarten, at LiU.

 

Ett öppet brev till Linköpings universitet

När jag nu snart påbörjar mitt fjärde år som student på Linköpings universitet anser jag att jag lärt känna min arbetsplats väl. Jag har insett att det finns utrymme för förbättringar, även fast LiU är världens bästa universitet. I det här inlägget listar jag de tre förbättringsförslag jag anser vara viktigast att prioritera för att LiU ska fortsätta att vara världens bästa universitet.

Förbättringsförslagen

  • Höj temperaturen!
    Det är vanligt förekommande att universitetets lokaler är kallare än vad som är behagligt att studera i. Exempelvis gör ISYtans grupprum verkligen skäl för namnet, det är iskallt. Även SU-salarna och bibliotekets tysta läsesal får mig att frysa knäna av mig och jag känner mig förkyld fast jag är frisk.
    Kanske borde jag börja ta med mig en filt till skolan, men min uppfattning är att detta problem berör fler studenter än jag har filtar. En ökning på ca 1 °C skulle göra susen.
  • Döp studentköket i B-huset, ingång 25 till ”Bamba”!
    Studentköket i B-huset ska självklart ha ett namn som börjar på B och vad passar väl då bättre än ”Bamba”? Det göteborgska ordet för matsal är betydligt lättare att säga än ”Studentköket i b-huset vid ingång 25, (eller var det 23?)” och lite mer göteborgska i livet är aldrig fel.
  • Sätt tassar på fötterna på borden i Key-husets studentkök!
    Under varje lunch som jag har ätit i Key-husets studentkök har någon försökt dra eller skjuta ett bord till rätta vilket alltid resulterar i ett fruktansvärt skri då fötterna på bordet skär över stengolvet. Lösningen heter passande nog ”FIXA” och finns att köpa på IKEA för en billig peng.

Bild på möbeltassar från IKEA.
Tassar är för övrigt ett av mina favoritord vilket bland annat beror på att tassar finns på underbara saker som till exempel kattungar och mumintroll.

Bubblare

Här följer ett par förslag som jag tycker är minst lika viktiga som de ovan men som jag bedömer väldigt osannolika, i de närmaste omöjliga, att kunna genomföras. Jag har dock inget emot att bli motbevisad.

  • Skrota Lisam!
    Jag har då aldrig träffat en student som tycker att Lisam är bra. Från universitetets sida verkar trenden dessvärre vara att använda Lisam mer än någonsin. 😦
  • Släng upp ett JAS Gripen på Campus Valla!
    Att få ett jetplan att pryda universitetsområdet är en historia som sträcker sig bak flera decennier och beskrivs föredömligt i artikeln ”Flygplanet som försvann” i Lithanian #1 2011. Då det i dagsläget verkar råda ett överskott av JAS Gripen hos Svenska flygvapnet tycker jag det passar bra att väcka frågan till liv igen. Krigsmaskin eller inte, ett JAS Gripen är ett makalöst under av ingenjörskonst och skulle inspirera och hänföra många studenter.

JAS Gripen uppställt på campus.
Såhär skulle det kunna se ut, coolt!

Slutord

Syftet med detta öppna brev är att uppmärksamma vad jag tycker är viktigt för Linköpings universitet. Min förhoppning är att det ska engagera studenter och andra med anknytning till universitet och därmed öka chansen att dessa förbättringsförslag går från idé till handling.

Med vänliga hälsningar

Eric Henziger

Att söka till universitet i UK

Ungefär ett år efter det att jag fick idén till att plugga utomlands känner jag att det är läge för att ventilera mina erfarenheter. Att söka utbildningsplats var en för mig en väldigt stor process och därför är det här inlägget skapligt långt, men jag försökte att stycka upp det i mindre delar så gott jag kunde.

TL; DR

Om du pluggar på gymnasiet: Jobba hårt för att få A i alla kurser, även om du inte känner dig motiverad. Tänk om du en dag inser att du vill plugga utomlands men har för dåliga betyg för att komma in? Betygen är viktiga och det är inte alltid som ett högskoleprov kan rädda dig.
Skulle du känna stor ångest inför betygen och betygshetsen får dig att må dåligt, så försök hitta något sätt att lindra stressen. Att prata med någon du har förtroende för om hur du känner och planera din studietid på ett hälsosamt sätt kan vara till stor hjälp.
Kom ihåg att inget betyg är värt utbrändhet och även om du ”bara” får ett B så är du fortfarande en f-ing awesome person, du läser trots allt min blogg och bara det gör dig fantastisk 😉

Pro tip of life: Att få ett referensbrev skrivet till sig själv är en mycket trevlig erfarenhet som alla borde prova på. EGOBOOOOOOOST!

Bästa chokladpralinen: Om du väljer att bara läsa ett stycke, utöver TL; DR, så tror jag att Reflektions-delen är den del med minst tekniska detaljer kring ansökan och handlar mer om hur jag tycker och tänker kring livet, och sånt gillar vi ju alla att läsa.

Disclaimer: Det jag skrivit bör inte tas som absolut sanning för hur antagningsprocessen till ett universitet i UK ser ut idag. Texten är en beskrivning av de viktigaste delarna från min egen ansökan och kan skilja sig från hur verkligheten ser ut.

Att forma en dröm till en plan

Jag minns en eftermiddag förra hösten när jag satt i passagerarsätet i min kompis Andreas bil på väg hem från en klätterresa, jag sa till honom: ”Du, det vore nice att plugga utomlands.” Andreas svarade med ”Jamen, gör det då.” och jag tänkte lite surt att det är väl inget man bara gör sådär hux flux. Men jag spann vidare på idén, googlade och läste på, insåg att jag helst ville till ett engelsktalande land och kom fram till att Storbritannien var nära och bra.

Efter att ha läst på ytterligare insåg jag att Skottland var det bästa landet för mig att söka till då t.ex. universitet i England har en utbildningsavgift på ~9000£ per skolår. Skottland har bara 1820£ per år och har du tur kan hela den avgiften betalas av skotska staten. De skolor i Skottland som hade utbildningar inom computer science, vilket var det ämne jag planerat söka till, verkade dessutom ha ett hyfsat gott rykte.

Ska man plugga på ett universitet i Skottland eller övriga UK så är det via UCAS du ska gå, det är ungefär motsvarigheten till UHR här i Sverige. Hela ansökan görs via UCAS och det kan ibland vara lite klurigt men som tur är har flashback världens bästa diskussionstråd om UCAS, så om det krisar kan man alltid posta en fråga där.

Till slut hade jag en vettig plan. Jag skulle söka till fem (maxantal för en ansökan) utbildningar inom datavetenskap på fem olika skolor i Skottland:

  • University of Aberdeen, Computing Science
  • University of Edinburgh, Informatics
  • University of Glasgow, Computing Science
  • University of St Andrews, Computer Science
  • University of Strathclyde, Computer Science

Av de universiteten jag sökt till ville jag helst komma in på St Andrews som är ett gammalt anrikt universitet. Orten St Andrews har ca 17 000 invånare och ligger utmed Skottlands östkust. Skolan har väldigt gott rykte internationellt och jag tror att den kan uppfattas som lite snobbig. Jag tyckte, och gör så fortfarande, att St Andrews verkade fantastiskt, gemytligt och vackert.

För att ha en chans att komma in på någon av utbildningarna behövdes en väldigt bra ansökan från min sida, och det hela började med betygen.

Betyg

När man har registrerat sig på UCAS kan man stegvis bygga sin ansökan. Ett av de stora blocken är förstås betygen från tidigare utbildningar. De kurser man har läst ska översättas till deras engelska motsvarighet. Vad kurser heter på engelska kan man hitta på Skolverkets hemsida. Just själva betygen jag hade, (G, VG, MVG) behövde man inte översätta till något kryptiskt som ”Pass with distinction” för VG osv utan de var bara till att skriva på svenska. Det spelar ju iofs ingen roll för de som har A-F betyg, skönt med nytt system som funkar internationellt.

Jag fyllde i alla betyg jag fått, dvs från grundskolan, gymnasiet och under min utbildning på MDH. Om du planerar ansöka, var noggrann och hämta hjälp där hjälp kan ges. Till exempel kunde jag få översatta betygsdokument från både högskolan och gymnasiet när jag frågade. Med tanke på att mitt gymnasium var så gott som nerlagt blev jag positivt överraskad.

Personal Statement

Din ansökan ska även innehålla ett personligt brev där du helt enkelt beskriver dig själv, varför du vill plugga på universitetet osv. Det här är en mycket viktigt del av ansökan där du har chansen att skilja dig från mängden av ansökningar. Jag la ner mycket tid på att få mitt PS så bra som möjligt, men beskrev egentligen bara mitt gångna liv och vad jag hade gjort/lärt mig inom data och IT ditintills. Storbritanniens största forum för studenter, The Student Room, har en hjälpservice för PS där man kan ladda upp ett utkast till sitt PS och sedan få tips på förbättringar av någon ”random” snäll person på forumet som tillhör deras hjälpgrupp. Jag skickade in mitt ps och är överlag nöjd med den hjälp jag fick, jag slapp undan några grammatiska missar och fick med några intressanta stycken som jag hade missat annars.Det svåra som jag upplevde med att skriva mitt ps var maxgränsen på 4 000 tecken, det går fort slut.

Det finns massor med tips på forum och även på vissa universitets hemsidor, läs dem, men tänk på att det viktigaste ändå är att du får ett unikt ps.

Reference Letter

Sökande måste ange en referens som skriver ett referensbrev om den sökande. Helt enkelt en person som känner till dig och din akademiska potential som kan ge en ”opartisk” bild av hur du skulle vara som student. Detta är vanligtvis en lärare från gymnasiet. För mig som hade varit från skolan i några år var det ganska svårt att välja referent. Jag kände inte att någon lärare från varken högskolan eller gymnasiet kände mig eller mina kunskaper inom data tillräckligt bra för att ha underlag till ett referensbrev.
Jag bestämde mig till slut för att låta en av mina närmsta kollegor på Westermo få i uppdrag att skriva mitt referensbrev. Kollegan hade i princip haft rollen som mentor åt mig under det dryga året jag jobbat på Westermo och kände till mina kunskaper inom data och programmering bättre än någon annan. Jag hade/har stor respekt för honom och minns att jag var mäkta nervös när jag skulle fråga om han ville vara min referent. En morgon på jobbet tog jag mig mod och frågade ”Tror du att jag skulle klara mig bra på en datavetenskaplig utbildning?” och när jag fick ett ja till svar så ställde jag följdfrågan ”Varför då?!” på ett lite skämtsamt och nästan smått aggressivt sätt.
Hursomhelst åtog sig min kollega att skriva referensbrevet och levererade ett asnice omdöme. Alla bitar var nu på plats för min ansökan och jag kunde skicka iväg den till universiteten via UCAS.

The Aftermath – När ansökan skickats

På Juldagen skickade jag in min ansökan, jag hade visst inte något bättre för mig. Deadline för de flesta utbildningarna i UK är den 15e januari. Nu återstod en lååååång väntan. Jag visste att man egentligen kunde få erbjudanden om plats redan dagar efter att man skickat in ansökan men vanligtvis får man svar någon gång mellan mitten på februari till slutet av mars. Svaren skickas via mail, och en lustig sak med mail är att man kan kolla närsomhelst om det har kommit nya mail. Är man riktigt sugen på att få mail så kan man kolla varje minut eller tom oftare än så.
Nåväl, jag blev aldrig så otålig att jag kollade minutvis, första veckorna efter deadline var det nog tre gånger om dagen ungefär. Men väntan är faktiskt olidlig, jag hade varit mentalt ansträngd av att bara få iväg en så bra ansökan som möjligt, men att sen vänta på svar var nog ännu mer påfrestande då man inte kan göra något mer än att just vänta.

Så till slut, den 12e februari och jag sitter på jobbet, fick jag ett mail om att jag hade fått respons på min ansökan. Under tiden jag loggar in ökar spänningen och förväntan om en plats på ett skotskt universitet. Väl inloggad ser jag att University of Aberdeen har fattat ett beslut: Unsuccessful.

Jag kunde läsa en kort motivering kring skolans beslut:
Due to the high calibre of applications for entry this year, the Academic Admissions Selector comments that, although your application was strong in places, it is below the calibre of those who will receive offers of admission.

Att återgå till att jobba direkt efter detta var en omöjlighet. Jag gick iväg till köket och fyllde på vattenflaskan, kände mig ledsen, kände mig dålig. Jag höll inte måttet, och extra betungande var att Aberdeen var en av de universitet med lägst intagningskrav av de skolor jag sökt. Ett nej från de innebar troligtvis ett nej från de flesta andra skolor jag sökt. Att få ett erbjudande från Edinburgh eller St Andrews verkade hopplöst.

Några dagar senare fick jag ett mail från en anställd på University of Glasgow. De ville se ett betygsdokument från gymnasiet, inskannat och skickat via mail. Här var det verkligen jätteskönt att mitt gamla gymnasium kunde ge mig ett stämplat och underskrivet betygsdokument med översatta kursnamn, så att universitetet tydligt kunde se att det var legitimt.
Att få det här mailet gav även en liten förhoppning om att de kanske vill ge mig ett platserbjudande. Tankarna gick som så att de ville kolla att jag inte ljugit om mina betyg i min ansökan utan varit sanningsenlig. Jag mailade över betygen i ett noga formulerat mail och fick kort därpå svar om att jag snart skulle få besked om jag kommit in. Senare samma dag kom beskedet: Unsuccessful. Ingen motivering till beslutet gavs.

Jag mailade senare till Uni of Glasgow om varför jag inte fått något antagningserbjudande och fick till svar att mina gymnasiebetyg (16.9) inte uppnådde minimikraven på 17.5. Att ha pluggat nätverk och jobbat på Westermo hade jag inget för, kanske, det kändes som att de inte brydde sig om det iaf.

Därefter följde negativa besked från Edinburgh och St Andrews, föga förvånande men ändå lite nedslående. Sist kvar var Strathclyde, ett relativt ungt universitet i Glasgow. När jag tog emot deras besked var det med blandade känslor. Jag hade inte blivit antagen till deras program i computer science, men däremot hade jag fått ett erbjudande om en liknande utbildning inom ”Computing &  Electronic Systems” dvs lite data och lite el. Jag var glad över att ha möjligheten till att plugga i Skottland, men jag ville verkligen plugga compsci på heltid och inte läsa något hopkok av ämnen. Dessutom tror jag inte att jag skulle göra så bra ifrån mig i kurser inom elektronik, särskilt inte när terminologin är på engelska då ämnet är nog så svårt på svenska. Så jag tackade nej till erbjudandet.

Jag hade slängt ut fem metkrokar med det bästa betet jag kunde skaffa och fick inget mer än ett bottennapp. Det var dags att titta på plan B och C.

Bonuschansen – Clearing

I antagningsprocessen, när man har blivit nekad eller själv tackat nej till alla sina val av universitet så har man chansen att söka ytterligare ett universitet i en fas som UCAS kallar för Clearing. Jag hade inget att förlora på att använda mig av Clearing och började kika på ytterligare ett universitet att söka till. Det började bli ont om universitet i Skottland som kunde ge en högkvalitativ utbildning inom compsci men jag bestämde mig för att satsa på University of Dundee.
Innan man lägger in sitt clearing-val är det rekommenderat att man ringer till universitet. (GULP!) Rekommendationer är till för att följas och jag formulerade några frågor kring utbildningen för att verka intresserad och ringde en skotte på universitet en vacker vårdag. Under samtalet studsade jag runt bland några olika personer på universitetet och fick höra den härliga skotska dialekten (ibland förstod jag ingenting av vad de sa, men det lät iaf kul) och fick klartecken för att göra en clearing-ansökan. Efter ungefär 6 veckor hade jag ett erbjudande om en plats på Computing Science-programmet i Dundee.

Och det är det närmaste jag kommit till att plugga i Skottland.

Dundee hade inte samma charm som t.ex. St Andrews utan kändes mer likt en utbildning på MDH i Västerås, ryktesmässigt och kvalitetsmässigt. Med chansen att få börja en ny utbildning i mjukvaruteknik på Linköpings Universitet var det lite för riskfyllt för mig att välja Dundee, och jag tackade än en gång nej.

Reflektion

Om man ser på livet som en väg och varje val i livet är en korsning så kan jag känna att under året som gått kom jag till en korsning med många väldigt spännande stigar. När jag hade alla vägar öppna till bland annat St Andrews och Edinburgh kändes det nästan överväldigande. Men en efter en stängdes de vägarna och jag hamnade på en trygg och säker väg som nu går längs Linköping.

Den huvudsakliga anledningen till att jag inte fick möjligheten till att välja en plats på ett av mina fem toppval i Skottland var mina gymnasiebetyg som var för låga. Jag känner inte direkt ånger för att mina betygsresultat, det var så länge sen jag förtjänade mina betyg och jag var en helt annan person. Tittar man på dem objektivt kan jag tycka att de är väldigt bra. Men om jag  hade vetat då vad jag vet nu, kan jag känna att jag hade haft lite mer motivation till att jaga höga betyg i gymnasiet. Jag tycker att det är lite konstigt hur låg motivationen är för att få höga gymnasiebetyg om man ser till dess värde inom Sverige. Såvida man inte tänkt läsa till läkare behöver man inte ha så höga betyg. Och så finns ju alltid högskoleprovet som kan garantera en utbildningsplats om man skulle ha otillräckliga betyg.

Ibland tänker jag att jag hade trivts bättre på en skotsk skola än här i Sverige. Inte för att det är så dåligt här i Linkan, men av någon anledning känns det väldigt hemtrevligt i regniga UK. Kan det bero på min höga konsumtion av Hem till Gården och River Cottage under mina ungdomsår? Jag tror iaf att jag förr eller senare måste besöka fina Storbritannien och antingen spränga luftslottet jag byggt eller låta mig falla i löv me’t.

Till sist, prata med folk om din ansökan. Jag själv höll det hela ganska hemligt och berättade inte för någon mer än min familj och mina närmsta vänner. Jag kände att jag inte ville berätta för alltför många då risken fanns att jag inte skulle komma in och folk skulle se mitt misslyckande och skratta åt mig, typ. Så går det inte till, folk är empatiska av sig. Berätta om ditt äventyr, det kan nog bara hjälpa dig. Med tanke på att det är något du eventuellt kommer gå och tänka på 90% av din vakna tid så är det nog sunt att dela med sig av dina tankar, oro och förhoppningar.
Tänk också på att det finns en risk att dina närmaste inte direkt gör volter när du berättar för dem att du tänkt fly landet. I själva verket kanske du möter sorg, avund, ilska, ignorans, egoism eller något annat otrevligt. Så ja, berätta för folk, du kanske finner stöd från den mest oväntade personen. Själv minns jag att min kollega Peter på jobbet gav jättebra uppmuntran både när jag väntade på besked från universiteten och när jag hade fått veta att jag inte kommit in, och han var ändå en person som knappt kände mig över huvud taget. Believe in the kindness of strangers!