Hur blir man icke-Junior utvecklare

Plöj någon manual med API-er som har relevans i ditt kommande projekt. Bara att skumma igenom så får du en översikt om vad som finns och vad som kan göras. Det stärker din ryggrad. Jag tog för vana att bläddra igenom "System Call Reference" en gång per år, välja ut något intressant och bara testkoda lite med sådant som inte var direkt bekant. Hade som t.ex. inte någon "nytta" av signalhantering och minnesmappade filer de första åren, så det var bra områden att testa lite på, även om det inte krävdes i jobbet.

Var också lite öppen för din kodstyling, hur du skriver kommentarer och namnger variabler. Sådant utvecklas över tid och är värt att tänka på. Förbättringar brukar poppa upp när du börjar läsa din egen gamla kod.

Lycka till och var rädd om dig, tighta deadlines kan vara jobbigt för hälsan. Räkna med att allt tar dubbelt så lång tid som man tänkt sig. Att bli färdig i förtid är bättre, än att överskrida det man sagt/lovat.

Jag arbetar med Microsofts Power Platform, dvs utvecklare inom Low-Code. Finns säkerligen en del som skiljer sig, men tror mycket är det samma.

Inom PP så skulle jag säga att det som skiljer en junior och en senior utvecklar åt oftast handlar om "kunskapen att planera med framtiden i åtanke".

- En junior utvecklare får en uppgift, och designar en databas som fyller kraven. Den seniora utvecklaren designar en skalbar databas som inte behöver ersättas ifall behoven växer.

- En junior utvecklare fokuserar på sin uppgift, medan den seniora utvecklaren har fokus på hela cykeln. Från kravställning till produktion och drift. Tänker på testbarhet, CI/CD, rollback-planer etc.

- Junior utvecklare får arbetsuppgifter // Senior utvecklare skapar arbetsuppgifter, prioriterar dem och delar ut dem till juniora utvecklare.

Nu är du ju junior så du kommer att uppfattas som det, men oroa dig inte över det. Du är ny, så ta vara på den perioden; ställ många frågor, även "dumma" frågor. Lär dig av misstagen du kommer att göra.

Icke-junior blir du över tid, det kommer naturligt och det kommer synas om du försöker lämna den rollen i förtid. Misstag mig inte, visa framfötterna och jobba hårt men en roll är bara en roll.. Lås inte upp dig på det för mycket, om du fortfarande är kvar där efter 2-3 år så kanske det tåls att ta upp med chefen, men knappast innan dess.

Var den du är och äg det. Det finns ingen anledning att försöka framstå som något du inte är. Om du gör misstag, och det kommer du göra, se till att vara den som upptäcker det, erkänn det och fixa det.

Noggrannhet och tålamod. Du behöver inte vara snabb om du gör rätt. Testa din skit och se till att du vet hur den funkar och varför den funkar så. Ha som inställning att det är du som kommer att underhålla koden om fem år och att du då inte vill ta hand om något halvgenomtänkt skräp.

När jag läser din PR (och du läser din egen committ om fem år) så vill jag (du) veta i vilket sammanhang och i vilket syfte ändringen gjordes. Jag vill veta hur du testade ändringen, gärna med incheckad testdata. Vad du gjorde framgår ur diffen, men känn dig fri att guida mig lite om det är en stor ändring.

Håll logikändringar och uppstädning i separata committs, så att det blir lätt att se vad som faktiskt spelar roll. Kolla gärna på till exempel hur utvecklare i Linux förklarar sina ändringar för de som ska granska.

Kommentarer i koden som kan genereras med AI från koden är antagligen överflödiga. Det är kraven, användningsfallen och användarens/externa systems beteende och målsättning som är intressant. Vad får inte gå sönder om man ändrat i koden? Samma sak gället i ännu högre grad automattester, vad är det för användningsfall/krav som testas och varför.

Jag har för tillfället den delikata situationen att det är ”senioren” i teamet som gör alla misstag ovan, medan ”junioren” löser allt galant. Det har med personlighet att göra mer än ålder. Envishet, noggrannhet och tålamod kan slå erfarenhet kunskap. Hela paketet är förstås att föredra.

Hos oss (tidigare) så kunde man bli senior tidigast efter 7 år, senior normalt är inget man glider in på, utan det kräver en hel del.

Inom större företag (sitter på ett nu) så har man olika nivåer (levels) med en hel del krav för att nå nästa nivå, och man kan inte avancera inom två år efter en avancering. Varje nivå innebär en höjning av lön, högre bonustak och fler eventuella aktier. Senior nivå ger ett ordentligt kliv i kosing, men det innebär ofta ett större ansvar.

På vissa företag betyder titeln senior ingenting och kan delas ut / användas hejvilt, så generellt skall man inte lita på den.

Semantik, ordbajseri. Den som är junior någonstans kan vara senior någon annanstans. Jag gissar Apple, Microsoft etc har högre krav på deras seniorer är vad ett litet utvecklingsföretaget har.

Alla människor är olika. Inom de flesta yrken så handlar det mest om att leverera. Det finns tur och otur i det hela. Jag har sett senior utvecklare gått från ett bra jobb, börjat ett nytt där det har varit kaos och allt har gått skit så den blev uppsagd.

Det råd jag har till nyanställda är kämpa. Och med kämpa så betyder det ofta att inte bara jobba 40h och resten av tiden vara ledig, utan använda mycket tid till självstudier. De jag har sett som ej har klarat av jobbet så är det att de ej har levererat, ingen annan anledning har jag hört talas om. Där man som sagt kan ha tur eller otur i vilka uppgifter man får.

Emot kunder så spelar sociala egenskaper in, om man besöker en kund så kan utseendet också såklart påverka det intryck de får.

Senior och Junior o.s.v. är ganska lösa termer, som reflekterar vad andra utvecklare kan ha för förväntningar på arbetet du levererar. Men tid och erfarenhet är två stora faktorer som påverkar vad du betraktas som.

"Och finns det vanliga misstag eller beteenden som juniora utvecklare ofta gör"

Känns lite som en Youtube-clickbait-rubrik. Lyssna inte så mycket på sånt. Istället ha som mål att lära dig något nytt varje dag/vecka och med tiden bli bättre och bättre på det du gör.