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

Det giver bedre kode og produktivitet, hvis du skrotter dit setup af store skærme. Sådan lyder ét af rådene til at blive en bedre udvikler.

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.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (24)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Pelle Söderling

Alle undersøgelser peger i retningen af at mere skærmplads giver bedre produktivitet og det siger sig selv at det er meget lettere at teste sine løsninger når man kan have vinduerne side-by-side end når man er nød til at skifte frem og tilbage mellem vinduer og konstant mister overblikket.

24" skærme er desuden håbløse - her får du ikke rigtig nogen gevinst fordi de typisk kun kører 1920x1080 opløsning.
Man ønsker minimum 27" skærme så man får 2560x1440 opløsningen.

Hvis man ikke kan finde ud af at styre den ekstra plads og det resulterer i at man ender med at skrive meget lange kode-linjer så virker det ærlig talt som noget af en brute-force løsning at skifte til en mindre skærm og opløsning - hvis man ikke har diciplin nok til det så har man formentlig andre og langt mere alvorlige problemer i ens kodestil.

Jeg har været vant til at arbejde fra 2 x 27" skærme, men har pga. rejseaktiviteter i udlandet de sidste 2 år været tvunget til at arbejde fra en laptop og selv efter 2 år føler jeg mig stadig klaustrofobisk i dette miljø - der er alt for lidt skærmplads til at jeg kan arbejde lige så effektivt som jeg er vant til og jeg ser frem til den dag hvor jeg igen kan få mig et sådant setup.

Claus Jacobsen

Jeg tror faktisk han har ret - Læg mærke til at han ikke bestrider produktiviteten. - Men det er jo så her vi skal have defineret produktivitet. Det han skriver er at med en mindre skærm får man et mere fokuseret blik og det skulle så give en BEDRE kode. Ikke mere, men bedre kode. - Jeg har set masser af eksempler på "produktivitet" - og ja, nogle gange så havde de været så produktive at tingene skulle laves om igen. Det er ikke kun indenfor programmering at de ting gælder. - Det er jo sjovt nok også derfor at "distractionfree" applikationer til at skrive tekster med er blevet så populære. Man skriver bedre når man ikke bliver forstyrret af alle mulige ting der blinker og blipper og båtter. - Det er også derfor at "hardcore" webdrenge sværger til notepad og ikke visual studio. (for lige at finde et "kontroversielt" sammenligningspunkt, for det gør de vist ikke mere, men der var engang!! :-) )

Thorbjørn Martsum

Selv hvis der skulle være noget rigtigt over det, hvad gør Mark Seemann, når han skal læse andres kode, der er lavet på store skærme? Eller kræves det at alle har små skærme?

God kode kommer hvis firmaet kræver god kode, og investerer tid i det i forbindelse med kode-review (helst på forkant, før koden checkes ind). Om skærmen er større eller mindre er bestemt ikke det mest væsentlige, men umiddelbart må en større skærm være at foretrække. Det er en illusion, at blot fordi koden bliver delt logisk fornuftigt op, så har man ikke behov for at se mere end 20 linjer ad gangen.

Henrik Mikael Kristensen

Skærmstørrelsen har nok ikke så meget at sige.

Afbrydelser håndteres bedst med ordentlige todo-lister. Hvis jeg afbrydes i mit arbejde bruger jeg alt for tit 50% tiden på at finde ud af, hvor f... jeg var kommet til, hvis jeg ikke har en huskeseddel.

Åbn et nyt dokument i din teksteditor og beskriv, hvad du vil lave indenfor de næste 10 minutter. Beskriv ikke emner der skal håndteres flere dage frem i tiden, for det skal højst sandsynligt laves om, og brug heller ikke store, malende beskrivelser. Bare 4 ord med det nødvendige, for at huske det.

Så er det nemmere at arbejde stabilt, især hvis man skal sidde og skifte mellem mange forskellige programmer, f.eks. editor, compiler og testmiljø.

Pelle Söderling

Claus: Min pointe er at hvis man kun formår at dele sin kode pænt og strukturet op ved at skifte til en mindre skærm og opløsning så er der vist nogle prioriteter man bør få på plads. Det er sådan lidt som at skære i sig selv for at få det bedre.

Og hvis ens skærm blinker mere af at den er større så er der vist igen noget man gør forkert, skærmen i sig selv er ikke det som skaber forstyrrelsen - ingen grund til at torturere sig selv unødvendigt for noget der skyldes alle mulige andre faktorer.

Claus Jacobsen

Jeg er såmænd også selv til store skærme, men jeg er sjovt nok også selv "berygtet" for at kunne kravle i zonen når jeg arbejder, så jeg ved rent faktisk en del om det med at kunne fokusere. (noget jeg nok har taget med mig fra 20 år med kampsport) Bliver man distraheret af et eller andet kan der gå mellem 5 og 10min til man er 100% tilbage på sporet igen. Og det er så her man 1. lettere får overblik på en mindre skærm fordi der faktisk ikke KAN stå så meget (forudsat at man bliver hvor man kom til) og 2. kva det lettere overblik over den specifikke funktion, så har man også lettere ved at optimere den.(ser ting mere "klart")

Når jeg skriver er jeg faktisk begyndt at gøre det på en tablet i onenote, for derefter at gå over på en større skærm og færdiggøre det når jeg har de vigtigste ting griflet ned. Netop på grund af at fokus faktisk er lettere at holde på en mindre skærm med mindre mængde tekst. Øjnene hopper ganske enkelt ikke så meget frem og tilbage. Især når jeg brainstormer er det rigtigt godt.

Torben Mogensen Blogger

og brug en ASCII-teksteditor (som f.eks. Emacs eller Vi). Det tvinger dig til at tænke over, det du skriver, i stedet for bare at vælge en af de forslag, som IDE'en giver. Og vel at mærke bruger du kun løsninger, du forstår, i stedet for at være afhængig af, at IDE'en kan holde rede i typer, biblioteksfunktioner, m.m.

Men det er helt i orden at have flere tekstvinduer åbne samtidigt, så man samtidigt kan se de dele af koden, der skal spille sammen (for eksempel en funktion og de steder, den bliver kaldt fra). Det kan kræve en lidt større skærm end en 1280x768 13" bærbar. Men skærmopløsningen er nok (op til en vis grænse) mere vigtig end det fysiske skærmareal, så en 13" skærm med 3000x2000 punkter er bedre end en 27" skærm med 1500x1000 punkter.

Jens loggo

24" skærme er desuden håbløse - her får du ikke rigtig nogen gevinst fordi de typisk kun kører 1920x1080 opløsning.
Man ønsker minimum 27" skærme så man får 2560x1440 opløsningen.

Ja, jeg finder det i øvrigt utroligt irriterende at næsten samtlige skærme man kan købe, er i 1920x1080, uanset størrelse.

Hvad er pointen i at købe en større skærm, hvis opløsningen er den samme? Så får man jo ikke mere plads, men tingene bliver bare større.

Det er fint til spil og film, men for os der vil bruge skærmen til andet, er det ubrugligt.

Så skal man investere i f.eks. en 27" på 2560x1440.

Begrebet Full HD hører til på fjernsyn, og ikke på computerskærme. Desværre er det endt med at blive en slags kvalitetsbetegnelse, som helt uden berettigelse er blevet overført til computerskærme.

Jens loggo

det siger sig selv at det er meget lettere at teste sine løsninger når man kan have vinduerne side-by-side end når man er nød til at skifte frem og tilbage mellem vinduer og konstant mister overblikket.

Spørgsmålet er hvor mange ting du har brug for at kigge på, mens du udvikler.

IDE/Editor og en eller anden form for output er vel oftest hvad der er nødvendigt, og alt-tab tager ingen tid at trykke. Måske lige et ekstra tryk på tab en gang imellem, når man skal til en brower og søge dokumentation.

Det virker rigtigt nok som en selvfølge at det vil give overblik at have dem side-by-side, men det er en antagelse, og gør det ikke nødvendigvis mere produktivt.

Rasmus Kaae

Bare fordi han ikke er i stand til at begrænse sin websurfing med multiscreen setups betyder jo ikke at det gælder alle. Hvis man følger hans logik burde vi anvende single threaded operativsystemer.

Begrænsninger på antal tegn pr linje giver heller ikke rigtig mening længere. Specielt ikke hvis man bruger indlejret dokumentation.
Personligt har jeg en skærm dedikeret til kodeeskrivning og en anden det er dedikeret til output og debug.

Sune Riedel

...eller drop tekst-editoren og skriv koden i hånden og brug kun API dokumentation, der er tilgængelig i trykt form...
- said noone, ever!

Torben, det er ikke min opfattelse, at grunden til at folk (heriblandt jeg selv) vælger at bruge et IDE er, at så kan man bruge løsninger, man ikke forstår og bare vælge det første det bedste forslag autocomplete kommer med.

I min verden, så er IDE en produktivitetsbooster uden sidestykke:
- Autocomplete skriver 80-90% af min kode - hvorfor er det vigtigt, at jeg kan huske de præcise navne på funktioner og konstanter, når jeg bare kan nøjes med at skrive 2-3 bogstaver og så vælge den rigtige?
- Inline dokumentation - ved to tastetryk kan jeg få vist dokumentationen for den API funktion, som cursoren står i - hvis jeg skulle være i tvivl om, hvad det egentlig er den gør - jeg kan ikke komme på en hurtigere måde, at lære nyt eller genopfriske viden
- realtime source kode analyse - mit IDE analyserer min kode, mens jeg skriver, for syntax, delvist også for semantik og andre uhensigtsmæssigheder, som jeg så ikke behøver allokere så meget opmærksomhed til (dvs. jeg ved, at jeg behøver ikke gå min kode minutiøst igennem efterfølgende for at sikre mig, at der er overensstemmelse mellem typer, og jeg har erklæret variable, som kun bliver skrevet og ikke læst etc.) - jeg kan fokusere på at løse "opgaven"
- refactoring - Jeg kan med et snuptag omdøbe en variabel, en metode eller en klasse, ændre på signaturen på en funktion, udlede en ny funktion fra en blok kode eller implementere alle metoder fra et interface i min klasse - alt sammen uden jeg behøver lave globale søg og erstat operationer, slå metode-signaturer op i dokumentation etc. - via realtime source kode analysen, så ved IDE'et alt om kontekst for den ændring jeg vil lave.

Det er lidt ligesom når man får udleveret en regnemaskine i 8. klasse i folkeskolen (eller det gjorde man dengang jeg var nået dertil) - der var nogle, som efterfølgende lod hjernen blive derhjemme og stolede blindt på, hvad de tastede ind på regnemaskinen - og så var der dem, som stadig selv kunne tænke og som legede med funktionerne for at lære endnu mere - på samme måde skal man ikke blindt stole blindt på sit IDE og tro, at det gør al arbejdet, men derfra og så til at lægge det i skuffen fordi man vil snitte sin kode selv uden det nymodens pjat - det synes jeg er ærgeligt - bruger man det rigtigt, så har man et fantasisk værktøj til at øge sin produktivitet (både målt på kvantitet og kvalitet) samtidig med, at man har adgang til at lære nye ting om de sprog, framework og API'er man arbejder med - lige ved fingerspidserne.

Robert Jørgensgaard Engdahl

Jeg oplevede ikke noget produktionsboost ved at sætte skriftstørrelsen i Emacs op (svarende til at bruge en lille skærm), tvært imod kunne Emacs dårligt vise to kollonner af karakterbredde 80. Faktisk passer det meget fint med to kolonner af karakterbredde 80 på en full-HD-skærm med almindelig skriftstørrelse. Det kan være at de mere moderne IDE'er fungerer bedre på små skærme end på større (hvis det er en præmis for konklussionen, vil jeg da gerne høre, med hvilken IDE man faktisk oplever produktivitetsforbedringer ved brug af en mindre skærm).

Der ligger meget produktivitet i at kende sine værktøjer. Man behøver ikke nødvendigvis at skifte sine værktøjer ud, men så skal man følge med i hvad de nye værktøjer tilbyder, og sætte sig ind i hvordan det så realiseres i det værktøj man bruger i dag.

Pelle Söderling

Det virker rigtigt nok som en selvfølge at det vil give overblik at have dem side-by-side, men det er en antagelse, og gør det ikke nødvendigvis mere produktivt.

Det er en antagelse jeg laver baseret på mange års erfaring med dual-monitor og high-res setups.

Men du behøver ikke tage mit ord for det: http://gbr.pepperdine.edu/2010/08/three-ways-larger-monitors-can-improve...

Desuden tror jeg ikke du forstår hvordan folk arbejder på sådanne setups hvis du tror udvikling primært handler om at være opslugt af en IDE.

Når jeg udvikler ting (IDE eller ej) eks. et website - så har jeg altid så jeg kan refreshe siden jeg arbejder på i min browser side-by-side med min kode, det gør det utrolig let at skifte fra det ene til det andet og se resultatet. Jeg har også min database manager åben side-by-side da det er ofte jeg har ting hvor jeg har brug for at tjekke om noget kode matcher tabel-layouts og lign. eller har brug for at tjekke noget data som relaterer til min kode - det er langt nemmere når man kan se begge dele på samme tid.

Det samme gælder dokumentation, stack-overflow søgninger og lign. - hvis du foretager det på din sekundære skærm så behøver du ikke forlade din "kode-context" hvorved du netop ryger ud af din "zone".

Brug den ene skærm primært til din IDE/Editor og hvad der primært relaterer til det du laver pt. (DB Manager/Test-browser etc.) og brug den anden skærm til "alt det andet" du måtte have kørende og gang i så det ikke forstyrrer på din main-skærm.

For mig er der ingen tvivl om hvad der er mest produktivt, men gør dig endelig dine egne erfaringer - men jeg synes det er tåbeligt at handikappe sig selv med mindre skærm-plads og opløsning med nogle så luftige og begrænset relaterede argumenter.

Allan S. Hansen

Spørgsmålet er hvor mange ting du har brug for at kigge på, mens du udvikler.

Afhængigt af hvad jeg udvikler på har jeg ofte gang i op til 3-4 forskellige programmer på en gang og derfor er det rart en del af det kan stå på hver sin skærm/åbne vindue frem for at skulle alt-tab mellem dem.

For mig øger flere skærme og større skærme klart min produktivitet, netop fordi jeg nemmere kan skabe mig overblik mellem et sammenspil af informationer ved at have dem alle præsenteret hurtigt frem for at skulle skifte mellem vinduer på en enkelt skærm.

For mig svare det til at kunne have 2-3 bøger åbne på relevante sider på en gang, frem for at skulle sætte bogmærker i en bog og bladre frem og tilbage hele tiden. Det er nemmere at skabe overblik, for mig.

Afbrydelsen - der har han 100% ret. Selvom man langt hen ad vejen lærer at multitaske og måske hurtigt kan skifte kontekst mellem problemstillinger, så er det på ingen måde lige så effektivt som når man kan være "in the zone".
Og der er erfaring/kendskab til arbejdspladsen virkelig en faktor.

Anonym

Jeg kan godt nikke genkendende til nogle af de sysnpunkter som kommer frem i artiklen. Som helt grøn ingeniør blev jeg sat forat en 80 tegn gange 25 liniers ASCII monitor, og kodesproget var 8080 assembler og operativsystemet var MIK (vores egen variant af MIKADOS), yep - mange år siden.

Mine kollegaer grinede af mig, fordi jeg faktisk bruget papir og blyant inden jeg gik til tasterne. Ikke sådan at jeg skrev koden, men jeg lavede skitser. Og det var super effektivt. Om den lille skærm gjorde det bedre er tvivlsomt, men der var i hvert fald ikke noget med horisontalt scroll at spilde tiden på - og heller ikke mus selvfølgelig.

I dag skriver jeg ikke kode (kun for sjov og til husbehov), men rapporter og tekst. Og jeg laver stadig skitser, og tænker mig om inden jeg går i gang. Det høster af og til en del undren, fordi mange der ikke arbejder sådan lider af en konstant frygt for at komme bagud i tidsplanerne. Jo hurtigere der kommer tekst ud af Word, desto bedre har de det.
Denne pølsemaskine tankegang er skadelig, og jeg har lidt en mistanke om, at den indirekte skyldes alle de distraherende ting som tager vores tid. Og hvis distraktionerne sker på samme skærm som vi bruger til "hovedopgaven", så opstår balladen.

Jeg kan sagtens mærke når man er i "zonen", og det sker altså oftest når jeg sidder med min lille MacBook Air med 13" skærm, og alt andet end tekstbehandling slukket, og mine papirnotater ved siden af. (Indrømmet, det er ikke altid papir, men alligevel).
Sætter jeg mig foran den store 27" på kontoret med det hele slået på, så er koncentrationen meget mere vanskelig at holde. Det går med mail stoppet (til nød uden lyd, men kørende), samt alt andet lukket ned. Men med en browser i et hjørne, mail, skype, lync, jabber videokonference osv. kørende, kommer der ikke meget produktivt ud.

Så Nop, det er nok ikke skærmens størrelse, men hvordan vi indretter os på skræmen og på PCen, der er afgørende. At små skærme så indbyder til at man starter mindre op kan måske være rigtig nok, men det er altså ikke størrelsen på skærmen der udløser balladen. Det er beslutningerne der tages foran skærmen.

Lasse Lindgård

Jeg har mellem 30 og 45 minutter i stillezonen hver vej til arbejde. Der sidder jeg så godt som altid med min 12" lenovo og koder på livet løs.

Når jeg er i toget, så kører jeg mit IDE i fuldskærm og laver altid ren testdrevet udvikling. Der er ikke noget netværk, så det er ikke muligt at teste mod eksterne afhængigheder - og det er heller ikke muligt at blive afsporet af mails eller andre henvendelser. Men lidt planlæggelse af opgaver er det næsten altid muligt for mig at holde denne tid til 100% "i zonen".

Når jeg så kommer ind på kontoret, så har jeg en 27" og en 24". Her er der andre fordele. Især, hvis det jeg sad og producerede i toget har problemer, så er det dejligt at kunne se loggen, debuggeren og API dokumentationen på to dejlige skærme mens at man fejlsøger.

Så min erfaring er at begge dele har sine stærke sider. Jeg ville nødigt undvære nogen af delene.

Log ind eller Opret konto for at kommentere