Grey laptop on top of a patterned blanket in a dark room.

3 råd til å takle Arbeid Under Pandemi

Tweeten over ☝er et poeng som drukner i alle råd om “hjemmekontor” og “slik jobber du best hjemme”. Dette vi holder på med nå er ikke det samme som å jobbe remote- / distribuert, faktisk er det veldig langt unna og det glemmer mange av de som kommer med velmenende råd. Jeg har jobbet remote i ca to år og det som jeg gjør i disse dager er noe helt annet.

Å arbeide under pandemi (AUP) handler i stor grad om å takle det mentale stresset du er under. Dette er ikke noe jeg vanligvis må håndtere når jeg jobber remote til vanlig. Det å jobbe remote handler mye om frihet til å jobbe hvor du vil og når du vil. Jobbe under pandemi er noe annet, du har begrenset frihet til å jobbe hvor du ønsker og kanskje når du ønsker. Tingene vi vanligvis gjør for å kompensere for å jobbe remote kan en ikke gjøre i situasjonen vi er i nå.

Derfor vil jeg gi noen råd om hvordan arbeide under pandemi, fordi dette er helt ekstraordinære tider.

Råd #1 – ikke les nyheter mer enn en gang om dagen 🙈

Dette handler ikke om å ha hodet i sanden, men det lages så mye saker hver eneste dag om situasjonen vi er oppe i at om du følger med på alt så vil du bli helt utmattet. Ved å redusere inntaket av nyheter vil din mentale helse bli bedre, du vil klare fokusere mer på å gjøre jobben for arbeidsgiver og familien din.

Råd #2 – vis litt ekstra omtanke ❤

Min kollega Alexandre Leisse har mange bra råd og ett av dem er å skape sosiale arenaer hvor man kan hjelpe hverandre i en vanskelig tid. Dette er viktig i remote jobb til vanlig, men ekstremt viktig i den tiden vi er i nå. I dag er det en haug folk som må jobbe alene hjemmefra for første gang. Bor du alene ser du kanskje ikke andre mennesker hele arbeidsdagen.

Derfor er det viktig å sjekke inn med hverandre: “hvordan går det?”. “Trenger du et friminutt på video samtale?”. Vær litt ekstra raus og vis litt ekstra omtanke. Fordi dette er spesielle tider vi lever i akkurat nå.

Råd #3 – bruk AUP som en mulighet til å bli bedre på skriftlig kommunikasjon 💪🏼

Å fordype deg i noe som kan gi mestringsfølelse når du lykkes er en herlig ting å distrahere deg selv fra alt som skjer. Gå all inn og fordyp deg i kunsten å kommunisere via tekst. Være det seg ved å skrive e-post, dokumenter, chat meldinger eller noe annet.

“Bruk video, bruk video chat” råder mange deg til når du jobber hjemmefra. Jada, det er nyttig å ha “høy båndbredde” samtaler via video chat. MEN! Og dette er viktig. Men, det er et supplement til skriftlig kommunikasjon. I stedet for å bare “flytte kontoret over på video chat”, hva med å benytte sjansen til å bli bedre til å kommunisere skriftlig?

I stedet for å “jukse” med å kjøre video hele tiden, bruk heller denne muligheten til å trene på skriving og tekstlig kommunikasjon. Gi deg selv muligheter til å føle mestring i en tid hvor alt er kaotisk. En ekstra fordel er at du blir en bedre arbeider også etter alt dette er over.

Arbeid under pandemi har få likheter med å jobbe remote, ikke la det skremme deg fra å prøve det en gang i fremtiden ♥️

Espen D.
Black computer screen showing graphs in white text.

Three tips for acquiring a remote heart beat

When you are a member of a remote team, one of your most important tasks as an employee is to ensure everyone is able to see what you are up to. I have worked in a remote team for about a year and in semi-remote scenarios for an even longer period, therefor it is time to share some of my experiences on how to communicate progress (or lack there of).

There is some responsibility on whoever manages a team to ensure these things are working. There are however some things which has to be the responsibility of the individuals. This is what I will be discussing here.

Create your own remote heart ❤ beat 📈

Showing your team when you are working and how that is going is essential to getting a good team vibe. In order to get this feeling in a remote setting you need to generate a remote heart beat to show “proof of life”.

  • Actively use status flags in chat tools
  • Telling your story through the commit history
  • Show work that is not complete
  • When communicating progress (or lack there of) take the time to do it properly so people actually understand how things are going

📣 Yell it form the roof tops! 📣

The developer stereotype is that of the lone wolf working in silence only to emerge from the cave with The Ultimate Solution™!
In 2019 this way of working should be dead and only be told as a tale to scare your grand kids. As a developer you are expected to contribute to a team and ensure you move forward together. What this means is that the way you work needs to accommodate for the fact that you are not working in a vacuum. This fact becomes even more important when the team is spread out in different physical locations. Your way of doing your work needs to be louder in order for your team mates to get an insight into how things are going.

Keep the information flowing of information

Ever since the emergence of Git I have been a big fan of making many small commits, as opposed to committing large chunks at a time. Luckily a “commit often” approach is ideal for remote work. It automatically gives you a heart beat and it does enables you to communicate progress without status reports.

Take pride in committing

If you take the time to write a good commit message (this is very much an aspiration for me, it is not like I am very good at this!) a team member can read the days list of commits and get a decent overview of what’s happened the past day.

When completing something, ensure it’s communicated somewhere

Picture of a leaf forest in daytime with fallen trees on the ground in the sunshine.
Photo by Chelsea Bock on Unsplash

If a tree falls in a forrest” is a philosophical exercise which applies to remote work. When you fix a bug, it’s nice to others to know right? It is one thing to move the card in your task management tool of choice, however that is usually not something everyone in a company keeps a close eye on. When you fix a bug or complete a feature there are several things you could do when applicable:

  • Add a piece of documentation to the end user documentation.
  • Update the help pages FAQ / company blog / etc with news of the new feature or solved issue.
  • Notify your customer success team about a bug being fixed.
  • Humbly blog on your company communication tool of choice (mailing list, chat, whatever)

Take a screenshot or screen recording of a feature you have implemented and post it somewhere customer success and sales also see it. Remember, sales are only as informed as you make them. In order for them to do a better job, they rely on information from developers such as yourself.

Embrace showing work that is half done

Not everything you do as a developer is a commit and if that takes up most of your day, how do you enable others to see what you are working on? Taking the plunge and dare to show things which are not complete can feel a bit scary at times, but if you build a team culture where that is common it will be hugely beneficial for the entire team.

Develop skills in handling feedback on half-done work

As developers we talk a lot about feedback cycles and rapid responses to code that gets pushed into production. It is equally important to get early feedback on things which aren’t code.

Let’s say you are redesigning a form and you have just started on the task and you realize you are not quite certain what the interaction should be. You could implement everything and then get feedback or you could quickly create a sample implementation and create a videos which shows off what you have done.
Doing the latter you get rapid feedback with the added benefit of showing the rest of the team what you are working on. Having shown something early makes it easier for others to give quality feedback later on as they have a rough idea of what it is you are working on. Engaging in dialog early on when developing a feature is also time saving. A lack of context when talking about something is a common source of misunderstandings.

By showing off to your sketches, screen shots or small screen recordings you enable your fellow team members to get an insight into your progress. It’s also a nice way to bond the team and it is also an indication of a healthy team if members don’t feel intimidated by doing this.

Man with arms out saying something in front of an image

Så jævla enkelt å gjøre en lyntale!??🤷🏼‍♂️

Jeg hadde gleden av å snakke på årets Y Oslo konferansen. Denne posten handler om hvordan det gikk til, formålet er å vise at det er ulike måter et foredrag oppstår. Det handler ikke om å følge en mal eller oppskrift, fordi mennesker fungerer ulikt og det handler om å finne ens egen måte å gjøre ting på.

Veteranfaen, kommer og dreper alle samma
Bare bæsjer på dem, skriver mens jeg sitter på ramma
Bensin i kanna, svett i panna, fyrstikker i handa
Men jeg tenner ikke på meg sjæl selv om jeg blir forbanna
Blir forbanna, blir forbanna, jeg er sulten, jeg er sinna

“Loff” av Mae. Kilde: https://genius.com/Mae-no-loff-lyrics

Akkurat som Mae satt jeg på ramma og ble forbanna (Nesten da, jeg leste på Twitter, det er ganske likt det å sitte på dass egentlig. Det er 💩 overalt). Det var sånn det begynte. jeg leste om konferansen og 🔥ble forbanna🔥. Jeg rantet litt og det endte med at jeg i affekt 😡 sendte denne DM til Jostein i NetLife (arrangøren av konferansen):

Screenshot fra DM dialogen som startet resisen mot et fordrag

Jeg sendte etterpå en litt lengre versjon av ideen om foredraget, som var på ca 200 linjer. På dette tidspunktet hadde jeg ikke noen annen ide annet enn at jeg var forbanna på hele konseptet med en innovasjons konferanse.

Tida gikk og jeg glemte hele greia. Helt inntil det plutselig lander det en e-post fra Netlife i innboksen hvor det stod jeg var akseptert, jeg tenkte bare:

Å faen!

Meg da jeg leste e-posten om at jeg skulle holde foredrag på Y Oslo

Å gjøre ting instinktivt er noe jeg ofte gjør (litt for ofte vil noen si). Jeg har sendt inn utkast til foredrag mens jeg satt på ramma (bokstavlig talt, bare se bildet her hvor flisene fra vårt gamle bad vises). Fordi det handler om å agere på følelsene når de er de. Ikke analysere og rasjonalisere. Jeg handler uten å tenke noe mer enn at “dette har jeg lyst til”!

Utfordringen ved å gjøre noe uten å tenke det gjennom i særlig grader er at det ofte tar minst fire fem måneder fra en konferanse åpner for bidrag til du får bekreftelse. Ikke engang jeg klarer å holde på den forbanna følelsen SÅ lenge..

Hva var det jeg tenkte?

Tida fra jeg mottar et eventuelt positivt svar og til det nærmer seg deadline handler om å forsøke rekonstruere hva jeg tenkte. Enkelte ganger er det lett, andre ganger krever det ganske mye jobb å grave frem lidenskapen og tankene jeg hadde da jeg sendte inn. Samtidig som jeg irriterer meg over at jeg enda en gang har satt meg i denne situasjonen. Sånn var det også med denne lyntalen, hva i alle dager skal jeg si på tretten minutter?

Det e en vibe, det e ekstremsport

“Ekstremsport” av Myra. Kilde https://genius.com/Myra-no-ekstremsport-lyrics

Lyntaler virker kanskje enkelt, fordi det er kort tid. Likevel vil jeg si at det er ekstremsporten innen foredrag, fordi du har NULL rom for tvil eller nøling. Det skal sitte schmekk schmekk schmekk. Helst også med litt punch og kanskje litt humor. Lyntaler handler om å åpne opp fire fem ekstra knapper på skorta også forvandle deg til scenenes Tony Montana og tenke:

Al Pacino som Tony Montana i filmen Scarface

Hele verden er din, og alt som er i den

Tony Montana, Scarface

The Rules of Lyntaler is there are some rules actually…

Jeg lærte en gang at lyntaler alltid skal inneholde en påstand eller ett budskap. Aldri noe mer (en regel jeg faktisk brøt i min lyntale på Y Oslo hvor jeg hadde minst to 🤣). Lyntaler som er “korte foredrag” er i mine øyne feilaktig bruk av formen etter min mening. Du skal ha et budskap i en lyntale. Å holde en “erfarings lyntale” blir feil og bør spares til lengre formater.

O processo

Min prosess for å lage lyntaler er at jeg setter meg ned med PCen også skriver jeg ned foredraget jeg holder i hodet. Jeg transkriberer det som kommer til meg der og da. Dette gjør jeg en tre fire ganger også leser jeg gjennom også ser om det er noe som funker. Segmenter jeg føler begynner ligne noe plukker jeg ut til jeg har igjen nok. Deretter handler det om å sy sammen disse fragmentene til en historie.

Eventuelt så blir det å gå tilbake til start også tenke: “Hva er det egentlig som er budskapet jeg vil komme med?”. I forbindelse med Y Oslo slet jeg veldig med det, fordi jeg hadde innhold nok til 45 minutter i hodet mitt. Hva kan jeg koke det ned til som gir verdi på tretten minutter?

Jeg var skikkelig i tvil lenge, men heldigvis har jeg en kollega Alexandra som jeg kunne prøve ut ulike budskap på. Denne testingen gjorde at jeg etterhvert nærmet meg to hovedbudskap:

  • Innovasjonsbransjen er full av 💩
  • Det handler om å være komfortabel med å være ukomfortabel

Y Oslo hadde et opplegg som ikke passet min prosess. I det deadline for slides kom, hadde jeg ikke begynt på dem. Fordi jeg jobbet med å utforme scriptet for hva jeg skulle si, så da sendte jeg inn en text-fil 🙈🙉🙊

Helgen før hadde jeg noen timer til å snekre slides. Da pleier jeg å begynne med å lete på Unsplash etter noe visuelt spennende bilder mens jeg samtidig prøve å lage noen punchy ord eller setninger til å hjelpe meg å huske.

Øve øve øve øve

Det er ikke alltid jeg øver særlig om det er lengre foredrag. Jeg går gjennom de i hodet og visualiserer, men jeg fremføre sjelden. Denne gangen gjorde jeg det en del, fordi det var på Engelsk. Min første lyntale på engelsk og jeg var egentlig ganske nervøs. Jeg hater selv når folk knoter det til med dårlig språk og mye ståttring. Det ble mye finsliping av speaker notes (du vil se i videoen at jeg bruker de en del, jeg skylder på nerver) også holdt jeg en gjennomgang for de som hadde tid i VIBBIO via Google Meet.

 where I was doing a dry run of the talk with my co-workers hanging out
Practicing before my co-workers

Resultatet

Slik gikk det.

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.