« Hem

Felsökning med hjälp av en badanka?

Ärligt talat, jag hade aldrig hört talas om uttrycket ”rubber duck debugging” innan jag läste det här inlägget på bloggen Coding Horror för några veckor sedan. Och jag måste säga att jag är ganska frälst i konceptet!

index

Bildkälla

Så vad är då ”rubber duck debugging”?

Idén kommer från boken The pragmatic programmer, och grundtanken är att när du har problem med din kod, så räcker det inte med att sitta och stirra på skärmen och tänka på problemet; det måste formuleras högt. Processen med ankan brukar beskrivas ungefär såhär:

  1. Köp, sno eller låna en badanka och placera ankan bredvid din skärm.
  2. Berätta för ankan om grundproblemet du försöker lösa och vad du vill uppnå.
  3. Gå sedan igenom din kod och berätta för ankan hur du försökt lösa problemet, och förklara rad för rad vad koden gör.
  4. Inse något av följande:
    1. Du hittar felet i koden, eller
    2. Felet ligger inte alls där du trodde, eller
    3. Din kod försöker inte alls lösa det problem du tänkt att den ska göra
  5. Tacka ankan för hjälpen och ändra koden.

Jag tycker det här är en klockren idé, och efter jag hörde talas om metoden har jag tänkt tillbaks på tillfällen då jag skulle ha behövt en badanka till hjälp!

Bildkälla

Jag tyckte det här fenomenet är extremt tydligt under skoltiden: när vi hade handledning räckte det ibland med att förklara för handledaren vad jag behövde hjälp med, för att komma på lösningen själv. Andra gånger var situationen omvänd: jag var handledare och satt bredvid en uppgiven student som suckar: ”Ingenting funkar! Jag blir tokig!”. Nej, då blir det inte lätt för mig att hjälpa dig. Förklara istället för mig vad du försöker göra och exakt vad som inte fungerar.

keep-calm-and-start-debugging-8

Det har även hänt mig nu när jag jobbar, och jag minns för några veckor sedan när jag behövde hjälp att förstå en grej, så jag ringde till en person som hade koll på detta, men under samtalet fick jag motfrågan: ”vad är det exakt du vill veta?”. Och jag insåg att fasen, jag visste inte riktigt vad jag ville veta! I mitt huvud trodde jag att jag hade formulerat mig klart och tydligt, men egentligen var själva grunden för frågan otydlig för mig. Då hade jag behövt en anka att prata med först!

Tanken slog mig igen igår: jag skulle skicka ut en fil till en mapp genom en integration, och det hände absolut ingenting. En superenkel grej, men ändå funkade den inte. Jag stirrade på skärmen och försökte på flera olika sätt, tänkte att vafasen, det här ska inte vara svårt! Till slut ringde jag en kollega och bad om hjälp, och när jag försökte förklara problemet för honom så förstod inte han heller vad problemet var. Han gav lite tips att testa, men när jag lade på luren så slog det uppenbara mig: felet ligger inte i den här enkla grejen. Det är något som går fel innan, vilket gör att exekveringen aldrig når den här punkten och försöker skicka ut filen – det finns ingen fil att skicka ut.

Nu ska jag forska i en incident som precis kom in, därefter drar vi till Stockholm för sommarfest med hela bolaget. Önskar er alla en trevlig fredag!

Integratören == Spindelmannen

God förmiddag!

Kommer ni ihåg att jag skrev att jag hade ett möte med folk från Finland, Indien, Tyskland och Ryssland för ett tag sedan? Då diskuterade vi en integration mellan företagets HR-system, där användaren knappar in data om anställda, och Active Directory, där datan lagras. Jag har utvecklat den här integrationen och implementerat den i testmiljön, så nu sitter jag i ett möte där flödet ska testas från början till slut. Eller möte är egentligen fel ord – vi har en testsession på ca 4h, där någon från varje ansvarsområde är tillgänglig.

Det är väldigt spännande, även om det såklart dyker upp nya problem som vi inte förutspådde innan. Det är ju anledningen till testerna, och jag tror att det är väldigt få IT-lösningar som fungerar perfekt på en gång. Hursomhelst, jag fick en ganska skum känsla när vi började testerna: jag kände mig helt plötsligt jäkligt viktig. Inte så att jag går runt och känner mig försumbar i vanliga fall, men i det här scenariot tyckte jag det blev extra tydligt att integrationen är hjärtat i det dataflöde vi vill skapa, och jag som integratör är en Very Important Person.

Visst, det här är min subjektiva åsikt, och de flesta tycker säkert ens egna område är det viktigaste. Typ som lärare i skolan: nå, det är väl bra att det finns andra ämnen, men det är just mitt ämne som du faktiskt behöver kunna. Men jag tycker ändå jag har en poäng här: utan integrationen kan inte systemen kommunicera med varandra, och då finns det liksom inget flöde, oavsett hur bra övriga system funkar. Integratören är också den som måste ha koll på hur de olika systemen kommunicerar: vilken typ av data skickar HR-systemet ut? Vad är det egentligen AD vill ha för att kunna lagra information om anställda? Vilka konverteringar behöver vi göra? Hur ska responset se ut? För att använda ett slitet uttryck: integratören är spindeln i nätet här. Som den här snubben.

spider-man

Typ.

Uttrycket är klyschigt, men det stämmer. Precis som vi skriver på vår infosida om att driva integrationsprojekt: ”Det är ofta en stor utmaning då [integrations-]projekten av naturen kräver kommunikation mellan fler parter (som ofta inte befinner sig på samma plats). Integratörens roll får alltid inslag av projektledning och kravställning eftersom man nästan alltid får en väldigt central roll i projektorganisationen.”

Nu ska jag inte gå så långt som att säga att jag varit inblandad i projektledningen i det här fallet, eftersom jag bara haft ansvar för just den här integrationen, men jag ser ändå utmaningarna. Som till exempel i den här testsessionen, då vi är folk från totalt sex länder i olika tidszoner. Visst är det lite svettigt med första testet av något jag har byggt, men jag tycker coolhetsfaktorn väger över. Här sitter jag och är internationell liksom!

Myter om jobbet som IT-konsult

Finns det myter om IT-konsulter? Jag hade ett par förutfattade meningar kring yrket innan jag började, och för att få ytterligare kött på benen ställde jag frågan i facebookforumet ”Kodapor OT” – stort tack till er som svarade! Detta är ett ihopkok av mina tankar och svaren jag fick där, och mina åsikter kring huruvida stereotyperna stämmer.

1. Vi är antisociala killar som gillar Joltcola

Ungefär som Dennis Nedry i Jurassic Park, han som kodat hela parkens IT-system alldeles själv och ser ut såhär:

thumbnailImage

Jag tror att alla rent logiskt fattar att det här inte längre stämmer: du behöver inte vara en lonely gamer som sitter i en källare och spelar WOW hela nätterna för att vara bra på programmering/IT. MEN. Det är fortfarande underskott på kvinnor i branschen och även om utvecklingen går framåt så tar det tid att bryta mansdominansen i yrket. Jag försöker dra mitt strå till stacken genom den här bloggen, där jag vill visa att du inte behöver tillhöra Dennis Nedry-normen för att jobba som IT-konsult.

2. Vi är gifta med våra jobb

Vi som jobbar med programmering/systemutveckling har det som ett kall och något vi gärna gör gratis på fritiden. Du förväntas kunna visa upp egna, spännande projekt som du skapat utanför studier/jobbet, för att bevisa att du inte bara är bra på ditt jobb – du är ett med jobbet, det är ditt jag och din identitet.

Den här är svår, och en av de största förutfattade meningarna jag hade innan jag började jobba, vilket jag nämnt tidigare.

Åh ena sidan: ett jobb är bara ett jobb, och det är faktiskt helt okej att ägna fritiden åt andra saker än programmering. En av de saker som jag hoppas jag har fått fram i den här bloggen är att du inte behöver vara underbarn som monterade datorer vid 3 års ålder för att vara en bra IT-konsult.

Åh andra sidan så kräver jobbet otroligt engagemang i hjärnan, det går inte att programmera och tänka på annat samtidigt. (Åtminstone kan inte jag det…) Det kräver dedikation och en vilja att lösa problem, ett sug efter att leverera lösningar, och den här dedikationen har en tendens att sprida sig utöver de där timmarna mellan åtta och fem. Risken är stor att om du är gift med något annat än jobbet, så kommer jobbet vara ett rätt så krävande vänsterprassel.

Här har jag dock en teori: det är lätt att gifta sig med jobbet, när allt som krävs är en dator och internetuppkoppling. Människor kan garanterat känna samma dedikation i alla yrken, men det är inte lika lätt att leva ut när jobbet kräver aktioner på plats. Till exempel: en undersköterska som stannar kvar efter sitt pass ses som konstig, men den IT-konsult som gör samma sak, det är bara vardag.

3. Vi kan allt.

När jag ställde frågan på facebookforumet om vilka fördomar folk upplevt som kodapor var första kommentaren detta:

Vad jobbar du med då?
 - Jag är programmerare.
 a) Jaha, kan du göra en hemsida åt mig?
 b) Du, min dator är långsam, kan du titta på den?

Med andra ord: många tror att vi kan när det gäller datorer, vare sig det gäller att göra grafik till en hemsida eller en trasig dator.

IT är ett väldigt, väldigt, väldigt stort ämne och för att bli riktigt bra behöver du välja ett område att bli bra inom, annars finns det helt enkelt inte tillräckligt med livstid för att lära sig allt. Dock så blir jag ständigt imponerad över de olika gurus som finns därute och som har samlat på sig så otroligt mycket kunskap kring olika aspekter av vårt jobb – en eloge till er!

4. Vi kan ingenting

Ytterligare en myt är motsatsen till ovanstående, nämligen illusionen av att det vi gör är jättelätt och inget som kräver någon direkt ansträngning. Citat från facebooktråden i Kodapor OT: ”Fan vad skönt att vara programmerare, då kan man bara sitta i en stol vid datorn hela dagen och dricka kaffe istället för att slita och vara stressad på ett riktigt jobb.”

Min fördom kring folk som har den här fördomen är att de har en liten inblick i kodning och hur det fungerar. De kanske har skrivit ett par rader i något programspråk, men har ingen djupare insikt om vilka problem som dyker upp, vilket leder till att de tror att allt är enkelt löst med en if-sats. Ytterligare en situation när den här mentaliteten dyker upp är vid prototypvisningar: för den som tittar ser det ut som att produkten är färdig, men egentligen är den bara ett tomt skal, och de inser inte att det är betydligt svårare att implementera animationer och snygga flöden i kod än att rita upp det i Photoshop.

Sanningen ligger någonstans mittemellan: ja, det är komplext och ingen barnlek att implementera en idé i kod, men det är samtidigt inte magi, och låt inte den här komplexiteten skrämma bort dig. Jag tror att alla som är motiverade till det kan lära sig koda, och när den första tröskeln är överstigen så kommer det kännas lättare. Det svåra är inte att skriva koden utan att veta vad som ska skrivas.

5. Vi hoppar på vilket projekt som helst

Det här är lite sammankopplat med illusionen om att programmering är ett kall som vi gärna gör gratis på fritiden, och jag tycker nedanstående bild illustrerar det här väldigt bra:

13083260_10153542473356981_2475047108041777606_n

Detta har nog hänt många programmerare, och som en i Kodapor OT formulerade det: ”- Du jag har en unik app/spel/webbsideidé som du kan hjälpa mig med! (jag berättar vad jag vill ha och du gör det faktiska jobbet.)” Gärna utan betalt, med motiveringen att ”det är ju något att sätta på CV-t” och att det är idén som är värd något, inte implementationen. Det hänger också ihop med illusionen om att programmering är enkelt. Och visst, att skriva en funktion som tar en en sak och returnerar en annan är enkelt, men det är vägen från ”jag vill ha en app som gör x och y” till enskilda klasser, attribut och funktioner som är det svåra, vilket jag tror många underskattar.

Bubblare

Det verkar också finnas en del myter från andra yrkesroller i branschen, så vi tar ett gäng bubblare också:

  • Att en kodare bara kan koda och inget annat
  • Att kodare bara ska koda och ingenting annat
  • Att konsulter tar överpris och har sjukligt höga löner, helt i onödan
  • Vi har ju nästan byggt ett sånt system, vi kan väl utgå från det och bara ändra lite, det är väl redan modultänk så det är lätt att lägga till och ändra moduler? Så sparar vi tid.
  • Att det är möjligt att följa exakt samma kodstandarder som i tidigare projekt, även om det är i olika språk
  • Att man vill hjälpa alla med deras datamaskin
  • Missuppfattningen att vi bygger bilen när vi i själva verket bygger ritningen till bilen. Datorn bygger bilen (maskinkoden) utifrån ritningen (källkoden).
  • Att man förväntas vara expert på allt som alla avdelningar jobbar och pratar om bara för att det råkar visas på deras skärm
  • Att teknisk skuld är detsamma som buggar.

För att summera: det finns en jäkla massa fördomar och myter kring det här jobbet! Och då har jag ändå begränsat mig i urvalet från svaren i facebookgruppen. Vad tycker du? Har du myter att krossa eller bekräfta? Lämna en kommentar!

 

Language: