's Picture

Några råd på vägen till framtidens utvecklare

Postad av Joel Abrahamsson

Tidigare i veckan höll jag en lunchföreläsning för studenter på KTH. Titeln var "Hur hamnade jag här? – Eller: några råd på vägen". Ämnet var min egen resa från KTH-student till att jag förra året fick utmärkelse som Sveriges bästa utvecklare av IDG. Jag avslutade presentationen med några råd som jag tycker är bra för aspirerande utvecklare. Inte ens mitt ego tillåter att jag berättar min egen historia i detta blogginlägg men kanske kan råden komma även andra till nytta. Here goes!

Första jobbet

Jag började min utvecklarkarriär med att sitta på "supporten" på en webbyrå. Det innebar att jag jobbade med sajter som byrån hade utvecklat åt kunder och som nu inte aktivt vidareutvecklades förutom mindre buggfixar och förbättringar. Det var inte det sexigaste jobb jag haft men kanske det mest lärorika. En vanlig dag kunde jag hoppa mellan tio, ibland fler, olika applikationer för att fixa buggar i kod som någon annan hade skrivit. Tack vare detta fick jag se exempel på många olika sätt att skriva kod, lära mig vad som funkade och vad som inte funkade. Eftersom jag ofta inte förstod vad koden gjorde eller hur den fungerade var jag tvungen att gå att prata med den som hade skrivit den. Det innebar att jag också tvingades lära känna alla andra utvecklare på företaget.

Ärligt talat så hade jag inte alltid jätteroligt där på supporten men nu, tio år senare, är jag väldigt glad att jag hade den här perioden i mitt liv. Jag kan också konstatera att många av de andra utvecklare som jag har uppskattat mest att jobba tillsammans med under min karriär har gått igenom liknande perioder i sina karriärer. Tack vare detta är de duktiga på att felsöka, gräva i loggar, sätta sig in i problem och inte minst har de en ödmjukhet när de skriver ny kod som ibland saknas hos dem som bara sysslat med nyutveckling.

En sådan utvecklare är vår egen Oscar Tholander som, när jag visade presentationen för honom, summerade det hela med:

Det är enkelt att skriva ny kod, svårare att underhålla kod. Altså lär man sig mer av att underhålla kod.

Ställ frågor – rätt

En, enligt mig, viktig egenskap för utvecklare, inte minst juniora sådana, är att kunna ställa frågor. Ingen utvecklare kan allt och att ta hjälp av kollegor är viktigt. Det gäller dock att göra detta på rätt sätt och med lagom frekvens.

Att ställa frågor hela tiden utan att försöka lösa problem själv först leder till irriterade kollegor och troligtvis att man inte lär sig någonting. Men, om man aldrig ställer frågor innebär det troligtvis att man spenderar för mycket tid på att sitta fastkörd i ett problem. Alternativt att man skapar lösningar som hade blivit bättre om man hade bollat dem med någon annan.

Med andra ord vill man som utvecklare ställa frågor till sina kollegor med lagom frekvens. Det är också viktigt att se till att lära sig i samband med att man ställer frågor. När man frågar en kollega ska det inte bara vara i syfte att lösa ett konkret problem utan också för att lära sig av svaret. Ett enkelt sätt att märka om man misslyckas med det är om man ställer samma fråga flera gånger. Då har man uppenbarligen inte fått någon djupare förståelse den första gången.

En bra fråga är enkel att besvara.

Alla kan ställa en fråga, men att ställa en fråga på ett bra sätt är en konst. Bemästrar man den kommer man få ut betydligt mer av interaktionen med sina kollegor. En bra fråga är enkel att besvara. Detta åstadkommer man genom att berätta vad man själv redan vet, vad man inte vet och genom att berätta så mycket som möjligt om sammanhanget.

Ett banalt exempel på en dålig fråga är: "Hur skriver man ut grönt i konsolen?". Här finns det massor med öppna frågeställningar som frågeställaren redan vet men som den som ska besvara frågan måste reda ut. Vilket programmeringsspråk är det det gäller? Är det ordet "grönt" som ska skriva ut eller är det något som ska skrivas ut med grön färg?

En bättre formulerad fråga vore därför: "Hur kan jag skriva ut text med grön färg i konsolen med Java?" Men, frågan kan göras ännu bättre. Om man också förklarar varför man vill skriva ut något med grön färg kanske den som besvarar frågan också kan tipsa om en annan bättre lösning.

Det går att dyka ännu djupare i hur man ställer bra frågor. Det har vi dock inte plats för i det här blogginlägget utan istället kan jag varmt rekommendera ett blogginlägg på ämnet, Julia Evans "How to ask good questions".

Läs böcker!

Om man har läst en avancerad utbildning, exempelvis de civilingenjörsstudenter jag talade för, så har man lärt sig en viktig egenskap: att lära. Att efter studierna inte utnyttja detta vore slöseri. Dessutom är man långt ifrån fullärd efter studierna. Det är nu man på riktigt ska lära sig utvecklar-yrket och ingen annan kommer att ta ansvar för ens fortsatta kompetensutveckling.

Mycket lär man sig naturligtvis på jobbet men för att få de djupare insikterna kan man med fördel ta till sig böcker. Naturligtvis går det ofta lika bra med videokurser, blogginlägg eller podcasts om man föredrar det, men vissa klassiska verk bör man ändå ha läst. Jag tänker på böcker som Robert C. Martins "Agile Software Development, Principles, Patterns, and Practices", Mary och Tom Poppendiecks "Lean Software Development: An Agile Toolkit" och Kent Becks "Extreme Programming Explained: Embrace Change".

Genom att läsa böcker blir man en bättre utvecklare. Inte nödvändigtvis för att man alltid kan, eller vill, applicera det man läst i den kod man skriver utan snarare för att man vidgar sina vyer. Dessutom lär man sig terminologi och kan bättre föra sig i samtal med andra utvecklare.

Att läsa böcker är dessutom en utmärkt karriärinvestering. Jag har många gånger känt mig underlägsen inom ett tekniskt område jämfört med andra utvecklare. Då har jag köpt och läst en bok i ämnet. Inte sällan med resultatet att jag inte bara kan området lika bra som mina kollegor utan ofta rent av bättre. I dessa lägen kan man spinna vidare på sina nyfunna kunskaper genom att lära andra. Både i det dagliga arbetet och genom att blogga eller föreläsa vilket alltid uppskattas.

Fler tips och föreläsningen

I min presentation hade jag fler tips, bland annat att man bör känna till Dunning-Kruger-effekten, en rant om att skolorna tenderar att svartmåla kodduplicering väl mycket (snarare än att fokusera på att abstrahera kod som delar anledning att förändras) samt några tips på strategier för problemlösning. Här har jag dock valt att fokusera på de viktigaste råden.

Föreläsningen då, hur gick den? Tjaa.. enligt en åhörare som kom fram efteråt var den "över medel".

Toppbild: från Flickr, creative commons.

PS. Missa inte vår nästa bloggpost, följ oss på Twitter!

Till startsidan