Når målet er det samme men utgangspunktet er ulikt
Hvordan klare å samarbeide i et IT-prosjekt når utgangpunktet og forutsetningen for de involverte utviklerne ikke er det samme? Tankene og spørsmålene svirrer i hodet mitt etter en kort diskusjon i utviklingen av teknologi for å utføre og sette opp prosjekter.
For juniorutvikleren så er utgangspunktet og forutsetningene noe helt annet enn seniorutvikleren. Fellesnevneren er at begge to ønsker den meste effektive veien til mål. Der er de enige.
Jeg vet dette innlegget er langt. Medium anslår at det vil ta deg i underkant av 8 minutter å lese hele teksten. Derfor har jeg en TL;DR, krydret litt med bilder for å byte opp og brukt noen overskrifter. Emnet er et stort lerret å bleke. Jeg er inne på noen få punkter av svært mange faktorer som spiller inn for at et prosjekt skal være vellykket.
I dette innlegget drøfter jeg hvilken egenskaper både juniorutvikleren og seniorutvikleren bør ha i tillegg til kunnskap om selve jobben de utfører.
TL;DR
Ingen kan kjøre et sololøp om vi sammen skal bli gode. Mange fokuserer på verktøyene. Det er ikke alltid verktøyene som er løsningen for en smidig gjennomføring. Nøkkelen for suksess er kunnskapdeling og stikkord som ydmykhet, åpenhet, kommunikasjon og samarbeidsvilje.
Helt nederst i teksten har jeg listet opp noen få anbefalte lenker.
I IT-verden kan det være et stort gap mellom juniorutvikleren og seniorutvikleren. Felles er at de begge to gyver løs på oppgavene med stort mot. Ofte er resultatet det samme. Men veien, og når jeg nå skriver veien så mener jeg koden, og tiden man bruker kan være ulik.
Det er på tide med noen stikkord for å drive denne teksten videre: ydmykhet, åpenhet, kommunikasjon og samarbeidsvilje.
Juniorutvikleren
Juniorutvikleren, enten det er en erfaren junior eller nyansatt, må våge å innse egen svakhet. Det er ingen som blir mester av å tro at man er en mester.
Å vise ydmykhet på at man ikke kan alt og ikke minst være åpen på at enkelte ting er krevende er ikke en svakhet. Det er en styrke å kunne ha en god selvinnsikt. Men ingen hvilepute.
Spesielt for nyansatte kan det være å balansere på kniveggen mellom å være ærlig på at man ikke er så god som senioren og vise at man er verdig til å beholde jobben. Det er likevel bedre å komme med de dumme spørsmålene enn å lure seg selv og andre til å tro at dette er noe man kan.
Det jeg kaller en erfaren junior er han som ikke lengre er nyansatt men utfører junioroppgaver. For en erfaren junior så gjelder det samme som for den nyansatte junioren. Man må våge å være åpen på at ting ikke nødvendigvis er så lett.
For en junior så er det viktig at man er lydhør og suger til seg ny kunnskap.
Seniorutvikleren
Like mye som for juniorutvikleren så må seniorutvikleren våge å innse egne svakheter. Samtidig som at seniorutvikleren har en utøvende makt. Gjerne den som setter standarden eller bestemmer prosedyrene. Hvis det skulle finnes noe slikt da.
Når juniorutvikleren burde fokusere på åpenhet og ydmykhet ovenfor sine egne evner og kunnskaper så bør seniorutvikleren fokusere på kommunikasjon og samarbeidsvilje.
En god senior har mye kunnskap og lang erfaring. Likevel er det aldri for sent å lære en gammel hund nye triks.
Hvis seniorutvikleren skal kunne få med seg resten av laget (et lag består jo ofte av en blanding seniorer og juniorer) så er det viktig at man kommuniserer hvordan og hvorfor ting bør være som de bør være.
Selv om junioren kan oppleves som en akilleshæl i et prosjekt så vil ikke den akilleshælen forsvinne om man ikke er villig til å være med å styrke den. Det bør utøves en vilje til å kunne samarbeide med juniorer.
Å fjerne det svakeste leddet i en kjede gjør faktisk ikke kjeden sterkere. Arbeidsmengden blir større på de gjenværende. Ved å styrke det svakeste leddet så styrker man hele kjeden.
Den gode læremester
Jeg hadde en matematikklærer på høgskolen som ikke kunne forstå at vi elever ikke forsto hva han snakket om. Forstår du?
Han tok alltid den samme frasen: dette skulle dere ha lært på videregående.
Hvem har vel ikke opplevd det at noen forventer at man skal kunne noe man aldri har hørt om tidligere? Vent nå litt, jeg hadde jo også en lærer på videregående som i norsktimen dro samme frase: dette skulle dere ha lært på ungdomsskolen.
Lærerne hadde altså så store kunnskap om faget at de ikke klarte å sette seg inn i elevenes ståsted. De klarte rett og slett ikke å forstå at elevene syntes det de snakket om var vanskelig.
Dette skulle dere ha lært på [sett inn skoletrinn her]! Nødutgang når elevene ikke forstår hva det undervises i.
Samtidig så ble frustrasjonen i klasserommet større og større. Men kunnskapen den forble kun hos våre lærere.
Vi som elever skulle heller forklart vår lærere hvorfor vi ikke forsto hva de forsøkte å undervise oss. Først da hadde de (kanskje med godviljen) klart å endre på metoden for undervisning slik at elevene forsto.
Men det var ingen som turte å ta til ordet fordi de fryktet for lærerens karaktersetting. Det er i mange tilfeller bedre å tie stille enn å bekrefte at man er dum.
Fallgruver
For det er noen fallgruver …
For en juniorutvikleren så kan seniorutvikleren og prosjektleders vrede føles skummel. Man risikerer at prosjektleder ikke tar en med på neste prosjekt. At seniorutvikleren ikke ønsker å samarbeide. I dette tilfellet gjør man det stikk motsatte av de punktene jeg foreslår i teksten over og ting kommer ikke frem i dagens lys før det er betent.
… for bedriften
Som bedrift så er det kanskje lettere å se på økonomien fremfor den kollektive kunnskapen i bedriften. Så lenge prosjektet blir levert til avtalt tid og helst med overskudd så er det lett å se igjennom fingrene på kvalitet og kanskje at seniorutviklerne har dratt hele lasset etter at juniorutviklerne ble fjernet fra prosjektet.
Den beste metoden er å heller bruke tid på å styrke juniorene. På sikt vil jo det styrke den kollektive kunnskapen i bedriften på tvers av prosjekter. Og dermed kan også bedriften ta på seg flere og mer inntektsbringende prosjekter.
I større grad en juniorutvikler kan stå på egne ben jo større styrke har bedriften.
… for junioren
Som Sonny Reico skriver så finnes det en mengde artikler og gjennomganger på internett man kan lese for å styrke sin egen kunnskap. Men hvem av dem er legitime og er av god kvalitet?
Når man skal lære seg noe som er helt ukjent så har man som junior ofte ingen referansepunkt.
With no reference point, it’s like walking the street with blindfolds attached around your eyes, or chasing something that’s about to get away.
- Sonny Recio
Å bygge seg opp kunnskap tar tid. Selv har jeg (uten at dette er et pro-tips) bygget meg opp en anstendig liste med RSS-feeds som jeg abonnerer på. Med erfaring så har jeg klart å skille ut de gode fra de dårlige. Men det er fortsatt vanskelig å skille ut hvilken artikler som er verdt å lese og hvilken artikler som er aktuelt å lese for å styrke sin egen kunnskap.
Men fortsett og lese. Forsøk å snapp opp det seniorene snakker om og undersøk på egenhånd. Da kan man faktisk stille kvalifiserte spørsmål uten å være helt på bar bakke.
… for senioren
Å ha en person som ikke forstår deg på laget kan tømme enhver person for krefter. Det kan være fristende, fordi det tar kortere tid og er lettere, å utføre oppgaver selv fremfor å forklare eller lære noen å gjøre det samme. Stol på meg, selv vi juniorer kjenner på den følelsen noen ganger.
Prøv å tenkt tilbake på den tiden du selv var junior og til tider famlet i mørke. Det er ikke snakk om at junioren skal kunne alt det du kan. I tillegg er de fleste juniorer rimelig oppegående. Så ved å hjelpe dem i riktig retning så får de til mye på egen hånd.
Gi junioren tid til å prøve og feile. Ikke prøv på et sololøp. Det vil bare slite deg selv ut. Tid brukt er tid spart.
… prosjektleder
En prosjektleder ønsker naturligvis å bygge seg et lag med kun de beste. Men det er ikke alltid man er privilegert og kan gjøre dette.
Ved å ta med et godt knippe utviklere med ulike erfaring og ved å våge og budsjettere med tid til opplæring så kan man likevel komme svært så godt ut av det.
Det må settes av tid til at de som skal utføre oppgavene får snakke sammen. Ikke bare i oppstarten av et prosjekt men også underveis.
Det er ikke noe i veiene for å sette samme to vidt forskjellige utviklere på oppgaver. Så fremt de ikke er helt på hver sin kant da. Men her kommer jo åpenhet og kommunikasjon inn i bildet.
Anbefalt lesning:
Why it’s hard to be a programmer Developers: The Why and How to Writing Technical Articles 5 real-life examples of beautiful technical documentation Jon Skeet — The Chuck Noris of programming