Av: Svend Andreas Horgen, høgskolelektor og faglærer i blang annet Visual Basic-programmering

I disse dager er det eksamener ved landet høgskoler og universiteter. HiST er intet unntak, og selv om vi i noen fag har tatt i bruk moderne eksamensformer (for eksempel nettbasert/bruk egen datamaskin) så er flertallet fortsatt i form av tradisjonell skriftlig eksamen.

Her er en del tips jeg normalt har brukt å sende ut som e-post til de som skal ta eksamen i faget «LN116D Programmering i Visual Basic .NET». I morgen (14. desember 2010) skal ca 90 campusstudenter avlegge skriftlig eksamen i faget. Innlegget kan sikkert også overføres til eksamen i andre fag, derfor legges det her på itfag-bloggen.

Kjære student. Takk for et interessant semester. Nå er det eksamen og du gledegruer deg kanskje. Her er noen tips fra meg til deg. Det er ikke sikkert at alle tipsene passer med din stil, men jeg tar opp ting som jeg vet fra egen erfaring er lurt og som jeg har observert gjennom flere år at folk gjør feil/rett på.

Leksjoner, øvinger og bok kan du få ta med på eksamensdagen. Alle hjelpemidler er tillatte på eksamen. Hvorfor det? Fordi det oppgaven spør etter, er forståelsen for programmering. Du kan IKKE slå opp i lærestoffet og finne svar. Du får oppgaver som du ikke har sett før. Du må gjerne slå opp i lærestoff for å dobbeltsjekke hvordan for eksempel en for-løkke skrives syntaksmessig, men mitt tips er å legge alt av hjelpemidler på gulvet i eksamenslokalet og gjerne knyte en hyssing rundt. Klipp over hyssingen bare hvis du absolutt må. Hvorfor? Fordi du kaster bort mye tid med en gang du begynner å slå opp, og det er ikke sikkert du finner det du leter etter heller. Du mister kanskje tråden på hva oppgaven spør om. Det er bedre å tenke klart og prøve å formulere med egne ord.

Tro meg: Jeg (og øvrige sensorer) ser med en gang når jeg retter at koden er halvveis klippet ut fra et eksempel i lærestoffet. Det er alltid noen som prøver å løse oppgavene ved å finne noe som likner i leksjonene. Jeg avslører det ikke fordi jeg har glede av å avsløre det, men det synes lett fordi det gjerne er for å si det rett ut «malplassert» og gir en ulogisk sammenheng med resten. Det er da mye bedre å prøve selv og gjøre det halvveis. Da viser du evne til et helhjertet forsøk, og kan faktisk få mye uttelling for å ha tenkt i riktige baner. Du har selvsagt lov å bli inspirert av ting som du måtte ha gjort før eller sett i lærestoffet, men poenget er at dersom du først klarer å bli inspirert av slikt på en riktig og god måte, så klarer du også å skrive alt selv i en eksamenssituasjon, og trenger ikke å slå opp 🙂

Du skal til nå ha lært deg grunnleggende prinsipper i programmering (variabler, kontrollstrukturer, funksjoner, matriser, eksterne lagringsmedier, …). Du har gjort mange praktiske øvinger og lært å anvende i praksis. Du har brukt Visual Studio, men hvis jeg nå spør deg: Hvordan ville du lage et program som leser inn ti tall som brukeren oppgir, og summerer disse og viser summen til brukeren? Må du da ha Visual Studio for å løse dette? Eksamen er skriftlig. Med penn og papir. Du har ikke datamaskinen foran deg, du har ikke Visual Studio som kan automatisk fylle ut det du starter på å skrive inn. Det er derfor lurt å løse gamle eksamensoppgaver, fordi det ER ANDERLEDES å kode på ark med penn, sammenliknet med å kode i Visual Studio. Det er likevel ganske likt, fordi det er du som tenker logisk og som formulerer det som må til for å løse problemet. Tro meg: Selv om jeg alltid har datamaskinen noen (centi)meter unna meg til vanlig, så er det ofte at jeg begynner en programmeringsjobb med papir og blyant.

Et annet triks er nettopp å være problemfokusert. Hva er problemet i denne oppgaven? Det må du spørre deg selv om. Hva er det du skal løse? Forstå det – og du er halvveis. Bruk derfor tid. Jeg leste alltid alle eksamensoppgaver 2 ganger når jeg selv studerte (noen år siden). Faktisk begynte jeg med å lese alle oppgavene før jeg tok opp pennen. Ikke grundig, men jeg brukte ca 5 minutter på å skumme halvfort gjennom eksamenssettet. Da så jeg sånn ca hva dette dreide seg om. Jeg vil si det er like lurt anvendt tid som når idrettsutøvere varmer opp før de skal yte.

Foto: Geir Maribu

Jeg brukte også kladdearket til å skrive stikkord, ting som evt. kom umiddelbart til meg som jeg måtte huske på. Det å ha en liste med «gjøremål» og en liste med «kanskje» er ingen dum idé. Det er også lurt å streke under viktige ord med gul tusj. En annen strategi er å skrive et kort resymé av oppgaven med egne ord på kladdearket for deg selv. Hvorfor bruke tid på det? Fordi da sikrer du deg at du forstår oppgaven, og du bruker mindre tid på å løse den. Når du er midt oppi å skrive løsningen din ned, kan du bare se kort på ditt lille resymé av oppgaven, og du får gjennoppfrisket hva du egentlig skulle løse, evt. husker du å få med deg alle delene som du må løse.

Kladd er bra, men noen har dårlige vaner fra videregående skole. Der var det nemlig (i hvertfall i min tid) lagt opp til at en skulle kunne kladde alt og så «føre inn». Mange skrev da av det de først hadde kladdet, med noen få endringer. Dette kan være ok, men hvorfor ikke heller bare føre rett inn? Ha kladd, men bruk kladden kreativt. Bruk kladden til stikkord og figurer, skisser. Tegn gjerne en dataflyt. Skal du bruke løkke, så tegn en pil som går i sirkel og skriv hva som repeteres. Skal du programmere noe der du må kalle en funksjon, så tegn en boks og bruk piler. FØR RETT INN med kulepenn. Blir det feil, så la DET være kladden din og start på nytt.

Et annet konkret tips er å starte hver nye oppgave på et nytt ark. Fordi: Hvis du skriver smått og får alt inn på noen få ark, så blir ting fort feil. Bruk mange ark. I stedet for å måtte skrive alt på nytt, så må du skrive bare det aktuelle arket på nytt. Det er forresten lov å streke ut ting. Hvis du har en kodesnutt som du ser blir «helt feil», så bare kryss over eller strek ut. Sensorene har ikke så god tid at de leser ting som er streket ut når de retter, for å si det sånn. Streker du ut noe, så hopper sensorene til det neste som ikke er streket ut.

MEN: Ikke rot. Noen roter og skrabler noe helt utrolig. Det du skriver skal være lesbart. Blir det helt feil, så ta deg to-tre minutter ekstra til å skrive et nytt ark. Det tar ikke mye tid å skrive et ark med kode når du vet hva som skal stå der 🙂

Skriv tydelig. Noen bruker store bokstaver. Helst unngå det. Det er vanskelig å lese (fordi mennesker er vant til å lese små bokstaver). Skriv pent og tydelig.

Kommentarer kan du ta med, men dersom du skal skrive et avsnitt for å forklare noe, så trenger du ikke følge innrykkene du tidligere har brukt, og du trenger heller IKKE å bruke kommentartegnet ‘ for å angi at dette er en kommentar. Vi ser hva som er kode og hva som er kommentarer. Noen bruker for mye innrykk og får da bare 20% igjen av arket helt ute til høyre til å skrive på!!! Det er slik du ser det i Visual Studio, men det er ikke gunstig på ark. Overbruk av innrykk ødelegger for deg selv, og lesbarheten blir grusom for sensor. Du trenger heller ikke ha med Private Sub Button1_Click … og så videre i koden din. Visual Studio tar seg av alt av autogenerert kode. Det vi er interessert i er din løsningsstrategi, ikke din evne til å produsere det samme som Visual Studio gjør. Gå derfor rett på det kreative, altså det som er din løsning og ditt bidrag for å løse problemet som oppgaven spør om.

Noen ganger vil du kanskje stå fast. Prøv da så godt du kan. Klarer du ikke å formulere kode, så skriv DETALJERT med egne ord (eller helst pseudokode) hvordan du ville løst det. Da kan du få noe uttelling i stedet for ingenting.

Gitt at eksamenstiden er 4 timer. Hvis det står at en oppgave teller 30 % så betyr det at du bør bruke ca 1 time, kanskje litt mer, men IKKE 2 timer. Du må disponere tiden godt. Ikke ta med «egge-timeren» fra kjøkkenet, fordi tikkingen irriterer de andre i salen, men ha gjerne en fysisk klokke ved siden av deg. Du får ikke bruke mobilen, så tenk analogt. Jeg har sett folk med søte vekkerklokker på eksamen 🙂 Et triks er også å skrive klokkeslettet ved siden av hver oppgavetittel i det du starter på en oppgave. Da vet du hvor lang tid du har brukt.

Praktiske ting? Eksamensvaktene er koselige mennesker. Noen studenter blir veldig nervøse før eksamen, og kanskje underveis. Da sier jeg følgende som råd: Ta med en eksamensvakt ut på tur. De liker å gå litt rundt, og du har lov til å ta en pause eller to om du trenger «luft» og litt fri fra variabler, datatyper og løkker. De gangene jeg var nervøs når jeg studerte, hjalp det å snakke litt med eksamensvaktene om hvordan det var å leve under krigen, hva de synes om noe dagsaktuelt, og andre ting. Noen spør hva du har eksamen i, og det kan jo være både mental rekreasjon og forløsende å prøve å forklare en pensjonist hva en «if-setning» er. Men: Ikke bestikk eksamensvaktene med sjokolade.

En vanlig feil er for øvrig å spise for mye søtt, men det vet dere sikkert fra andre eksamener. Brød og melk til frokost er bedre enn New Energy og Coca Cola, men det er faktisk lurt å ha en sjokolade i bakhånd i fall du trenger energi. 4 timer programmeringseksamen er en mentalt tung øvelse. Jeg ødela mange eksamener ved å sovne kl 03 dagen før eksamen, og lese til siste sekund. Ikke lurt. Aldri lurt. Intet å tjene på slike desperate tiltak er min erfaring.

Husk til slutt at akkurat DU er flink! Du har kommet helt til eksamensdatoen, og du har lært mye i løpet av semesteret. Kanskje lærer du noe under eksamen? Det hadde jo vært gøy, ikke sant? Livet er læring, og det er morsomt å lære. Det er vel derfor du studerer, ikke sant? 😉

Kom gjerne i spørremodus, for da reflekterer du og det er det du trenger for å gjøre det bra. Prøv å unng å bli frustrert. Er det noe som frustrerer, så tenk positivt, og IKKE heng deg opp i detaljer. Hvis vi har gjort noe feil i eksamenssettet, for eksempel skrevet ting som er selvmotsigende, så ikke bli irritert, men si fra til faglærer etterpå. Det kan være det var noe som var så uklart eller misvisende at faglærer/sensor vil ta hensyn til det under retting. Da blir det også likt for alle, som seg hør og bør.

Puh!

Har du noen andre tips?

Oppdatert mai 2011: Her er et nytt innlegg om eksamen, skrevet mai 2011

Dette innlegget har 10 kommentarer. Gjerne bidra :-)

Skrevet av: Svend Andreas Horgen (totalt 133 blogginnlegg)

10 comments

<< Bloggkavalkade 2010

Litt om virtualisering i undervisningen >>