Du kommer aldri til å tømme backlogen din. Du kommer aldri til å jobbe deg gjennom den. Jo større den blir, jo mindre nytte har du av den.

Kode blir rotete. Derfor må vi rydde mens vi jobber, ikke spare opp rotet til ukeslange refaktoreringssprinter.

Er parprogrammering mindre effektivt? Det korte svaret er nei, tvert imot. Det lengre svaret er noe mer nyansert.

…og som alle andre ferdigheter kommer du ikke til å mestre den første gang du prøver. Det må trenes opp.

Jeg vil skrive god kode. Jeg vil være stolt av koden—både koden jeg har skrevet selv, og koden andre har skrevet. Dit kan man komme med parprogrammering!

Hva gir det mening å fokusere på når man starter i en ny jobb? Hva driver Øyvind, Christian og Magnar med fra dag til dag? Jeg deler mine erfaringer fra mine første to uker.

På årets JavaZone holdt jeg et innlegg om hvordan vi får til å levere kontinuerlig. Fokuset var på de små detaljene. Jeg viste hvordan vi bryter opp arbeidet sånn at vi kan jobbe rett på main og rett i prod, enten vi gjør litt refaktorering eller bygger en helt ny innloggingsløsning.

Vi dytter kode rett til main, som bygges rett ut i prod. Ingen feature branches. Ikke noe staging-miljø. Men hvordan funker det når vi skal lage omfattende funksjonalitet?

Står pull requests i kontrast til kontinuerlig integrasjon? Er kontinuerlig integrasjon det samme som CI? Hva med CI/CD? Jeg forsøker å oppklare noen uklarheter fra mitt forrige innlegg om pull requests.

Pull requests har blitt en så vanlig arbeidsform at det for mange er synonymt med å bruke git. Men er det en bra ting? Må alle endringer komme via en pull request? Jeg er ikke så sikker.

Hva skal til for å jobbe effektivt i produktteam? Og hva har vi selv gjort i vårt nystartede team de første månedene? Og hva har dette egentlig med frokost å gjøre?