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.

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?”