two men hugging in what looks like a dance floor

“Du får ikke venner på jobb”

Jeg hadde en sjef som sa dette en gang som et velment råd. Den gangen reagerte jeg og tenkte: det var da et jævlig dårlig råd og en pussig ting å si. Grunnen til at jeg syntes det var pussig, var fordi jeg hadde vært så heldig å blitt kjent med folk i jobbsammenheng som jeg vil kalle mine venner. Antagelig sa det utsagnet med om stedet vi jobbet og om personen som sa det.

“Er det bare meg eller er..”

Jeg har jobbet som utvikler i over tjue år og er det en ting jeg har hatt ekstremt god bruk for så er det disse vennene jeg har fått gjennom jobb. De som jeg ringer for å sjekke: “Er det jeg som er teit eller er det vi prøver å gjøre på jobb helt idiotisk?”. “Vi tenker på å innføre X og jeg tenker det er helt hjernedødt”. “Sjefen min sier jeg skal få personalansvar, hva faen gjør jeg?”. “Selskapet tilbyr opsjoner over lønn”. “Jeg trenger en ny jobb, jeg blir gal her!!”. Dette er spørsmål jeg har stilt selv og har hørt andre si til meg gjennom årene.

Særlig i roller hvor du har en form for utvidet ansvar, og ikke kan diskutere alt med de rundt deg på jobb, er det ekstremt viktig å ha noen “som vet hva det går i”. Du trenger de som kan hjelpe deg å ikke bli gærn. Å ha noen å spørre som ikke er i samme selskap, men har erfaring fra lignende situasjoner, er ekstremt nyttig. De kan hjelpe deg å navigere utfordrende situasjoner og kan dele av sine erfaringer. Dette er ikke alltid like lett å få til om du jobber i mindre selskap for eksemple.

Det å ha folk du vet du kan stole på og some du vet gir deg ærlig feedback, er uvurderlig for å ha en lang karriere i IT bransjen. Du vil komme borti situasjoner hvor du vil trenge denne gjengen for å hjelpe deg forstå situasjonen du er i. Du vil ikke alltid kunne spørre dine “vanlige” venner eller livspartnere om de samme tingene, da de “ikke har vært der”. De har ikke nødvendigvis de samme referansene og forstår helt hva du snakker om. Derfor er disse vennene du kan være så heldig å finne så viktige. Slik som rappere fra Bergen sier: “de som vet, de vet”.

Finner du en, så ta var på dem

Rådet mitt er ikke at du skal aktivt gå rundt å forsøke bli venner med alle du jobber med eller noe sånt. Det jeg råder deg til er å være åpen og mottagelig for at kanskje er det noen av de du møter som er verdt å gi sjanse til å bli en venn. Hvis du klarer det så er det noe både du og den andre personen vil ha glede av i lang tid fremover. Disse vennen kan være de som trekker deg opp av dype daler. Det er de som hjelper deg stå i stormen og jobbe gjennom utfordringer. De har ryggen din uansett hvor mye det stormer rundt deg. Jeg har skaffet meg noen sånne og jeg er så takknemlig for at de er mine venner. Uten dem ville jeg ikke vært den personen jeg er i dag. Jeg trenger ikke snakke med dem hver dag, hver måned eller alle år. Men! Jeg vet at om jeg sender en DM så vet jeg de vil hjelpe meg om de har mulighet.
Det er folka som gir deg din neste jobb, gir deg anbefalingen du trenger og som kan hjelpe deg på en realitestsjekk som gjør at du kan utvikle deg.

Vær en venn!

Du bør også være åpen for å være den som andre kan støtte seg på. Vær den som stiller opp når noen trenger å “få blåst ut” litt frustrasjon, still opp om noen vil du skal være referanse, osv. Ta den kaffen eller videosamtalen som gjør at kollegaen din finner ut hva som er riktig ting å gjøre. Det koster deg antagelig ikke mye og det kan vise seg å bety mye for begge. “Si hei, være en venn. Bli med!” som det heter i sangen.

Photo by Thiago Barletta on Unsplash

Picture of a forrest with snow and a lot of branches everywhere

The hidden meaning of complexity in the context of software development

Complexity is on the one hand something which can be measured by tools to give an objective value of how complex something is. However, this is not how I’ve come to see the word used in my work as a software developers. In this article I will talk about some of the aspects tucked away in the concept labeled complexity.
It tends to be used to cover up subjective opinions or believes getting portrayed as objective observations. Being able to detect when this happens is an essential skill to ensure you are able to no loose your confidence in your own abilities.

Fear of the unknown 👻

Image of a dark hallway with lights coming out from two open doors leaving two strips of light in the image.
Photo by Kamil Feczko on Unsplash

In my early days as a developer I worked as a contractor on a project for a client where we where hired to get a project over the finish line. They where facing a deadline and needed some people in to product. This was a Microsoft based architecture and it was in the years just after ASP.NET was released. Upon entering the project we learned about the guiding principles by the clients own architect. What we hear left us a bit puzzled as the way in which we where expected to go about coding components and pages went against everything we thought was right. Essentially we had to write our web application as if we where stilling concatenating strings in Perl, but in C# on the .Net platform. We where only two fairly young programmers from our company at the time, but we both thought this looked funny.

We tried to advocate for ASP.NET actually being a productivity enhancement and something which could help us reach the milestones with less effort. Especially since what we where making was a booking calendar solution, which would be ideal for the built in calendar components in ASP.NET. We tried to advocate this and show how it would make things easer, more robust and reduce our time to market. The architect was having none of it. Presenting reasons such as performance and complexity for reasons to keep the current pattern of development.

In reality it turned out to be fear of loosing control and fear of the unknown which lead us to having to implement a solution which was far from ideal and which ended up consisting of way more code than was needed. Writing the calendar booking component in a “Perl-style” was in an objective analysis far more complex and added may more code paths to the solution than the one we presented using the ASP.NET controls. What was diguised as something too complex, was in reality something new and unknown for one individual.

More advanced does not always mean it is more complex

Knowing everything about all different software libraries and frameworks is really hard. Therefor it quite often happens that there are different levels of experience in a team. Developers who’s spent more time with a certain piece of software will know different patterns of how to solve certain things than the novice just learning it.
In cases like this the seasoned practitioner could be faced with their solutions being “too complex”. What the person uttering this often should have said is this: “I was not aware this was a way go about solving this problem. Could you please tell me more”. Figuring out how to best leverage a framework or library takes practice. Especially senior developers are quick to jump to the conclusion of something being “too complex” because they don’t understand something or lack the practice in this particular framework or library.
When encountering this, it’s important to outline how the statement of something being “too complex” is false, it’s just a matter of a more advanced usage of the software we use.

I remember being thought this lesson as a young developer with the attitude and failures of many other young developers: I knew it all. Luckily I had a patient teacher in Per Otto who had the patience and skills to learn me new things. Where I previously would just “hack together” some code, he introduced me to the Gang of Four patterns as a way to more elegantly solve some problems. What looked liked something needlessly complex for me without knowledge of them, turned out to be elegant ways to solve common problems with fewer chance of errors.

Not to my personal taste

Man appearing to be outside is licking on a deadly mushroom.
Photo by Anton Malanin on Unsplash

I have on a few occasions opted to use a framework called Hapi for writing HTTP based APIs in NodeJS. This is not the de-facto option which most developers use (which at the time of writing is Express), but it has some traits I personally really like. With few exceptions the choice of Hapi is always scrutinized by developers accustomed to Express, as they are developed with two totally different philosohpies. Where one is about freedom of choice and providing few opinions in how to do things (Express) and the other is all about making decisions and laying out a preferred path as to how to use the framework to get the most out of it (Hapi).

Being introduced to Hapi is always a bit of a hurdle as there are conventions and ways to do things you just have to accept. If you don’t you will only spend a lot of time fighting a fight you will loose in the end. Most developers opt to follow the path outlined by the author, while others choose to fight the premises on which the framework was authored on every single occasion.

The concept of plugins is central to Hapi and seasoned users of the framework tend to rely heavy on building their solutions as a series of plugins. This concept does not exist in Express and the introduction of writing a piece of domain specific code as a plugin is often met with utterances such as “it is too complex” or “this adds needless complexity to our app”. What I think they actually mean to say is that “this is an unfamiliar approach to solve this issue” and instead opt to solve the problem at hand in their usual manner instead of using the mechanisms built into the framework to solve these things.

What is deemed complex by someone not familiar with the framework, is viewed as an elegant and preferred way by those with more experience in the framework. Writing a Hapi plugin does require some more knowledge, but it follows the architectural patterns outlined by its author.

🎬 In closing

Be on the lookout for the word complexity being thrown around in technical discussions. Much like other powerful words such as performance and security, it is often used to disguise something else.

There are of course some solutions, frameworks and technologies which are more complex (Hello 👋🏼 container managed persistence with EJBs in the Java stack of early 2000s), so there are situations where the argument of something being too complex is appropriate.

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

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.

A brown cow looking towards the camera with one eye.

Detecting bullshit 🚨

I remember when I first read How To Detect Bullshit by Scott Berkun, I was mesmerized that someone was able to articulate this so well. Throughout my career I have referenced this article to my coworkers. Today, more so than ever before, being able to detect bullshit is one of the most important skills you can have working as a programmer.

An endless stream of bullshit

There is an endless stream of bullshit flowing all over social- and traditional media at any given time. Previously it was not so constant and all consuming, but today you will encounter countless situations where the skill of bullshit detection is required.
If you fail to acquire this skill or do not practice it, you will end up making flawed decisions, make bad choices and maybe you even end up loosing your job over it!

Having a finely tuned bullshit filter is something that requires persistence in this day and age. If you do not force the filter to be applied to all information everything you consume, it will wear you down and you will be one of those people who’s only capable of reiterating something somebody else came up with.

I would argue that in all positions bullshit detection is essential. Obviously it is vital when being in involved in hiring processes. However you need to apply the same filter when working as a programmer and sysadmin. We are all bombarded with trends, hypes and promises of a new silver bullet every single day. A finely tuned bullshit filter is essential to be able to pick out the few important pieces that pass before your eyes during a day. Without it you’ll quickly feel exhausted and get a feeling you are not keeping up.

It only takes one question:

One of the first items in Berkun’s article is this, asking the question:

How do you know what you know❓

It sounds pretty easy, but once you focus upon asking this question every single time someone makes a statement, you will be surprised how often the answer will not be satisfactory.

Always be alert 👀

Let’s say you are visited by someone who’s portrayed as a thought leader in innovation. The first question you should ask yourself should be:
How does this person know what it claims to know?

In an argument with a fellow programmers when someone makes a claim that “X is superior to Y”, your first question should be:
How does this person know this?