Sådan bliver du mere kode-produktiv: Brug en mindre skærm

Du vil gerne ind i ’zonen’, hvor du er 100 procent fokuseret, kodelinjerne sprøjter ud, og tiden flyver afsted.

»Pludselig kigger du op og opdager, at det er blevet mørkt, du er sulten, og alle dine kolleger er gået hjem. Sådan er det at være i zonen – det er et godt sted at være, som jeg selv elsker,« fortalte den selvstændige udvikler Mark Seemann i sit oplæg på Warm Crocodile Conference, der finder sted i København onsdag og torsdag.

Problemet er, at det ikke er nemt at ramme den mentale tilstand – især ikke på arbejdet, hvor der tit vil være forstyrrelser. Og af samme grund kan en erfaren udvikler faktisk være mindre produktiv end de nye, unge håb.

Det kan hænge sammen med antallet af afbrydelser, forklarede Mark Seemann, for de nye på holdet får i højere grad lov til bare at sidde og kode for sig selv i et hjørne.

»Så ved du ikke så meget, som andre har brug for at vide, så de har ingen grund til at afbryde dig. Men når du bliver mere erfaren, finder folk ud af, at du ved noget, og som team lead er det dit job at blive afbrudt hele tiden. Så må du se, om du også kan nå at skrive noget kode indimellem,« sagde han.

I mange åbne kontormiljøer er det blevet almindeligt at bruge hovedtelefoner, hvis man vil lukke støjen fra de andre ude og koncentrere sig. Så kan folk se, om det er et godt tidspunkt at spørge dig om noget – bortset fra at nogen vælger at have hovedtelefonenerne på hele tiden. Så bliver de afbrudt alligevel, pointerede Mark Seemann.

Små skærme giver pænere kode

Han havde tre råd med til at få produktiviteten i vejret, hvor det første var lidt kontroversielt: Drop de store skærme.

Det meste af tiden, når man udvikler, handler nemlig om at læse kode – både egen kode og mange andres – så hvis man hurtigere kan læse og forstå koden, er meget vundet. Og her bliver det typiske udvikler-setup med to 24-tommer-skærme hurtigt en sovepude, lød Mark Seemanns teori.

»De fleste har flere store skærme og tror, det gør dem mere produktive. Men mit tip er: Brug en mindre skærm. Jeg koder på min bærbare computer med en 13-tommer-skærm, og det fungerer faktisk ret godt,« sagde han.

Finten er, at det at skrive kode på en lille skærm får udvikleren til at begrænse sig, og dermed skrive mere overskuelig kode, der er nem at læse senere hen.

»Jeg har to vinduer åbne på min skærm, og så har jeg en regel om, at der højst må være 80 tegn i hver kodelinje, og at funktioner ikke må være for lange. Min skærm motiverer mig til at dele det op i mindre bidder, som er nemmere at læse,« forklarede Mark Seemann.

At arbejde hjemme er også blevet udbredt – så kan man også undgå forstyrrelser og sidde alene og komme i zonen. Det er i hvert fald folks forventning, men det kan hurtigt gå helt anderledes.

»Det med ikke at blive forstyrret derhjemme virker ikke ret godt, hvis man har familie. De har meget svært ved at forstå, at du arbejder. Og selv hvis de ikke er hjemme, vil de bede dig gøre alt muligt, fordi du er derhjemme,« lød Mark Seemanns egen erfaring.

Han arbejdede dog stadig hjemme nogle gange, men det var af andre grunde, ikke fordi han forventede otte timers uforstyrret arbejdstid.

Forgreninger er ikke ondskab

Et meget større boost i produktiviteten giver det at skifte til værktøjer som Git, der gør versionsstyringen af koden distribueret, så folk kan sidde og arbejde på deres del af koden lokalt, og så smelte det sammen med master-kodebasen, når det er helt klar.

»Det er meget bedre end et centralt system. Hvis I ikke bruger det, så skynd jer at bede chefen om det og fortæl, at det er vildt, så meget mere produktive, I kan blive med det,« sagde Mark Seemann.

Han pegede på flere fordele, blandt andet at man med branching kan fremstå som et geni, fordi man først laver alle fejlene lokalt, før man endelig til sidst sender ny kode ind i fællesbasen – uden spor af alle omvejene, der førte dertil.

»Man siger, at branching (forgrening, red.) er det onde selv. Men branching gør det muligt at omskrive historien og programmere med trial-and-error, i stedet for at analysere koden til døde. Du kan prøve forskellige ting af, gå tilbage hvis det ikke virker, og så finde den rigtige løsning. Så branching er slet ikke ondskab,« sagde han.

Rådet var hele tiden at lave check-ins og committe koden, så man aldrig er længere end fem minutter fra et check-in. Det gør det nemt hele tiden at gå tilbage i tiden.

Problemet med at folk arbejder med forgreninger af master-koden er at få det hele smeltet sammen igen, og det kan være et helvede, hvis man står med store stumper kode, der skal splejses. Hemmeligheden var at gøre det ganske tit, også selvom en kodestump ikke er helt færdig.

»Hvis du merger ofte, er der ingen konflikter overhovedet. Og gør det, selvom opgaven ikke er helt løst endnu, for det er et mindre problem end et merging-helvede. Så kan du have en feature-toggle, hvor du indikerer, hvilke funktioner der er klar til brug, og hvilke der ikke er,« lød rådet.

Gå ikke i bad

En anden faktor, der spiller ind, hvis man vil holde sin produktivitet oppe, er motivation. Bliver opgaverne for lette, kommer man aldrig ind i ’zonen’, for det kræver en udfordring af hjernen. Og mister man den begejstring for at kode, man havde tidligere, gælder det om at komme ud og lære noget nyt – måske et helt nyt sprog.

Endelig var der det ultimative råd, der ville sikre mod afbrydelser: At holde op med at gå i bad.

»Så vil ingen opsøge dig og afbryde dig. De kan dog stadig ringe til dig. Og du kan arbejde hjemme helt alene, for hvis du ikke tager bad overhovedet, får du nok heller ikke en partner og en familie,« jokede Mark Seemann.

Udviklerkonferencen Warm Crocodile Conference kører den 15. og 16. januar i Empire Bio i København. Version2 er mediepartner for konferencen.