Framtidens programmeringsundervisning = user first (del 1)
När jag träffade ett 50-tal programmeringslärare häromveckan blev jag påmind om att det är ett ämne med en frustrerande spänning mellan historia och framtid. Jag tror nämligen inte att nya programmerare måste göra samma resa som jag eller branschen i stort gjort. Jag tror inte att man måste börja procedurellt och hårdvarunära. Jag tror inte ens på objects first. Jag tror man kan börja funktionellt och dynamiskt, men det är inte min huvudpoäng. Den allra första boken man borde läsa när man lär sig programmering skall varken behandla syntax eller problemlösning, utan användarnytta. Börja gärna med boken Jävla Skitsystem. Gå sedan in på programmeringen som sådan. Huvudmålet med programmering är inte att lösa matematiska problem, utan användarnas problem.
Ett inspirerande möte
Innan jag återkommer till frågeställningen om hur och vad som bör ingå i undervisningen i programmering, låt mig börja med att tacka Lennart Rolandsson som arrangerade träffen och alla kollegor som jag verkligen uppskattade att träffa. Att jag dessutom fick höra mycket beröm för de ämnes- och kursplaner jag skrivit gjorde ju knappast saken sämre. Är du gymnasielärare i programmering, så gör det till en prioritet att komma till nästa träff! Detta var den fjärde träffen i denna seminarieserie och intresset växer hela tiden. Efter mitt forsta deltagande förstår jag varför.
Lennart har skrivit ihop en sammanfattning av det som sades av oss föreläsare, så jag tänker inte göra om det. Mitt eget föredrag om utvecklingen i branschen finns på Slideshare och den del som behandlade det fjärde året finns på Prezi.
I stället skall jag utveckla mina åsikter i (troligen) tre blogginlägg:
- Användarens behov kommer först och inte matematiken.
- Webben är mer än ett gränssnitt.
- Det finns fler paradigm än strukturerad och objektorienterad programmering.
I dessa inlägg kommer jag beskriva mitt tänkande ifrån tre aspekter:
- Några tankar om min grundsyn på ämnet och branschens utveckling, delvis hämtade från mitt föredrag.
- Hur det påverkat mina vägval när jag jobbat med fjärde året på teknikprogrammet.
- Vad slags stöd kollegor kan ge mig för de ideer jag har om detta.
Och jag kommer tänka mig en slags antagonist
som omhuldar följande åsikter:
Riktig
programmering är tillämpad matematik, algoritmer och annat vi lärt oss av Donald Knuth.Riktig
programmering är baserad på manuellt kompilerade språk med statiska typsystem.Riktig
programmering är strukturerad och/eller objektorienterad.
Enligt Lennarts sammanfattning från träffen, så skall en av lärarna på BTH uttryckt följande åsikt om gymnasiets programmeringsundervisning:
… skit i grafik och annat, se till att de kan programmera de mest grundläggande sakerna, helst i mindre i flera olika språk, men att de verkligen behärskar grunderna.
Om detta har jag en enda sak att säga:
Not on my watch!
Jag gillar såväl Donald Knuth som matematik, men detta synsättet är för snävt. Det kommer att vara dåligt för rekryteringen av elever till programmeringen och det kommer inte gagna industrin.
Programmering som en del av fjärde året på Teknikprogrammet
När jag tänkte på det fjärde året så var ett ord viktigare än alla andra: Anställningsbarhet. En klassisk programmerare med goda kunskaper om datavetenskap och algorimer behöver normalt studera ämnet i flera år. Det är högskolans sak att få fram dessa. Jag tror inte att gymnasiet skall utgöra en lättversion av detta. Branschen var mycket tydlig att den inte såg möjlighet att anställa studenter med en sådan utbildning. Från början ville man därför inte ha någon annan inriktning på fjärde året än webbutveckling.
Delvis tror jag detta beror på att få fattat hur komplex modern webbutveckling kan vara. Testa dig själv med dessa frågor:
- Om du vill åstadkomma asynkron nedladdning av JavaScript, men ordningen i vilken de laddas och körs är viktig, hur gör du det?
- Vad har TCP:s slowstart algoritm för påverkan på frågan om man skall använda progressive enhancement eller inte och vilka parametrar skall jag testa för att säkerställa bäst resultat utifrån den frågeställningen?)
Annorlunda uttryckt: En webbutvecklare måste kunna programmera och en programmerare måste kunna webbutveckla.
Och såväl utvecklongsverktyg som projektmetodik sammanfaller till stora delar mellan dessa två discipliner.
I slutändan kom profilen att heta mjukvarudesign
och den rymmer såväl webb som vissa moment ren
programmering.
Att lösa rätt problem
Traditionellt har kopplingen mellan programmering och tekniska beräkningar varit stark.
Att bygga goda användarupplevelser är inte
computer science
och inte lika fint
. Eller så kan man lära sig det senare
.
Problemet med detta tänkande är att det i längden leder till dåliga produkter.
Den invändning som främst kommer fram är att man missar grunderna
om man börjar för tidigt med grafiska
gränssnitt och försök att göra snygga program. Min motfråga är varför det skall anses som icke-grundläggande
att skapa just det som användare efterfrågar?
To the user, the interface is the product.
Det köps idag in s.k. affärssystem
för miljardbelopp i Sverige, som inte används eller när de används så driver
man användarna till vansinne. Det är system skapade av programmerare som låter användarna anpassa sina rutiner till
datan och inte tvärtom. Det är system som är så fula i estetisk bemärkelse att de kan anses vara ett
arbetsmiljöproblem. Det är system som användarna undviker och som i extremfallet inte alls används. I stället
används vanlig mejl och vanliga officeproduktertil sådant som de egentligen borde vara sämre på. Men på grund av sin
generella goda användbarhet så används de i stället.
Nu finns det ett problem med frågan om gränssnitt, nämligen att den lätt reduceras till färdighet att använda ett
visst verktyg. Jag är allergisk mot kurser i Dreamweaver
. Likaså mot okunniga ASP-utvecklare som använder
verktygen i Visual Studio utan att ha den blekaste aning om att de producerar gräslig och dåligt fungerande
skräpkod, fylld av monstrositeter som
viewstates
och annan sörja.
Hur man bygger en modal dialogruta i just ditt favoritverktyg är ointressant. Frågan är när du skall
använda modala dialoger, hur du utformar dem så att användaren inte missar dem, etc. (Hur ofta har man inte varit med
om att dialogrutan ligger dold bakom ett fönster…)
För att lyfta frågan om gränssnitt, så har det blivit ett eget ämne och grundkursen i gränssnittsdesign är dessutom ett förkunskapskrav för fjärde året. Notera att ämnet fokuserar såväl interaktionsdesign som visuell design. När eleven sedan fortsätter med att konkret programmera, så är det problem som han/hon har att lösa hur just en optimerad användarupplevelse åstadkoms.
Först kommer inte flödesschema och UML-diagram. Först kommer en storyboard!
Exemplet WordPress
Jag vet inte hur många gånger jag hört erfarna programmerare klaga på Wordpress. Och vad jag förstått, så görs det med rätta. Ur programmeringsteknisk synvinkel så lämnar nämligen produkten mycket att önska. Under dess första tid uppvisade den alla tänkbara problem: tight coupling, bristande säkerhet, ineffektiva algoritmer, bristande arkitektur, etc. Trots detta blev produkten en succé och frågan är varför?
Därför att produkten, när den kom, bättre än någon annan tillgodosåg ett konkret behov. Den kunde installeras utan
att man behövde vara alltför teknisk och den gav avändarna just de funktioner man önskade. Under skalet
var det skrot men likväl lyckades produkten då det som efterfrågades var ett bra skal
!
Användarens upplevelse är grunden för allt
Det är rimligt att just tekniska högskolor skall utbilda programmerare som är djup förankrade i datavetenskap och matematiskt tänkande, men det jag värjer mig mot är att all programmering skall passas in i den mallen.
Jag säger det igen: Att utveckla fungerande gränssnitt har sina egna utmaningar. Jämför en applikation som löser en uppgift på tre (3) sekunder, men under tiden är programmet fryst. Med touch interface så kanske inte ensett timglas visas, utan användaren hinner peka på skärmen flera gånger. Sedan när programmet reagerar så händer det en serie av oönskade händelser. I värsta fall hinner användaren inte ens se det hett efterlängtade resultatet, innan skärmbilden försvinner.
Ett annat program har kanske mindre optimerade algoritmer och uppgiften tar fem (5) sekunder att lösa, men under tiden
fortsätter programmet att svara. Sämre datavetenskap
, men bättre produkt!
Responsiveness is more important than speed.
Alltså, jag köper att programmering är problemlösning, men vad för slags problem skall vi lösa? Inte bara det slags problem som återfinns i programmeringsolympiaden. Jag tror vi gör oss en otjänst genom att stirra oss blinda på den mycket snäva definitionen av problem.
Jag är helt frankt mer intresserad av att se mina elever skapa användbara mobila appar, webbplatser och nyttoprogram, än att se dem ta medaljer i en artificiell tävling.
Nu har jag skrivit ett skarp blogginlägg. Jag tror diskussionen mår bra av skärpa. Men missta inte den skärpan för antipati. Jag uppskattar mötet med kollegor som har avvikande åsikt. Jag välkomnar sådana på Delas forum för programmering.
Publicerad: 2011-04-19 13:38
Uppdaterad: 2011-04-19 13:38