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?

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? 


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. 


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


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

Det å presentere

Jeg var så heldig å få lov til å snakke om noe jeg virkelig synes er spennende på årets JavaZone, nemlig mine erfaringer fra å forsøke skape den nye typen sosiale musikkspiller i foredraget: “How we blew our shot at beating Spotify, spending two metric truckloads of cash doing it”.

En takk går til programkomiteen som lot meg slippe til med et tema som kanskje er litt utenfor, men som likevel så ut til å være spennende for mange. Personlig trodde jeg at det enten ble meg og noen gamle kolleger som kom dit, men det var utrolig gledelig å se et pakket rom. Det var utrolig spesielt å snakke foran en tydelig engasjert gjeng som også stilte en rekke veldig bra spørsmål etter jeg var ferdig, så tusen takk til dere som kom.

Det å presentere

Veldig mange sier at det å holde foredrag handler 80% om det å presentere og 20% om innholdet. Jeg er veldig enig i dette, hvis ikke den som står på scenen faktisk gir av seg selv og forsøker å gjøre det spennende for de som hører på så burde egentlig hele salen gå. Personlig gjør jeg dette veldig ofte, klarer ikke den på scenen å skape en kobling med de som hører på så kan du heller lese slidene etterpå eller se videoen. Du får ingenting ut av å sitte der.

Selvsagt er det utfordringer ved å fokusere mye på hvordan man presenterer, fordi det er ikke alle som da klarer å få med seg hovedbudskapet. Dette forstod jeg da jeg så artikkelen Slik tapte vi for Spotify på digi.no, hvor journalisten hadde valgt å fokusere på de tabloide utsagnene som ikke var en del av hovedbudskapet som gikk på innovasjon og det å starte opp selskaper. Det er selvsagt nyttig erfaring å ta med seg videre og forsøke gjøre det slik at enda fler får med seg det viktigste. Heldigvis var nok journalisten i mindretall, for jeg fikk mange gode tilbakemelding på nettet og fra folk som var i eller hadde jobbet i oppstartsfirma at jeg hadde noen gode poenger.

Hvordan jobbe med presentasjon?

Det er mennesker som skriver bøker om emnet og holder foredrag om nettopp dette. Personlig så har jeg ikke lest noe særlig av slike ting, fordi jeg har en enkel filosofi: Jeg holde kun foredrag om ting jeg bryr meg om.

Dersom jeg skulle holdt foredrag om andre ting, ja så kanskje hadde jeg hatt behov for en metode eller lignende for å komme frem til en presentasjon. Kanskje hadde jeg måtte øve mye og trent på hvordan levere ting. Gitt at jeg alltid snakker om noe jeg brenner for eller som jeg er veldig engasjert i så har jeg ikke behov for noen metode for å komme opp med foredraget (ok, kanskje avsnittene nedenfor kan regnes som en metode, hva vet jeg). Det bare kommer av seg selv, fordi jeg har noe å si.

Til årets JavaZone brukte jeg i underkant av ti timer på å forberede foredraget. Det gikk med litt tid til å få slidene til å matche musikken på introen, men til å sette opp selve foredraget så brukte jeg lite tid. Siste uka før konferansen begynte jeg å sette opp selve presentasjonen. Før det hadde jeg satt opp noen mind maps hvor jeg hadde lagt inn hoved poengene og utover det foregikk forberedelsene i hodet mitt. Jeg føler at det er bedre å gå å gjøre presentasjonen i hodet en del ganger, visualisere hvordan det skal gjøres, fremfor å begynne å hacke ting inn i slides.

Å lage slides er like kjedelig som å skrive manuelle test script

Å lage slides er, for meg, en svært lite kreativ prosess og noe jeg forsøker å bruke minst mulig tid på. Det er som når man skrev stil på skolen og måtte føre inn med penn (ja, så gammel er jeg at jeg ikke kunne levere stil elektronisk). Oppsett av slides er å føre inn for meg, kjedelig men nødvendig likevel. Jeg gjør det slik fordi jeg vil ha mest mulig frihet til å tenke på hvordan ting skal leveres på scenen så lenge som mulig. Det å sette opp slides gjør ting veldig endelig og det er mye jobb å rette opp i ting etterpå. Ved å ha mind maps og ting i hodet så er det ekstremt lett å gjøre justeringer :)

Det eneste som jeg pleier å øve på er introen. Den aller første setningen må sitte og der er det etter min erfaring veldig dumt å ta det på sparket. Kommer du skeivt ut allerede i det du sier hva du skal snakke om, så kan det fort gå bare nedover fra der. Derfor sørger jeg alltid for å ha helt klart for meg hva første setning er. Alt etter det tar jeg på sparket. Å gjøre selve foredraget er noen ganger litt sånn ut av kroppen opplevelse. Det har hendt at jeg har blitt både overrasket og flau når jeg har sett meg selv på video etterpå fordi jeg trodde virkelig ikke at jeg sa det.
Jeg tror at om jeg hadde øvet inn alt jeg skulle si, så hadde ikke foredraget blitt noe bra. Alt jeg øver inn er første setning og etter det ser jeg bare på flyten i presentasjonen og at det er en bra historie som fortelles. Det er langt viktigere at slidene danner en bra ramme som jeg bare kan snakke ut i fra uten å ha trent inn noe.

Sannelig virker det som jeg har en metode likevel når jeg leser dette her, men jeg tror ikke jeg vil anbefale noen andre å følge den. Finn ut av hva du må gjøre for å føle deg trygg når du skal levere noe også gjør du det. Ikke les en bok eller hør på sånne som meg. Lag din egen måte å gjøre det på, så kommer det helt sikkert til å være veldig mye bedre enn å adoptere andre sine metoder. Dette gjelder ikke bare det å gjøre presentasjoner, men også ting som blogg innlegg. Skriver du fra hjertet om noe du brenner for så blir det stort sett bra og folk skjønner det. Ikke hør på en eller annen “kjendis blogger” som skal fortelle deg hvordan du skal gå frem for å skrive blogg. Det er egentlig veldig enkelt: Har du noe på hjertet, så skriv det. Hvis du ikke egentlig har noe å melde, vel så la være å skriv det blogg innlegget. Vi trenger virkelig ikke flere innholdsløse blogger på nettet :)

Kjære konsulent med fin tittel, kom deg ned av scena!

På JavaZone er det ekstremt mange konsulentselskaper som ønsker å profilere seg og det har hjulpet konferansen til å vokse seg til å bli en av de største. Problemet med dette er at de samme selskapene tvinger folk som aldri burde stått foran et publikum til å holde foredrag fordi de har en tittel som tilsier det. Jeg har en bønn til alle dere som tvinger i utgangspunktet veldig dyktige mennesker til å gjøre noe de åpenbart ikke er skikket til. Du bør settes foran et publikum bare fordi du er flink, du skal være foran publikumet fordi du klarer å formidle et budskap. Å kunne lese opp dine egne slides holder rett og slett ikke.

Det handler om å levere

Jeg konstaterte på at det var noe murring om nordmenn som ikke snakket på engelsk og slike ting. Det er godt mulig de snakket om meg også her, for jeg hadde tittel og slider på engelsk men snakket på norsk. Hvorfor gjorde jeg det? Først og fremst av respekt for de som kommer å hører på. Nå tenker du kanskje at det var en rar ting å si ettersom det kan være noen som ikke forstår engelsk i salen. Jeg mener det er bedre å faktisk være i stand til å formidle noe til 80-90% av salen, fremfor å stå der å stotre på håpløs engelsk og bruke all energi på å forsøke å huske hva faen det var du skulle si. Flere foredrag jeg så på JavaZone var på såpass dårlig engelsk at jeg strengt tatt tror de engelsktalende hadde problemer med å forstå det likevel. I tillegg så var det folk som jeg vet kan holde bra foredrag som fremstod som ubrukelige fordi de ikke gjorde det på sitt morsmål.

Derfor mener jeg det er en respektfull ting å gjøre å faktisk innse at, nei jeg kommer ikke til å klare å levere en bra presentasjon som engasjerer de som hører på om jeg gjøre det på engelsk så jeg gjør det på morsmålet mitt. Da er det i vertfall en viss kvalitet på det jeg gjør og jeg kan skape den stemningen jeg ønsker. De som ikke forstår norsk kan forlate salen og heller se på slidene, eventuelt snakke med meg etterpå. Jeg skulle selvsagt ønske at jeg hadde tid til å øve tilstrekkelig slik at jeg kunne gjort foredraget på engelsk, men det var ikke mulig i år. All respekt til de som gjorde det og klarte det bra, dere er mer dedikert og flittig enn meg :)

Enkelhet, ikke så enkelt

Dette er en artikkel i kategorien refleksjon og det kommer som et resultat av det jeg har erfart i de siste årene hvor Smidig-bevegelsen virkelig har blitt allemannseie. Jeg har både vært team medlem, Scrum Master, arkitekt og delvis produkt eier i ulike sammenhenger. En ting har alltid ligget å ulmet i bakhodet mitt de siste årene og det har med begrepet enkelhet eller simplicity.

Begrepet brukes til veldig mye rart og har blitt en viktig ingrediens i alle dokumenter om visjoner og strategier. Alt skal være enkelt. En annen setting hvor enkelhet nevnes hyppig er i diskusjoner rundt konkrete løsninger. Her brukes begrepet ofte som hersketeknikk hvor den som kommer med “men det er jo ikke enkelt” eller “det er unødig komplisert” forsøker å parkere andre forslag. Det er i denne andre konteksten hvor det hele tiden har skurret i hodet mitt. Veldig ofte bruker man begrepet enkelt på en måte som tilsier at noe skal være banalt eller simpelt. Løsninger som involverer teknikker eller noen biblioteker blir ofte merket som kompliserte (ofte med unødvendig som prefix).

Enkelhetens lover

Enkelhet kan oppnås på mange måter, hvor en av de er å redusere og fjerne noe. Dette er grunntanken de fleste forbinder med enkelhet, men etter å ha lest John Maeda sin The Laws Of Simplicity ble jeg klar over at dette er bare en av veldig mange teknikker som kan brukes til å oppnå enkelhet.

Maeda oppsummerer enkelhet i ti lover som kan brukes i et arbeid med å oppnå enkelhet i løsninger. I det daglige hører jeg stortsett snakk om å oppnå enkelhet gjennom Lov 1: Reduser. Det er selvsagt en viktig teknikk for å oppnå enkelhet, men den er overvurdert særlig i forbindelse med å løse problemer som oppstår under systemutvikling. Dersom det er en problemstilling som ikke er triviell, så er det faktisk slik at det er en del andre lover som faktisk gir bedre resultat enn bare å redusere kompleksitet og å “dumb it down”. Organisering og kunnskap fører veldig ofte til enkelhet i løsningen, på tilsvarende måte som loven om å redusere.

Simplifisering mer enn bare å redusere

Hvis du må lage et rammeverk for å utøve f.eks mapping fra ett objekt til et annet, så kan det gjøres enkelt dersom du sørger for at rammeverket er godt organisert og hvis du sørger for å la de som skal bruke det få økt kunnskap gjennom eksempler og dokumentasjon.  Veldig mange vil si at å lage et rammeverk strider imot det å gjøre noe enkelt, men det blir for enkelt mener jeg. Et godt skrevet rammeverk som er testet og skrevet brukervennlig vil jeg si er essensen i enkelhet. Du gjør en ofte utført operasjon enkel for flere. Hvorvidt det ligger avansert kode i rammeverket er egentlig uinteressant. Ingen stiller spørsmål rundt hvorvidt Spring rammeverket bruker noe avansert for å oppnå det de gjør. Hvorfor skal man i prosjekter måtte gå kanossagang om man ønsker å benytte seg av noe som av enkelte oppfattes som avansert?


Enkelhet består ikke i å fokusere på reduksjon eller bare å se på tidsbesparelser. Evnen til å vurdere flere av lovene slik at de balanserer hverandre ut som er nøkkelen til å oppnå enkelhet.

Det viktigste er likevel å innse at for å oppnå enkelhet kreves mer enn reduksjon. Hvis du synes utvikling av web applikasjoner er vanskelig med Java verdens mange rammeverk, så blir det ikke bedre av å redusere alle slike å bare bruke servlet klassene. En slik drastisk reduksjon er ofte fundert på en tanke om enkelhet, trukket altfor langt. Ofte bunner slike på manglende kunnskap eller behov for å bevise noe, som begge er krefter som trekker i retning av “dumbing down”: ikke enkelhet.