Pakk sekken med ting du trenger for turen

Don’t let yourself get attached to anything you are not willing to walk out on in 30 seconds flat if you feel the heat around the corner

Neil McCauley – from the movie Heat

Sitatet er fra nittitalls filmen Heat med blant andre Pacino og DeNiro, ikke nødvendigvis den beste filmen men sitatet er bra. En skal være forsiktig med metaforer, men jeg mener dette sitatet er noe du bør ha bakhodet når du jobber som programmerer (og trolig også andre roller, men jeg kan bare med sikkerhet snakke om programmerere).

Veldig mange selskaper er veldig gode på å skape gode sosiale- og faglige relasjoner blant sine ansatte. De har lagt til rette for at du får disse behovene dekket der. Det er ikke med onde hensikter nødvendigvis, men for å skape ansatte som trives og vokse sammen med det formål å gjøre best mulig jobb. Selskaper investerer mye penger i på rekruttere riktig folk og de gjør også sitt beste for at de fleste skal bli værende.

Det er ikke noe galt i dette og at selskaper forsøker skape bra miljøer er en god ting. Det er spesielt nyttig tidlig i karrieren. Disse arenaene er gode steder å trene seg på å diskutere, presentere eller på andre måter interagere med likesinnede om faglige tema. Poenget er å forstå hvordan disse skal brukes slik at de hjelper deg vokse videre.

Vær våkne og beviste

Et godt råd som lønnsmottager er å alltid være bevist rundt hva du investerer din tid i og hva det er du eventuelt får ut av det. Det er ikke nødvendigvis snakk om karriere, penger eller lignende. Å få en god følelse eller å ha bidratt til et fellesskap er også verdifulle ting å få ut av en jobb. Uansett hva du velger å bruke din verdifulle tid på, sørg for at den brukes på noe som gir deg noe. Ikke fortell deg selv at du skylder et selskap som betaler deg for å gjøre en jobb for dem noe som helst. Vær bevist og om nødvendig kynisk i alt du gjør slik at du kommer godt ut av det.

Det betyr ikke at du skal være et dårlig menneske og behandle de rundt deg dårlig. Hva jeg mener er at du ikke skal tillegge et selskap egenskaper som andre mennesker har. Et selskap har ingen følelser, lojalitet eller annet til deg. Du er en ressurs som kreves for å gjøre en jobb som igjen er for å nå ett eller annet mål.

Invester i det du kan ta med deg

I context av det å være programmerer så er det noen konkrete ting som er lurt å ha i mente. Invester tid i ting som du på ett eller annet vis kan ta med deg videre (fordi du kommer til å forlate stedet du jobber nå, tro meg).

Hvis du skal holde en presentasjon på en fagdag for selskapet ditt, sørg for at du på ett eller annet vis kan gjøre den tilgjengelig utenfor selskapet. Det vil si at du i utformingen alltid bør ha i bakhodet at budskapet må kunne deles. Hvis det er for mange sensitive ting, så kan du ofte ikke dele det. Er det konkrete erfaringer, forsøk å pakke de på en måte som gjør at det ikke hindrer deg i å spre det.

Åpen kildekode er en mulighet for deg som lønnsmottager til å kunne gjøre nytte for deg i jobben, samtidig som du har noe verdifullt å ta med deg videre i karrieren.

Ikke begrens deg

Veldig mange teknologiselskaper har i dag en eller annen chat løsning som fungerer som faglig- og sosialt lim. Det er effektivt og på mange måter nyttig, men det er viktig å ikke begrense seg i den faglige omgangskretsen (fordi husk på, du vil slutte i jobben du er i nå).

Finn deg arenaer å delta på som ikke er knyttet til ditt arbeidssted. Det finnes både fysiske arenaer som Meetups, konferanser, frokostseminarer, etc. Du kan etablere deg som en autoritet på Stack Overflow innen et emne. Hvis det er spesielle teknologier eller emner du føler er spennende har veldig mange av disse ofte en åpen chat du kan bli med i. Hvis du benytter et åpent kildekode prosjekt mye i jobben din, så er det ofte at disse har arenaer hvor du kan bli del av et større faglig miljø. Det finnes veldig mange måter å knytte faglige relasjoner på i vår tidsalder, ikke la deg begrense til selskapets egne løsninger.

Å forlate en jobb handler ofte om å bryte med noe kjent og trygt, jo mer du har av et faglig- og sosial nettverk som er knyttet til deg selv og ikke jobben jo friere står du til å ta det beste valget for deg.

Moralen er å ikke la deg begrense i hvordan du bygger ditt faglige nettverk, bygg noe som er ditt og som du tar med deg uansett hvor du går.

“Slipp fangene fri det er vår”

Photo by Jed Villejo on Unsplash

Overskriften er også film relatert og referer til filmen med sammen navn. Hittil i min karriere har jeg byttet jobb relativt ofte i følge den norske normen. I løpet av disse byttene har jeg sett altfor mange som bare blir igjen. Enkelte ganger blir folk værende ut av en følelse av at de skylder et selskap eller mennesker i et selskap noe. Andre ganger kan det være fordi det å bytte jobb virker skremmende. Hvis man kommer opp i en viss alder, som meg selv, så er det også en viss frykt at man har blitt for gammel til å bli ansatte noe som helst sted.

Guttene i Kortslutning har en veldig bra episode om dette temaet. De forteller modige sine følelser knyttet til å det å bytte jobb for første gang i episoden Det å bytte jobb. Det kan være skummelt første gang og det å bytte jobb er ikke alltid. Likevel så er det stort sett ikke så skummelt som du en tror.

Ta ansvar, ta sjansen!

Mennesker som jobber med teknologi i 2019 her i Oslo har absolutt ingenting å frykte ved å bytte jobb. Jeg er sikker på at om du stiller deg opp på Oslo S med en plakat og CV i hånda så har du jobb i løpet av morgenrushet. Det er og har vært siden tidlig 2000-tallet en brennhett jobbmarked, så hvorfor i alle dager skal man bli værende om man ikke føler man får noe ut av det?

Lærer du ikke noe eller føler du utvikler deg noe som menneske? Da er det bare å begynne finne seg et nytt sted. Du vil ikke angre, selv de gangene den nye jobben viser seg å være feil. Da vet du, om ikke annet, mer om hva du ikke liker til neste gang du bytter jobb.

Photo by Colton Duke on Unsplash

drawing of computer program

An approach to problem solving with computer programs

When you start learning to code you develop an idea of what people who does it for a living knows. I remember when I started, I was convinced that everyone around me knew everything and was never in doubt about what the correct approach would be. There was little to read about how to approach coding except for academic articles and books.

In this day and age the situation is very different. There are countless resources where you can see how people approach problem solving using computer programs. You can watch live streams of people working on popular Open Source projects or watch tutorial videos. They all give good insight into the process of coding and shows how you can reason about issues you encounter. One thing you don’t get to see in these rehearsed videos is how they come up with the solutions and how they learned to solve it. In short, you don’t get to see their frantic googling, pulling of hair and general frustration which is usually involved. You don’t see the chat messages discussing topics and expressions of doubts about the solutions.

What I’m getting at, is that there are some things related to problem solving with computer programs which we don’t discuss that often and which is not shown in most coding videos. I will try to outline my preferred way of approaching a problem in an attempt to show that even though I have done this for a living in almost two decades, my approach is not one linear process where I know the steps nor the place I want to end up.

Make it visual

Regardless of wether it is coding up an UI component or creating an API endpoint to solve a data access issue, I have to make it visual. What I mean by that is that I got to draw something somewhere. It could be doodling something on a piece of paper, drawing on a white-board or putting some boxes’n things in a Google slide. This visual I try to update as learn more about the problem I’m trying to solve. More often than not I have to start over. Usually my first assumptions where wrong. That is not a problem! It means I’ve learned something and it’s better to “scrap” a drawing or slide than to revert code changes deployed in production. 

I have met programmers who are able to process things like this in their head. They are able to find design flaws etc by visualising what happens it in their head. This is something I struggle with. I can perhaps “run” a couple of steps of a process in my head, but then I loose it. My short term memory is terrible and I’m also not that great at keeping focus when thinking. Therefor I commit my thoughts to paper or some digital tool. One nice side effect of this is that documentation comes pretty easy, as I’ve been doing that throughout the problem solving process. 

The format in which I draw or the tool I use does not matter, it’s proximity and flexibility that matters. I find modelling tools constraining rather than helpful and enabling. Therefor I tend to use generic tools for visualising / drawing / doodling. There are formal approaches on how to modell software processes and create designs. Personally I find just “drawing whatever” is more useful then ensuring it is 100% correct UML syntax. I am not saying you should not seek learning techniques for modelling software. Everything you can learn which can be added to your toolbox is always worth checking out.

Large problems only? 

My process is the same for wether I’m trying to create some distributed architecture or if it is creating a small UI component. Once the issue requires me to think more than a couple of steps ahead, this is my go to approach and it is something I feel comfortable with. I find that there is no problem too small where this does not help. Sometimes my head just isn’t in it and doing some simple drawings works wonders for me.

Solving the problem

Once the design and preparation is done it is time to solve it. I use similar approach when it comes to writing the code for solving the problem. You can visualise the problem to solve with a drawing, but you can also visualise the flow of a program using text. I learned this approach reading the book Code Complete by Steve McConnel. He said that before writing actual programming statements, you can flesh out the details just using code comments. 

someFunction () {

  // if there is an item
    // render delete button
    // if not render the add button
  
    // write the label of the item
  // then add a parenthesis and a number

}

Once you have got some thing written down, read it back and see if it still makes sense. You should refactor the code block until it makes sense and it does what you meant it to. Perhaps you should extract a method or maybe you need to call out to a service and retrieve some more data. Refactoring when all you have is code comments is easy. As opposed fixing written and deployed code. I’m not saying this is something you must do, it is just one approach which I find helpful at times. 

There are other techniques, such as test driven development, which serves the same purpose as writing code comments before coding (I am aware there are more advantages, but this is not the topic of this post). Others use pseudocode to achieve the same thing (check out Thomas’ post on the topic  “I love pseudocode”). Learning multiple ways to solve problems is useful and something that will be beneficial regardless of the technological platform you happen to be working with.

“Kids, stay in school”

This article contains methods which happen to work well for me. Others will have different approaches and techniques. What is important is staying open minded and stay curious. To keep learning is essential to having a long career as a programmer. 

Hva er en god systemutvikler?

Dusty road in a desert landscape with a car
Veien til å bli en god systemutvikler er hompete, støvete og endere kanskje ikke der du tror.
Kilde: https://www.flickr.com/photos/honzasoukup/2398942904/

Hva er en god systemutvikler? Dette er et ladet spørsmål, så først vil jeg legge ned min definisjon av systemutvikling. Det er et lagspill der man sammen leverer en digital løsning på en utfordring / problem.Legg merke til at jeg ikke sier «hva er en god programmerer». Hvorfor ikke? Fordi programmeringsdelen er bare en  del av det som inngår i systemutvikling. Så, hvilke egenskaper trengs for å være en dyktig systemutvikler i 2018 og i tiden fremover? 

Kommunikasjon 

Du trenger først og fremst å være i stand til å kommunisere med de du jobber med. Det betyr at du kan gjøre deg og dine tanker forstått enten verbalt eller skriftlig. Det er sjelden man sitter alene og utvikler noe uten at man må kommunisere med noen. Dette gjelder både i jobb, men også i stor grad i feks Open Source. En del av det å kommunisere bra er å bli forstått, men også det å gjøre det på en måte som er positiv for de rundt deg. Hvis du sliter med kommunisere det du gjør, tenker eller mener så vil du merke at det å jobbe som systemutvikler kan være frustrende. Å kontinuerlig jobbe med hvordan du kommuniserer muntlig og skriftlig er en veldig viktig det av det å drive systemutvikling. Det er også viktig å forsøke mestre både den uformelle (f.eks chat) og den mer formelle som går på å skrive dokumentasjon eller lignende. 

Empati

Du trenger å være empatisk og forstå de rundt deg. Systemutvikling er å løse problemer for mennesker (startsett, noen ganger å løse problemer for andre maskiner etc men ofte er det mennesker) og da er evnen til å sette seg inn i deres situasjon essensielt. Spesielt i løpet av de siste årene har dette blitt viktig, da teknologien vi utvikler direkte påvirker menneskers lov. Hvis vi som utvikler disse løsningene gjør det uten et snev av empati gjør vi livet til de rundt oss verre, ikke bedre. Systemer utviklet uten tanke på de det påvirker kan få fatale konsekvenser og kan være skillet mellom liv og død (se https://www.nytimes.com/2018/10/15/technology/myanmar-facebook-genocide.html). 

Oppsummert

Kommunikasjon og empati er viktige for å være en bra systemutvikler i tiden fremover. Det betyr ikke at selve faget programmering er uvesentlig og at de to egenskapene jeg nevner gjør at du ikke trenger utvikle den faglige siden av systemutvikling. Det jeg mener er at i tillegg til kunnskaper i faget må du ha menneskelige egenskapene for å være en god systemutvikler. Tiden da systemutvikling var en solo greie er over og kommer aldri tilbake (heldigvis). Ei heller vil tiden da vi laget systemer bare for lolz være det. Det vi lager påvirker verden og menneskene i den, og det ansvaret som ligger på oss som utvikler systemene skal vi ta på alvor.

Kortslutning Podcast har en episode om samme tema, sjekk den ut: “Må du være lidenskaplig opptatt av programmering for å bli en bra utviklar?”

Distribuerte produksjonsenheter er kommet for å bli – eller Remote Work FTW

Credit: https://www.flickr.com/photos/snowpeak/14351894398/

Jeg tok en sjanse i sommer, jeg gikk over i en jobb hvor jeg visste at jeg kom til å jobbe som del av et distribuert team i Vibbio. Resonnementet bak å prøve var at om det funker og jeg liker det kan det åpne nye muligheter for å gjøre morsomme ting i femtiden.

Jeg har en erfaring med å jobbe distribuert og det var under en oppsigelsestid hvor jeg var fristilt. Da jobbet jeg med en person i Seattle og vi klarte og levere det vi skulle. Riktignok varte dette bare ca tre uker. Etter det var planen å finne noe annet, det ble aldri noe av.

Å skulle jobbe distribuert uten å ha noen du kan bare snu deg til også snakke med var skremmende. Alle som har jobbet med meg vet at mitt behov for å snakke er der ganske hyppig (beklager..). Jeg har også merket at jeg liker mennesker og liker å snakke med folk. De gangene jeg har hatt foreldre permisjon har jeg snakket hull i hodet på de hjemme fordi jeg ikke har fått snakket. Så vi kan si at kona var minst like bekymret.

Antagelig jobber du alt distribuert

Jeg her nå gjort det en måned og har vel egentlig erfart at det å jobbe distribuert er ikke så ulikt å jobbe i en stor bedrift. Hvis du uansett bruker digitale hjelpemiddel for all dag til dag kommunikasjon så er overgangen til å jobbe distribuert liten. Om kollegaen er i en annen etasje, bygg eller land betyr lite. Eneste overgangen er at du ikke like enkelt kan kaste bort tid på å bare snakke med folk.

Veldig mange steder har tatt i bruke ting som Slack / HipChat eller lignende. De aller fleste styrer oppgaver og prosjekter via digitale løsninger. Hvis vi skal oppsummere så er det egentlig bare møter som må endres (og strengt tatt er vel det bare 100% positivt ettersom alle selskaper er elendige på å holde møter) til å bli digitale via videokonferanse.

Ikke nødvendigvis hør på alle råd

Hvis du får muligheter til å ta en jobb som har et distribuert team, så er det verdt å sjekke ut. En liten viktig ting er å sjekke at dere er i samme tidssone. Etter hva jeg har hørt er det en helt annen greie og kanskje ikke så chill om dere er ca på samme tidssone (selv om min første remote jobb var på tvers av tidssoner og var bra, så tror jeg det først og fremst var fordi vi var et team på to mennesker).

Hvis du leser på nettet om Remote Work er det selvsagt en mega industri som er veldig klar på at dette med å jobbe distribuert krever at du leser masse greier, kjøper bøker, handler inn kontormøbler, setter deg inn i hvordan du skal gjøre dette mega endringen. Det er litt som når du får barn for første gang og begynner lese alle tingene du bare  ha, men som du senere innser er fullstendig unødvendig.

Jeg kjøpte 37 Signals sin Remote: Office Not Required bok, som var nyttig og lese men kanskje mest nyttig for de som trenger argumenter for å begynne jobbe distribuert. Utover det har jeg ikke gjort noe. Dagene jeg er hjemme sitter jeg ved kjøkkenbordet (fordi det er ikke plass til noe kontor). Jeg har ingen spesiell rutine annet enn å levere unger dit de skal også få meg kaffe.
Folk er selvsagt forskjellige, men det er verdt å ikke lese for mye og heller bare prøve seg frem selv. Snakk med folk du kjenner og stoler på som har gjort dette alt.

Hva er anderledes?

En ting jeg merker veldig er at du må være flinkere til å formulere deg presist og kanskje bruke litt lengre tid på å utforme det du skal kommunisere. For meg personlig er det ekstremt positivt, da jeg kan være litt vel rask og noen ganger ikke helt være innforstått med at kanskje ikke alle vet alle detaljer jeg har i mitt hodet. Du merker at det å bare slenge ut noe på Slack ikke funker så bra. Tidligere har jeg gjort det mye, men da har jeg som regel tatt det “offline” rett etterpå for å liksom rette opp i ting som ble misforstått.
Jobber du distribuert så må du rette opp alt skriftlig også, noe som kan bli lange og tunge chat dialoger. Så jeg forsøker å bli flinkere til å komme med litt mer gjennomtenkte og velskrevne ting for å unngå lange chat tråder.

Dokumentasjon kommer automatisk, fordi du må formulert noe skriftlig for å gjøre noe. Dermed har du allerede før du begynner noe dokumentasjon og for å forklare dine intensjoner klart ovenfor de andre må du som regel skrive litt til når du er ferdig med en oppgave. Vanligvis kunne du bare reist deg opp også sagt “ey, jeg har laga noe kom å se” eller tatt det i lunchen. Distribuerte jobbing gjør at du er nødt til å ha en “papirsti” for at andre skal kunne forstå hva du holder på med.

Credit: https://www.flickr.com/photos/indi/3104247104/

Sjefer som er vant til å være “manager of chairs” vil bli helt åpenbart unyttige og være uten hjelpemiddel til å fortsette styre teamet på en gal måte. Å være på team hvor viktigste delen av jobben er å ha ræva si på en stol på et kontor er ikke gøy og ekstremt demotiverende. Ved å fjerne muligheten til å kalle “å se at folk er på jobb” ledelse så flyttes også fokus på hva det er som leveres av verdi. Det er ekstremt positivt og kanskje en av de aller største fordelen med distribuerte team.

Jeg merker at jeg må jobbe litt med min holdning / fremtoning i video møter. Hvis hele kroppen min og stemmen min utstråler “jeg vil gjøre noe annet, make it stop!!” så er det ganske dårlige signaler. I vanlige møter kan du rette dette opp med “koseprat” før / etter møtet, mens i videokonferanse får du liksom ikke det.

Konklusjon:

Å uttale bastant at dette er AWESOME etter rundt to måneder er i overkant naivt. Jeg vil si jeg er overrasket over at jeg liker det såpass bra allerede. Skepsisen jeg gikk inn i dette med er i ferd med å forsvinne. Jeg merker at friheten og ansvaret du får ved å jobbe distribuert passer med bra, kanskje varer det også.

0’er og 1’ere

Trondheim Developer Conference var stedet jeg valgte for å bearbeide følelser om noe som skjedde for seksten år siden. En Historie Om 0 og 1 er et foredrag hvor jeg forsøker å beskrive hvordan det var for meg å møte veggen og hva jeg ser som problematisk med dagens utviklermiljø. Hvorfor? Fordi vi som jobber med systemutvikling trenger å snakke om de vanskelige menneskelige tingene. Jeg håper at ved å fortelle min historie kan jeg hjelpe andre og kanskje hjelpe til å endre usunne holdninger som er i vårt miljø.

Uka før TDC holdt jeg en “dry run” av foredraget for mine kolleger i NRK noen dager før konferansen, mest fordi da slapp jeg å lage alt ferdig kvelden før. Det viste seg at det skulle bli noe av det vanskeligste jeg har gjort (minus minnetaler i begravelser). I det jeg skulle begynne kom det følelser jeg ikke ante var der. Etter foredraget hadde jeg en samtale som hjalp meg å få satt ord på veldig mange ting jeg ikke hadde klart selv. Å høre andre beskrive hvordan de følte det i en lignende situasjon,  og høre hvordan de opplevde det gjorde at jeg selv gravde opp en del ting jeg hadde lagt vekk. Selv etter så lang tid hjalp det å snakke med noen om hvordan dette var. På veien hjem fra jobb var hodet fylt av tanker og jeg var følelsesmessig helt utladet.

Jeg hadde aldri før satt ord på hvordan jeg følte det på den tiden, og det viste seg å være tøffere enn jeg hadde trodd. Det er seksten år siden og da det skjedde ville jeg vel bare videre. Bli frisk også fortsette å leve ut drømmen. Det var nok ting, som jeg ikke har satt ord på før nå, jeg burde ha bearbeidet. Men, jeg var ung og hadde ikke tid til slik. I tiden etterpå endret jeg ikke så mye. Det hendte jeg jobbet mye i perioder, men det var ting som var mulig for meg å mestre. Etterhvert ble jeg tryggere på meg selv og hva jeg kunne. Da begynte jeg å være strengere på jobbing. Mindre overtid og jeg brukte ofte min venn Chris’ sitat: “bad planning on your part, does not constitute a crisis on my part”.

Jeg er bare en som forteller min historie

Å snakke om ting, gjør noen ganger at folk tror du har en eller annen form for kunnskap de mangler. Jeg er overhodet ingen som kan noe om dette med utbrenthet eller hvordan fikse det. Det finnes smarte folk som du heller bør søke svar fra enn meg. Det eneste jeg vet er hva som skjedde med meg og hva som hjelper meg. Andre har sine historier og sine måter å jobbe gjennom det. Ikke ta min historie som noen fasit eller absolutt sannhet, men vær nyskjerrig og forsøk lese hva andre smartere folk kan si om disse tingene. Jeg ønsker bare å starte samtalen om tinge som er vanskelig. I håp om å gjøre det litt enklere for andre å fikse sin hverdag.

Rett etter og i tiden etter foredraget har jeg mottatt mange veldig hyggelige meldinger og hatt bra samtaler med folk. Å høre fra de som har vært igjennom det samme at dette var bra, betyr utrolig mye. Å se at folk vil anbefale kolleger og kjente å se det gjør meg takknemlig. Hver gang jeg holder denne typen foredrag tenker jeg i dagene før “hvorfor gjør jeg dette her!!??”. Tilbakemeldingene fra folk er svaret, å høre at du sa noe som ga mening eller hjalp er grunnen til å utlevere meg selv for alle å se.

Se EN HISTORIE OM ENERE OG NULLER fra Trondheim Developer Conference.