Har du en jobb eller en karriere?
Publisert November 16, 2008
I kategorien jobb | Kommenter
Hvis man til enhver tid har øyne og ører åpne vil man kunne lære noe nytt i de mest pussige situasjoner. Dette gjelder også når du ser TV på en lørdag kveld. Jeg så Chris Rock sitt Kill The Messenger show på SVT2 denne helga. Ikke bare var showet hysterisk morsomt, men det inneholdt også jobb relaterte råd! Hvem hadde trodd at en av de mest reflekterte uttalelsene jeg har hørt siste året om jobb kommer fra Chris Rock?
Spørsmålet han stiller publikum var: har du en jobb eller har du en karriere? Chris var kjempefornøyd med at han ikke lengre måtte ha en jobb nå som han hadde en karriere. En jobb er noe du gjør 9-17 og du får lønn (i Rock’s tilfelle var det å skrape reker på en rekerestaurant i Brooklyn). En karriere derimot er noe du har når du virkelig tjener penger.
Du skaper din egen karriere
Jeg har sett mange kolleger og andre i bransjen som alltid har veldig mange årsaker til hvorfor de ikke gjøre ulike ting. “Jeg kan ikke jobbe test drevet fordi prosjekt lederen gir meg ikke tid”. “Prosjektet suger fordi vi bruker utdatert teknologi og arkitekten er en dust”. Denne typen uttalelser kommer oftest fra de som har en jobb og som ser på det de gjør som en jobb.
Hvis du derimot ser på det du gjør som en karriere lar du ikke detaljer som lite tid og inkompetente arkitekter hindre deg i å gå videre i din karriere. Du finner måter å komme deg rundt hindringene på slik at du kan komme videre.
Hvis alt du kommer opp med er unnskyldninger til hvorfor du ikke gjør ulike ting, så er det heller ikke rart du ikke får nye arbeidsoppgaver eller at du aldri får gjøre noe du synes er spennende. Muligheten til å gjøre spennende ting skaper du selv og du kan ikke vente på at de lander i fanget ditt. Du må ta det du gjør som en karriere og ikke en jobb du får betalt for. Hvis du er en utvikler som ser på det du gjør som en jobb og er fornøyd med det, så må du heller ikke forvente å gjøre spennende ting. Du må jobbe for å komme i riktig posisjon, du må ta sjanser, du må stille spørsmål.
Så still deg selv spørsmålet: Har jeg en jobb eller har jeg en karriere?
Elegante løsninger?
Det Chris sier her sammenfaller veldig med ideène som Mathew E. May skriver om i The Elegant Solution: Toyota’s Formula for Mastering Innovation. Boken handler om hvordan Toyota har skapt et system for kontinuerlig inovasjon og at dette er nøkkelen til at de er verdens beste bil produsent. Arbeidsgivere må i følge boken få sine ansatte til å føle at de har en karriere, langt mer enn at de har en jobb.
Desverre kunne ikke YouTube finne akkurat sekvensen jeg refererer til, likevel så legger jeg med en godbit fra showet Kill The Messenger:
Kommentarer
Ønskereprise på XP Meetup
Publisert November 16, 2008
I kategorien smidig | Kommenter
Lyntalen “Agile sier du? frAgile sier jeg” jeg holdt på Smidig 2008 er en del av ønskereprisene fra konferansen på XP Meetup den 17. November. Dette er en ypperlig anledning til å få med seg det beste av det du ikke fikk sett under konferransen eller for deg som ikke kom deg dit er det en anledning til å se hva du gikk glipp av.
Detaljene om hvordan du kan delta finner du på Oslo XP November Meetup. Vi ses!
Oppdatering: Presentasjonen min fra møtet ligger nå ute, sammen med alle de andre presentasjonene, så du kan se dem dersom du lurer på hva jeg snakket om.
Dette var første gang jeg var på XP Meetup i Oslo og jeg må si det ga mer smak. Utrolig mange folk, veldig bra foredrag og ikke minst gode diskusjoner etter foredragene. Hvis du ikke var der så burde du angre, for dette er et community som er av de beste på planeten når det gjelder smidige metoder.
Kommentarer
Gro applikasjonen din som en åker
Publisert November 2, 2008
I kategorien utvikling | Kommenter
Jeg har vokst opp på en gård i fjellbygda Folldal og er dermed veldig mottagelig for analogier og eksempler som tar utgangspunkt i gårdsdrift. Overraskelsen min var stor da jeg leste en artikkel av XP-guru Kent Beck som nettopp bruker bøndenes metode for å dyrke åkeren for å vise hvordan man kan gjøre det samme i applikasjons design.
Artikkelen First One, Then Many tar for seg et klassisk dilemma innen systemutvikling. Du skal lage et system som skal håndtere en transaksjon i første omgang, men man antar at det vil måtte håndtere mer enn en senere. Klassisk systemutviklings litteratur sier da at du må ta høyde for dette i ditt design. Kent forklarer i sin artikkel hvorfor dette ikke er en god ide og han bruker bonden som utgangspunkt.
Bønder dyrker ikke åkeren sin for at den skal være komplett fra dag en, han dyrker den for at den skal være perfekt når det er tid for innhøsting. Derfor bruker bonden ikke bare en sort frø, han bruker gjerne flere sorter frø for å oppnå best resultat. Bonden bruker en frø type som gror raskt for å stabilisere jordsmonnet i tillegg til den egentlige sorten frø som gror litt saktere. På denne måten sørger han for at åkeren over tid blir utnyttet optimalt.
Jeg er veldig enig i Kent sin måte å tilnærme seg applikasjons design. Gjennom å gjøre “smarte” antagelser og å “ta høyde for” ting så skaper man problemer for den som kommer senere. Det er langt bedre å ha en kodebase som reflekterer det som systemet faktisk gjøre, enn en kodebase som inneholder halvveis implementert funksjonalitet. I Lean Software Development kalles dette søppel (eller waste (eller ennå mer trendy kalles det muda)). Søppel har en tendens til å skape ubehag dersom det opptrer i større mengder og blir liggende over tid. Derfor er jeg helt enig med Kent sine tanker om å la kodebasen reflektere hvordan virkeligheten faktisk er. Det gjør det enklere å både vedlikeholde og videreutvikle en løsning.
Hvis du tenker på Kent sin artikkel neste gang du sitter å forsøker være kreativ når du spesifiserer et grensesnitt så vil du, kunden og systemet nok takke deg til slutt.