Clojurians Log v2

Jeg fikk akkurat en 3000 % speedup av hashingen! • før ◦ les 32 kb: 0.4 ms ◦ hash 32 kb: 4 ms (thinking-face) • etter ◦ les 32 kb: 0.4 ms ◦ hash 32 kb: 0.15 ms ved … å fikse reflection warnings! 😄 🤡 Ser bedre ut nå — laste bytes fra disk skal ta mer tid enn å tråle gjennom bytes i minnet og lage en sjekksum ☺️ Det var noe som skurret her. ooog det er sikkert mange flere steder jeg skulle satt:

(set! *warn-on-reflection* true)

det kunne sikkert blitt enda bedre ved å lese chunk for chunk fra disk og hashe etter hvert som de kom inn i minnet — la CPU og disk jobbe samtidig, men det gidder jeg ikke! Ikke merkbart så lenge dingsen min har én ekte bruker (meg selv) 😂

Dette var noe jeg fikk erfare første gang jeg benyttet clojure til noe Advent of code-greier. Tok votter og vinter, mens det gikk på et blunk med standard imperativ java-kode. Så da oppdaget jeg type-hints 🙂

Haha, nei kjærlighetshistorien er ikke høydepunktet 😅

Men soundtracket!

Nydelig bok, minus åttitallet som skinner gjennom på kjærlighetsfronten, ja.

For de som ikke kjenner til boka (The Goal), så handler den (grovt sett) om hvordan man forbedrer flyt og kapasitet i produksjon, ved identifisering flaskehalser og rigge flyten deretter. Istedenfor å optimalisere prosesser som ikke er flaskehalser, så ser man på hvordan forsinkelser og opphopninger i flyten påvirker bunnlinja. (Boken fokuserer også på metoder for undervisning, og legger frem hele stoffet i en fortelling, og bruker aktivt den https://ndla.no/r/religion-og-etikk/kva-eksisterer/9608d9f914/19156 for å engasjere både hovedpersonen og leseren i problemløsningen.) Har tenkt litt på hvordan dette er overførbart i min egen hverdag, og jeg har ihvertfall ett åpenbart eksempel: Jeg har jobbet flere plasser hvor vi har benyttet pullrequest-basert flyt, og hvor det var stor variasjon i både størrelse og kvalitet på det som blir bedt om review på. Jeg blir en flaskehals som må bruke mye tid på review pga lav kvalitet og stor størrelse, og hvor produsentene av PRene løper videre og produserer nye PRer (opptil flere) før de foregående har blitt merget. Disse utviklerne er da tilsynelatende effektiv, men sørger egentlig bare for dårlig throughput totalt sett. En åpenbar løsning (nå som jeg har lest boken), er å begrense antall oppgaver en utvikler kan jobbe på. Det vil være bedre om utvikleren må tvinne tomler inntil PRen er merget, istedenfor å fortsette å produserere nye ting. En mulig positiv bi-effekt av lediggangen kan være at tiden brukes til egen-review (og forbedring).

Dette er spot on! unreviewed PRs er WIP. Hvis vi får en haug av WIP, må vi bruke tid på andre steder. Eksempelvis skrive PR’er som er lettere å reviewe. Eller parprogrammere, Eller hjelpe til med review. Samme om man har et QA steg. La utviklerne skrive happy path tester i playwright, så er det mindre jobb for QA folka (ja noen har sånne fortsatt)

Jeg vil dra det lenger: PR er WIP

> Eksempelvis skrive PR’er som er lettere å reviewe. Helt enig. Og det krever innsats: en god beskrivelse (tar man seg bryet med å gjøre dette, kanskje man finner ut nye ting om endringene, kanskje man finner ut at hele greia må tilbake til tegnebrettet, etc), og et lite og fokusert sett endringer.

Det er fremdeles helt koko for meg at den mest utbredte arbeidsmetodikken i bransjen virker å være at alle jobber i full isolasjon for så å kaste arbeidet over veggen til noen som ikke har konteksten til å forstå endringene, og som dessuten har fullt opp med egne oppgaver.