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 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.

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?

Woman holding phone taking picture of a lake

Om digital avhengighet

Jeg bestemte meg på sensommeren at jeg måtte gjøre noe med mitt forbruk av sosialemedier og telefonbruk. Først og fremst for å være et bra forbilde for barna mine, for hvordan kan jeg gi dem faste rammer om de ser jeg ikke klarer det samme?

Lol, jeg er’kke avhengig!


Du tenker kanskje du har full kontroll, men er du helt sikker? Har du sjekket Screen Time og sett hvor mange timer pr dag du bruker telefonen (og ikke kom med den “jammen jeg bruker den til jobb”, fordi det vet vi begge ikke er sant). Hvor mange pick ups har du pr dag? Blir du varslet 178 ganger om dagen? Svarene på disse spørsmålene vil være ubehaglig, men det er helt greit. Vi har alle vært der og det er veldig mange andre i samme situasjon. Familier, kolleger, venner har alle den samme utfordringen.

Denne teksten handler om hvordan jeg forsøkte jobbe meg gjennom min avhengighet og en del praktiske tips & triks som kan hjelpe.

Først: still en diagnose 👩🏼‍⚕️

A toy ambulance on top of a white wooden bench

Det aller første en bør gjøre er å stille en diagnose. Hvor ille er det egentlig? Dette er ikke noe du selv kan avgjøre, men heldgvis kan telefonen din fortelle deg hvor ille det er. Hvis du ikke har satt på Screen Time (eller tilsvarende på Android) så er det første ting du må gjøre. Den viser deg hvor ditt problem ligger.

Hvis du bruker den mer enn 3 timer om dagen, så har du en utfordring. Tar du opp telefonen mer enn 50 ganger i løpet av en dag har du også noe å jobbe med. Hvor ille det er avhenger av personlighet osv, men det viktigste er at nå har du et vekrtøy til å hjelpe deg.

Nå kommer litt mer praktiske tips, vipp ut telefonen og gjør deg klar til å gjøre det på din telefon.

Ta tilbake makten 💪

Jeg leste en del tips om hva man kan gjøre, mange av de er ganske åpenbare når man først tenker etter:

  • Slå av alle push varsler, utenom meldinger og telefon
  • Slå av “de røde badges” 🔴 som viser uleste meldinger eller lignende på appene dine.
  • Slå av alle Siri-greier som gir deg varsler om ting

Du har nå fjernet det som tvinger deg til å ta opp telefonen selv om den er i lomma eller ligger langt vekk. Dette gjør at du har, i teorien, makten over telefonen og ikke omvendt.

🎉Gjør telefonen kjedelig 🎉

Du har nå slått av en del av tingene som forsøker lokke deg til å ta opp telefonen, men det er bare starten. Du kan finne på å ta opp telefonen likevel, så da kan du gjøre følgende for å gjøre den opplevelsen litt mindre bra. Det handler om å ikke gi deg selv positive opplevelser eller assiosasjoner når du plukker den opp. Derfor må du gjøre opplevelsen av mindre morsom og innbydende.

  • Sett bakgrunn på lock og wallpaper til et bilde av en solid farge. Du ønsker ingen assiosasjoner som kan føre til at du kommer på noe.
  • Flytt alle applikasjoner vekk fra første skjerm. Ingenting skal firste når du åpner telefonen
  • På skjerm to skal du bare ha de aller viktigste appene som f.eks Yr, Google Maps, kalender, kanskje nettleser
  • Alle andre apper putter du i grupper og stuer sammen i en haug

“Jammen Espen, da finner jeg jo ikke appene?” Joda, du swiper ned også søker du de opp. Du finner alt du skal, men det gjør terskelen litt høyere og at du kanskje rekker tenke: “Nei, jeg skal ikke inn å sjekke katte videoer nå”.

Det er ikke den, det er deg!

Å gjøre alle tingene over hjelper deg til å ta kontroll og det gjør telefonen mindre attraktiv. Likevel gjenstår ett problem, som kanskje er det største problemet av alle: deg!

Du er det største problemet


Gjennom langtids bruk av smarttelenfon har du programmert hjernen din til å søke belønning hver eneste gang du: venter, kjeder deg, lurer på noe. Hver gang hjernen din merker du er i disse situasjonene ber den armen din om å fiske opp telefonen.

Du vil merke det, dersom du forsøker kjenne etter, når du venter på kollektivtransport. Hvor vanskelig er det ikke å la telefonen være? Hva gjorde du før når du ventet på bussen?

Du venter i bilen på at noen er inn å handler. Ungene er på trening og du venter på at de skal bli ferdig. Du skal på dass også tar du med deg telefonen (ikke nekt, vi gjør det alle sammen). Alle disse situasjonene må omprogrammeres i hodet ditt slik at det ikke er dopamin tid.

Gå drastisk til verks

Ingen av tingene over hjalp meg bli helt kvitt min avhengighet, jeg fikk relapser og jeg merket at hjernen min fremdeles tenkte: “kanskje sjekke Twitter?”. Jeg tok å fjernet appen fra telefonen min, så når jeg nå søkte den opp eller flyttet til gruppa der den pleide ligge. INGENTING DER!!

Det hjalp, så nå er jeg nede i kanskje et par ganger i en arbeidsdag hvor jeg sjekker Twitter. Jeg merker at det gir meg stadig mindre å være der, fordi uten jevnlig bruk så forsvinner verdien og magien.

Du la kanskje merke til på min homescreen at jeg bruker Firefox Focus, “hvorfor det?” tenkte du kanskje? Det er fordi det er en nettleser med ekstremt lite funksjonalitet! Det er ingen favoritter, ingen shortcut screen og ingen lagring av passord etc. D fleste operasjoner er litt krunglete og tar tid. Det er genialt fordi jeg må skrive inn adresser til nettsider jeg skal besøke (du får litt hjelp om du vil, men du må opp med tastaturet), hvilket betyr at terskelen for å bare surre rundt er litt høyere. Det skader heller ikke at du surfer med litt mer beskyttelse av privatlivet ditt i den nettleseren.

Vær oppmerksom👀

Hva mer kan du gjøre, vel det handler om å være litt bevist også ha en plan for hva du skal gjøre når du er i situasjoner hvor du vanligvis ville vippet opp telefonen.
Ha en plan for hva du skal gjøre når du venter eller kjeder deg. Tenk over hvilke ting du kan gjøre som likevel får tiden til å gå.

Lykke til 💪🔥✅