Frisammensatt bachelor i Realfag og Teknologi ved IFI

Hvordan IFI-emnene bygger på hverandre, og hva som ofte oppleves vanskeligst

#ifi#studier#algdat#emner

Merknad: Denne artikkelen er KI-generert for å teste siden. Endelig innhold kommer senere.

En frisammensatt bachelor gir mye frihet, men også mye ansvar for at graden faktisk henger sammen til slutt. Det er lett å velge emner som virker interessante hver for seg. Det vanskeligere er å få riktig progresjon, passe på forkunnskapskrav og unngå et semester der alle fagene har prosjektlevering samme uke.

Dette er ikke en fasit på hvilke emner som er «lette» eller «vanskelige». Bakgrunn betyr mye. Den som har programmert i flere år kan gli gjennom IN1000, men møte veggen i matematikk. En annen kan forstå bevisene med en gang og bruke tre timer på en liten Java-feil. Beskrivelsene under handler derfor mer om hva slags vanskelighet emnene har.

Kortversjonen

EmneHvordan det ofte opplevesDet vanskeligste
IN1000En rolig start som plutselig krever at du tenker som en programmererÅ oversette en oppgave til små, presise steg
IN1010Mer kode, flere filer og langt flere ting som påvirker hverandreÅ fordele ansvar mellom objekter uten å lage spaghetti
IN1020Bredt, teknisk og mer teoritungt enn mange forventerÅ skifte mellom binært nivå, maskinvare og større systemer
IN2010 / AlgDatFørst ryddig, deretter ganske brutalt hvis grunnlaget ikke sitterÅ velge riktig algoritme og begrunne kjøretid og korrekthet
IN2000Mindre skoleoppgave, mer faktisk utviklingsprosjektTeamarbeid, avgrensning og integrasjon rett før levering

IN1000: den første mentale omstillingen

IN1000 er introduksjonen til objektorientert programmering. Syntaksen er sjelden det største problemet. Det vanskelige er å gå fra «jeg vet hva svaret skal være» til en oppskrift datamaskinen kan følge uten å gjette hva du mente.

Løkker, funksjoner og klasser kan se enkle ut hver for seg. Når de skal brukes sammen, blir det tydelig om man faktisk forstår kontrollflyten. En klassisk opplevelse er at programmet virker på eksempelet i oppgaveteksten, men feiler på en tom liste, et negativt tall eller et navn med mellomrom.

Det som ofte er vanskeligst: debugging. Ikke fordi feilmeldingen alltid er komplisert, men fordi man ennå ikke vet hvor man bør lete. Den viktigste vanen fra dette emnet er å teste små deler av programmet i stedet for å endre fem ting og håpe.

IN1010: når koden blir et system

I IN1010 er ikke én klasse lenger hele programmet. Objekter samarbeider, datastrukturer vokser og en endring ett sted kan ødelegge noe et helt annet sted. Faget oppleves derfor ofte som et større hopp enn emnenavnet antyder.

Det er mulig å få en løsning som «virker» ved å legge all logikk i én stor metode. Problemet kommer når løsningen skal utvides, testes eller forstås noen dager senere. Da blir innkapsling, grensesnitt og tydelig ansvarsfordeling mer enn ord fra forelesningen.

Det som ofte er vanskeligst: å se forskjellen på kode som kjører og kode som er godt strukturert. Her begynner designvalg å koste noe.

IN1020: mange abstraksjonsnivåer på én gang

IN1020 introduserer datateknologi bredere enn bare programmering. Det kan være forfriskende etter mye kode, men også overraskende krevende fordi temaene skifter fort. Én uke handler om hvordan data representeres, en annen om hvordan maskindeler og systemlag samarbeider.

Faget belønner ikke bare pugging. Det hjelper å kunne følge én operasjon gjennom flere lag: fra det brukeren ber om, via programmet og operativsystemet, ned til hvordan data faktisk lagres og behandles.

Det som ofte er vanskeligst: å holde en rød tråd mellom detaljene. Hver del kan virke forståelig alene, mens eksamensoppgaven krever at flere lag kobles sammen.

IN2010 / AlgDat: faget som avslører hullene

Algoritmer og datastrukturer har rykte på seg for å være et av de vanskeligere bacheloremnene. Det skyldes ikke nødvendigvis at hver algoritme er ekstremt komplisert. Utfordringen er at man må gjøre flere ting samtidig:

  1. Forstå problemet presist.
  2. Velge en datastruktur som passer.
  3. Finne eller lage en algoritme.
  4. Argumentere for at den er korrekt.
  5. Analysere hvor mye tid og minne den bruker.
  6. Implementere den uten å ødelegge poenget underveis.
problem -> modell -> datastruktur -> algoritme -> korrekthet -> kompleksitet -> kode

Det er fullt mulig å skrive kode som gir riktig svar på små testdata, men som bruker så lang tid at den i praksis ikke løser problemet. Det er her kjøretidsanalyse går fra å være matematisk pynt til å bli nyttig.

Trær og grafer er ofte punktet der mange mister oversikten. En liste har en tydelig begynnelse og slutt. En graf kan ha sykler, flere mulige veier og noder som aldri blir besøkt hvis traverseringen er feil. Rekursjon gjør det ikke nødvendigvis lettere før man har tegnet kallstakken noen ganger.

Det som ofte er vanskeligst: oppgavene ligner ikke alltid på eksemplene fra forelesningen. Man må kjenne igjen strukturen bak historien i oppgaveteksten. «Finn billigste rute», «planlegg avhengigheter» og «oppdag en sykel» kan alle være grafproblemer med forskjellige krav.

Det som hjelper mest er ikke å lese løsningen ti ganger. Tegn datastrukturen, kjør algoritmen for hånd på et lite eksempel og skriv ned invarianten: Hva skal alltid være sant etter hvert steg?

IN2000: den sosiale vanskelighetsgraden

IN2000 handler om software engineering med prosjektarbeid. Her er ikke den vanskeligste delen nødvendigvis en algoritme. Det er å bygge noe sammen med andre mens krav, kode og tidsplan endrer seg.

Et team kan bestå av flinke utviklere og fortsatt få problemer dersom ingen avklarer ansvar, integrerer ofte eller sier fra når en oppgave står fast. Små Git-konflikter er enkle. Fire uker med parallelle løsninger på samme problem er ikke det.

Det som ofte er vanskeligst: avgrensning. Det er fristende å bygge fem kule funksjoner. Et mindre produkt som er testet og henger sammen er som regel bedre enn fem halvferdige funksjoner som møtes kvelden før levering.

Hva virker vanskeligst?

Hvis «vanskelig» betyr størst teoretisk terskel, er AlgDat en klar kandidat. Faget krever både programmering, abstraksjon og analyse, og det er vanskelig å skjule et svakt grunnlag.

Hvis «vanskelig» betyr mest uforutsigbar arbeidsmengde, kan IN2000 være verre. Du kontrollerer ikke hele prosjektet alene. Hvis «vanskelig» betyr størst mental omstilling, kan IN1000 fortsatt vinne for den som aldri har programmert før.

Min mest nyttige rangering er derfor ikke fra lett til vanskelig, men etter type:

  • IN1000: lære å tenke presist.
  • IN1010: lære å strukturere større kode.
  • IN1020: forstå lagene under koden.
  • IN2010: velge og analysere løsninger.
  • IN2000: få teknikk, mennesker og tid til å fungere sammen.

Slik ville jeg satt sammen progresjonen

Begynn med programmeringsgrunnlaget før AlgDat. Ta gjerne et teorifag parallelt med et praktisk fag, men vær forsiktig med å samle flere store prosjektfag i samme semester. Les emnesidene og forkunnskapskravene på nytt før hvert opptak; innhold og undervisningsopplegg kan endres.

Friheten i en frisammensatt grad er mest verdifull når emnene bygger på hverandre. Målet er ikke å finne den enkleste veien til 180 studiepoeng, men å slippe å oppdage midt i AlgDat at man hoppet over det faget som skulle gjøre trær, rekursjon og kompleksitet mindre mystisk.