Tre hemmelige opskrifter

opskrift

Jeg vil bryde mange års tavshed og her røbe nogle hemmelige opskrifter, jeg har haft megen glæde af. Især den første har jeg brugt igen og igen og igen. Den anden har jeg brugt af og til, og jeg ved at mange af mine gamle studiekammerater og kolleger er afhængige af den. Den sidste brugte jeg ofte i min studietid, og den er stadig populær blandt studerende.

Sådan beviser du en matematisk sætning:

  1. Definér de begreber, der indgår i sætningen, og en samling betingelser, der skal gælde for at sætningen kan være sand.
  2. Formulér den sætning du gerne vil have.
  3. Prøv at bevise sætningen.
  4. Hvis definitionerne og antagelserne gør det muligt at bevise sætningen, er du færdig. Ellers gå tilbage til 1 og revidér definitioner og antagelser.

Sådan konstruerer du et program, der skal løse et problem:

  1. Prøv at formulere problemet.
  2. Find ud af (ved at søge på nettet) om der findes eksisterende kode, der helt eller delvist løser samme opgave eller en tilsvarende.
  3. Hent de nødvendige stumper kode fra nettet.
  4. Prøv stumperne af og se om de gør det, du tror de gør.
  5. Sæt stumperne sammen ved at skrive kode selv.
  6. Test det program, du nu har.
  7. Se efter om andre allerede har lavet en bedre løsning (måske er der et bibliotek derude et sted).
  8. Ellers så restrukturér og ryd op i din programkode. Gå tilbage til 5 indtil programmet løser problemet.

Sådan laver du et problemorienteret projekt:

  1. Læs litteratur om problemstillingen.
  2. Prøv at skrive en problemformulering og et bud på en løsningsmetode og krav til en løsning.
  3. Prøv så at løse problemet.
  4. Hvis problemet er blevet løst, er alt godt. Ellers gå tilbage til 2 indtil problemet er løst eller deadline nærmer sig.
  5. Hvis deadline indtraf inden problemet blev løst, så skriv en god konklusion, der forklarer hvad du rent faktisk lavede og i hvilket omfang det bragte dig tættere på at løse problemet.

Én ting har disse opskrifter til fælles: Mange bruger dem, men ingen bliver undervist i dem. Studerende lærer pæne, rationelle strategier og bruger dem på små, konstruerede eksempler.

Den amerikanske datalog Philip Guo kender godt ovenstående opskrift på programudvikling og den skriver han om i Communications of the ACM:

I do not have a good name for this style of programming, so I would appreciate any suggestions. The closest is Opportunistic Programming, a term my colleagues and I used in our CHI 2009 paper where we studied the information foraging habits of web programmers. Also, I coined the term Research Programming in my Ph.D. dissertation, but the aforementioned six-step process is widespread outside of research labs as well. (A reader suggested the term bricolage.) Students currently pick up these hands-on programming skills not in formal CS courses, but rather through research projects, summer internships, and hobby hacking.

Jeg vil nu ikke omtale de hemmelige opskrifter så negativt. Det er ikke forbudt at efterrationalisere – tværtimod. Man skal efterrationalisere for at opnå ny indsigt. Den rationelle fremgangsmåde er en måde at genskabe (eller måske skabe) en velbegrundet tankeproces på, som gør det muligt for andre at forstå det, man har skabt. Det er ikke “snyd” omsider at kunne forklare strukturen bag det, man har fundet frem til.

Den rationelle vej mod målet, som vi underviser andre i, og som vi selv er blevet undervist i, er ikke “forkert” eller “dum”, for den giver os et struktureret sprog at tale i, men den er kun den ene side af mønten.

I videnskabsteori taler man om context of discovery og om context of justification. Den første kontekst er den, hvori man gør opdagelsen, den anden er den kontekst, man “begrunder” opdagelsen i – typisk ved brug af en struktureret teori. Jeg ved ikke, hvornår eller hvordan man bedst kan undervise i at efterrationalisere ordentligt. Jeg tror ikke det skal ske helt tidligt, for så lærer man aldrig idealet om den rationelle vej at kende og hvordan det kan bruges til at få struktur på. Men det skal heller ikke ske så sent, at man ender med at tro, at det er “snyd” at efterrationalisere.