50. Längst ner i pyramiden
lyssna! 
Med utgångspunkt i Gunnar Morlings visuella kodgranskningspyramid snackar vi var fokus under en kodgranskning bör ligga, sårbarheten, att kodgranskning är en färdighet som måste tränas och hur vissa delar behöver hårdare granskning för att de är svårare att ändra i efterhand. Dessutom en hel del sidospår om bland annat dokumentation, mobbprogrammering och mycket annat.
Om du gillar podden blir vi väldigt glada för en liten recension i iTunes eller en prenumeration på Spotify. Följ oss och säg hej på @asdfpodden på Instagram eller Twitter (Anton, Therése) <3
Länkar
Avsnittets skämt:
Hur får du en docker image på svenska?
Du kör en "docker bild"
Skrapa här!!
Transkribering
Transkriberingen är gjord av nån "AI-grej". Du kan förbättra den genom
att klicka precis här :) Hur får du en docker-image på svenska?
Jag vet inte.
Du kör en docker-bild.
Jag tycker att det här var svinkul.
Det är inte okej.
Jag tycker att det här på riktigt var en av de roligaste på länge.
Det krävs att man tänker efter lite grann.
Fan vad bra det var.
Du säger alltid att det är det roligaste på länge.
Fan vad du måste ljuga.
Jag tänker att nivån går uppåt.
Det stiger.
Jag mådde så dåligt när jag klämde ur mig den här.
Jag har absolut ingenting att klaga på.
För jag kommer ju inte med så många skämt från mitt håll.
Vart är vi? Välkomna till ett nytt avsnitt av ASDF, säger man kanske.
Jag är så jävla... Gud vad glad jag blev av det där skämtet.
Välkomna till ett nytt avsnitt av ASDF, som du precis sa, som jag sa igen nu, för att jag blev förvirrad.
Men vi sa bra skämt.
Men idag tänkte vi snacka lite om Gunnar Morlings code review pyramid som du skickade till mig.
Exakt. Jag tror att den här kanske dök upp på Codesnacks slackkanal som de har.
och att någon länkar den där. Och då tänkte jag att det där ämnet snor jag utan att skämmas.
Och så pratar vi om det. - Rakt av.
- Helt enkelt. Och jag tänker att innan vi börjar så kan vi också nämna att vi båda har varit ute och gästpoddat lite grann.
Du har ju varit med i Datachase podcast som släpptes förra veckan kanske?
- Ja, på när det släpptes, vet jag inte. Men jag gästade i deras podcast de har som
Vi pratade mycket om vilken bredd det faktiskt finns för inom teknik och programmering.
Jag var där och pratade om hur det är att vara konsult.
Det var jättetrevligt.
– Ja, jag tycker att det var ett toppenavsnitt.
Så kan rekommendera folk att lyssna på. Jag lägger länken dit i beskrivningen.
Och sen har jag också varit och gästat KodSnack på tal om dem.
Och pratat med Fredrik Björman som har den.
Vi pratade om en artikel som har världens längsta titel.
Jag kommer inte ihåg huvudet nu, men det är typ något i stil med "136 facts every developer should know before they turn to gardening or nude modeling" eller något sånt.
"Before they burn out and turn to landscape painting or nude modeling".
Ja, jag var ändå nära.
Ja, du har begått tyckande.
Exakt, där jag gästade och tyckte massa saker om.
En väldigt liten andel av de här punkterna, men det blev ändå ganska många punkter
rent numeriskt.
Så den kan man också lyssna på. Den släpptes i tisdags, tror jag.
Men med det ur världen så tänker jag att vi hoppar in i den här
kodgranskningspyramiden.
Och som lite bakgrund, den handlar egentligen om
Vad man ska tänka på när man gör en code review.
Så inte från andra hållet, utan det här är för granskaren.
Att man ska fokusera på olika saker, vilka som är viktiga, vilka man ska lägga mest vikt på.
Och visualisera det här på ett väldigt bra sätt, tycker jag.
Vi länkar såklart den i beskrivningen så att man kan gå in och kolla själv.
Men om man börjar beskriva hur den ser ut innan vi går in på detaljerna.
Det är fem olika nivåer där den i botten är bredast såklart, i och med att det är en pyramid.
Den pratar om API semantics, alltså hur ser API-ut egentligen för vad den här kodändringen ska arbeta med.
Sen är det implementation semantics, alltså hur ser koden ut och inte just API-ut eller hur den samarbetar med annan kod.
Nästa nivå är Documentation.
Ovanför det är Tests.
Sist på toppen är Code Style i den minsta biten.
Det här är de fem kategorier han har delat in i.
Han har en tanke om att ju större bit av pyramiden det är desto mer tid ska spenderas på de delarna under kodgranskningen.
Typ så handlar väl egentligen bilden om, om jag inte har missrepresenterat det helt och hållet.
Nej, det tycker jag inte. Du glömde färgerna. Nej, jag skojar.
De är ju absolut viktigast.
Ja, men det är väl intressant också på utgångsläget är väl mycket att
fokuset tyvärr ibland verkar ligga på de två högst upp
som han också tycker är någonting som bör automatiseras liksom.
som inte ska läggas vikt vid egentligen så på en kodreview.
Nej men exakt, vi var in på det här för något avsnitt för väldigt länge sedan nu tror jag att man inte ska prata så mycket om hur koden är skriven formateringsmässigt.
Han säger också att det ska automatiseras så mycket som möjligt och pratar man från en kod så är ju Prettier verkligen en gulden standard idag.
och gör ju att man slipper prata om hur koden är formaterad över huvud taget så länge alla kör Prettier.
Ja, det gäller väl inte bara fronten, det gäller väl JavaScript, men sen så finns det väl även Prettier eller en typ av Prettier för ganska många språk.
Jo, men det stämmer nog, du har nog rätt i det. Jag tror att Go har till och med något inbyggt som heter Go Format eller något sånt där.
Ja, för jag tror verkligen inte Prettier var liksom, eller Prettier för JavaScript var någon intens först, det är bara de som tror det i vår bubbla.
Vi utgår ju väldigt mycket från vår bubbla, det ska erkännas.
Men så är det.
Men jag tycker ändå att det är väldigt intressant för den här visualiserar så extremt tydligt och på ett bra sätt.
Man ska inte lägga så mycket tid på CodeStyle, men man ska lägga väldigt mycket tid på API Semantics som han pratade om.
Han ger också lite exempel på frågor, vi kan komma in på dem snart.
Jag har också nämnt att de här två toppbitarna, eller en och en halv toppbit kanske, ska automatiseras.
Så till exempel CodeStyle och Test till vissa delar ska kunna automatiseras så mycket som möjligt
att man inte ens ska behöva prata om det på CodeReview.
Det känns också som en självklar grej för mig, för att jag har kommit dit.
Jag har suttit i organisationer där det är så.
Men sen hör man ju alltid de folk som klagar på hur jag har skrivit,
att jag har använt single quotes istället för double quotes.
Och den känns ju bara tidsödande.
– Ja, såna korrosor har jag sett mycket med.
Men jag tror...
– Har du varit personen som har skrivit det?
– Jag har varit personen som har skrivit det.
Du säger använd single quotes istället.
Ja, men då var vi ju liksom, det var inte så mycket att jag kände att det var jätteviktigt för mig,
utan det var snarare att det var mycket diskussioner kring kodformatering.
Det här var pre-prettier, så då satte vi upp regler och då blev det väl så här när jag gjorde en review,
att ja okej, men det finns ju regler vi vill ha här, så borde vi inte följa dem.
Men jag tror, och det här tänkte jag mycket på när jag såg den här, att jag tror det handlar mycket också om erfarenhet.
För att under den här tiden så var det också, det var nog egentligen mina första code reviews.
Jag var inte van vid att sitta och reviewa PRs på det sättet innan.
Och jag tror att jag kände mig väldigt osäker och visste inte vad jag skulle titta på, visste inte hur jag skulle ifrågasätta någon annans liksom kod.
Så jag tror att det blev en safe grej att kolla mycket på kodstilen.
För att där fanns det så tydliga regler.
Så jag håller absolut med om att det bör automatiseras till stor del.
Jag menar, alltså Prettier när det kom in, det var ju det bästa som har hänt.
Fast jag är skeptisk.
Men det är ju inte alltid bara lätt att börja kodgranska, utan det krävs ju träning.
Ja, verkligen. Det är ju en färdighet som vilken annan egentligen.
Och då kan jag också tänka mig att den ser läskig ut.
Eller så att jag som om jag skulle börja göra det här då skulle jag kanske få lite panik.
Okej men API semantik eller semantics implementation semantics hur gör jag det?
Klarar jag av att se det? Vilka mönster är det?
Det hade känts kanske lite stressande för mig att göra det.
Då hade man varit glad om man hade fått några sådana här små små peers med typ double quotes.
Ja exakt, man kan verkligen tänka sig att om man som en utvecklare med inte så mycket erfarenhet
öppnar den här och man ska använda den som guide för att kolla, man ska göra en code review för första gången
då skulle man kanske bli lite överväldigad.
Om vi går in på API Semantics till exempel, då har jag lite exempelfrågor
och en är "API as small as possible, but as large as needed"
Och den är ju superbred.
Och den handlar egentligen bara om erfarenhet och vilken kunskapsnivå man är på inom den domän där man sitter och allting sånt.
Och det kan vara jättesvårt att svara på den frågan.
Så jag tror att det är ganska lätt att om man går in och läser den här som satan läser bibeln, säger man så.
Då tror jag kanske att det blir lite fel.
Utan snarare att det här ska mer vara en vinkning åt vilket håll man ska gå och vad man ska lägga sin tid på.
Ja, jag tycker det känns helt rätt.
För det är ju inte kodstilen som kommer ge svåra buggar för affären.
Utan det är ju det andra.
Men vi gillar att vi pratar mycket om dokumentation, men är folk verkligen bra på dokumentation?
Nej, förmodligen inte.
Det beror lite på vilken typ av dokumentation man pratar om.
Jag tänker att en sak som inte riktigt är med här, och det kan jag förstå på något sätt,
Det beror lite på vad man gör. Men jag tycker att typer går också in i väldigt mycket av det här.
Till exempel om man kör TypeScript.
TypeScript går kanske in lite grann i test, för att det är statiska tester av din kod om du har uppföljt din typkontrakt.
Dokumentationen blir också lite typer, att dokumentera sig själv när man faktiskt skrivit sina typer.
Och sen blir det implementationsdetaljer och sånt också, hur man ska typa sin kod.
Men just för dokumentationens skull så tycker jag ändå att
sån dokumentation kan folk vara duktiga på för att den kommer av sig själv.
Men inte sån här dokumentation som är väldigt stora stycken text där man ska förklara saker
som ibland kanske behövs om vi tittar på dokumentation för stora ramverk.
Där behövs tyvärr den färdigheten som vi har med att kunna skriva dokumentation.
Ja, det är mycket svårare än vad man tänker att det ska vara.
Det är lite spännande också, för jag menar som du säger, variabelnamn som är rimliga och om det är någonting som är helt banana så kan man lägga en kommentar för att förklara.
Eller att tester som man skriver faktiskt också är dokumentation för att någonting ska fungera.
Så mycket av det kommer naturligt.
Och någonting som jag känner att jag kanske tappat lite, för nu för tiden har jag suttit i mobb.
Alltså vi kör ju inga kodgranskningar så.
Så jag har kommit ur det lite.
Men det tänker jag ändå att jag kommer ihåg när det var, när jag skrev PRs kontinuerligt på allt jag gjorde.
att jag successivt blev mycket bättre på att förklara vad jag har gjort för någonting.
Så att det blev liksom som en övning på en dokumentation.
Är man bra på att skriva ticket så gäller ju samma sak där.
Ja exakt, det är väl lite som med allt att övning ger färdighet,
men just att man inte tänker på det på det sättet kanske när det kommer till dokumentation.
Om vi ska kunna dokumentera något. Det finns ju folk som jobbar som "technical writer"
Som jag inte vet vad det heter på svenska, men som jobbar med att skriva bra dokumentation och är extremt duktiga på det.
Och det ger ju extremt mycket när dokumentationen är bra. Jag vet att vi varit in på det tidigare.
Att titta på "views" dokumentation som har varit extremt bra väldigt länge.
Där Sara Dresner har varit inblandad och jobbat med pedagogiken.
Och Reacts nya dokumentation där Rachel Nabors har varit inblandad.
Och tagit ett helhetsgrepp över att det ska vara pedagogisk dokumentation.
Sen är det på en helt annan nivå än vad man behöver ha i ett eget projekt.
Beroende på vad man bygger.
Men det är fortfarande att man måste lära sig de grejerna som behövs.
Det ska vara pedagogiskt, det ska vara lätt att förstå.
Annars är det ju lätt att bara skriva ner saker, men det är ju inte så lätt att skriva ner saker som folk fattar och liksom finner intuitivt.
Nej, alltså du måste ju också kliva ur din egna bubbla, för att när du sitter på all den här kunskapen, eller kunskap om ditt specifika problem, det kommer ju någon utomstående inte göra.
Och då måste du förklara det på ett sätt som gör att de fattar vad som händer.
Och det tycker jag också är bra.
Om man tittar, och det var du som sa, det var en och en halv av de två första,
eller översta i prövningen, den som ska automatiseras.
För det finns ändå en del som ska fokusera på test.
Och det går ju tudelat, coderevia testen som har skrivits,
eller testa det som har byggts.
För det tycker jag, speciellt om man kanske inte har QA,
Om jag vill reviewa någonting så vill jag ju oftast testa funktionaliteten också.
Och det vet jag att jag föredlar mycket vikt på att förklara vad är det jag har gjort, hur funkar det, hur testar du av det?
Och det blev också så här, jag måste verkligen förklara vart jag befinner mig, vilket kontext och vad det är som ska funka för annars kommer den här personen inte kunna testa det.
Och det blev ju ofta mycket frågor tillbaka, vad är det du menar?
Ja, det är ju verkligen så att bara CodeViewer genom att kolla genom koden är ju ofta ganska svårt.
Då hamnar man lite på det här, då kanske det är implementationsdetaljer och code style som man fastnar på.
Ser det ut som att koden gör rätt sak ungefär? Ser koden vettigt formaterad ut?
Men man fattar inte riktigt kanske den här kontexten som krävs att man ska kunna lägga lite tid på hur API-et är designat eller hur är dokumentationen korrekt.
Då måste man ju faktiskt veta vad som ska dokumenteras.
Ja.
Nej men, fastän det var, shit vad länge sedan, jag blev lite trött bara på att tänka på korv.
Jag gör också väldigt mycket för att utveckla kultur där man slipper codevua för att man sitter tillsammans och gör allting.
Jag har också mobbprogrammerat väldigt mycket som du gör just nu och det är extremt skönt att slippa göra det.
Ja, men om man ska prata lite om mobbprogrammering, ibland kan det vara lite skönt att bara ta på sig sina lurar och gräva ner huvudet och köra.
Så det kan jag ju sakna med det här och då ingår ju de här bitarna men det är också rätt skönt när man inte har typ en kö på 10 PRs som man måste kolla igenom.
För det kan ju gå en dag bara att kolla PRs egentligen.
Ja verkligen. Förra uppdraget jag var på så var det väldigt hård PR-kultur eller PR-standards.
Du ska verkligen dokumentera med bilder och visa vad du har gjort och skriva duktig dokumentation.
Ibland kunde man spela in en film och gå igenom det flödet man hade gjort och visa att det här är så vi har gjort det.
Och det funkar ju väldigt bra, men det tar ju väldigt mycket tid istället.
Så jag vet inte om det är värt det, att då lägger vi massa tid på att visa code reviewer i stället för att vi sitter tillsammans och gör den här grejen tillsammans.
Och så skiter vi på code reviewer för att det har gjorts live, men vi har också fått massa andra saker som vi har vunnit genom att vi skrev all kod tillsammans.
Vi har diskuterat det, man har fått en förståelse av båda två för den.
Och kunskapsdelningen har ju skett direkt, så vi behöver inte lägga någon specifik tid på att berätta hur saker funkar eller hur man har löst något.
Det roligaste är bara när mobben fastnar i samma kontext.
Alltså du vet när man fastnar på en grej och skulle behöva rubberducka den för att komma ur det.
Ibland upplever jag att hela mobben fastnar på samma sak och så trycker vi in saker som blir fel ändå för att vi inte kunde tas ur det.
Och det hade vi kanske kunnat fånga i en code review.
Ja, men det känns ju också som att det kan lika gärna hända i en code review.
Det är inte så att code revieware är perfekta i att hitta allting.
Nej, verkligen inte.
Speciellt inte en sån som jag som bara kollade på kodstyren.
Men en sak som jag tyckte var intressant som jag tänkte på med den här pyramiden.
som vi var in på lite grann, men han pratar ju om att botten på pyramiden, alltså API-implementationen
och sen implementationsdetaljer, dokumentation, test och CodeStyle, högs upp.
Att ju högre upp du kommer i pyramiden, desto lättare är det att ändra i efterhand.
Medan ju längre ner du är i pyramiden, så längst ner på API-implementationen,
desto svårare är det att ändra i efterhand om man skulle upptäcka någonting.
Ja det är väldigt sant också när man läser det åt det hållet.
Annars är det så här, varför är API grunden på pyramiden och inte implementation semantics.
Så det är såklart att API har ju långt större påverkan på allting.
Det är mycket svårare att ändra, det är sant.
Ja, exakt. Och den tycker jag är ett väldigt bra sätt att tänka på, eller snarare argumentet för varför man skulle göra sådana här pyramid-revisor.
Om vi vet att kodstilen som vi har, eller formateringen, den spelar inte super stor roll.
Om vi upptäcker någonting kan vi ändra det här på fem minuter senare.
Medan om vi implementerar ett API på fel sätt, säga att det skulle vara ett externt API till och med, då kanske det är folk som har integrerat mot det.
Och helt plötsligt så krävs det en hel process runt hur vi ska förändra den här grejen som vi inte kollade på i vår code.
Och jäklar vad man måste tänka till då ändå. Jag har gått mot externa API, och helt plötsligt har någon tryckt ut en ändring.
Att istället för att inte få ett värde så fick du helt plötsligt 0 på det i JSON.
Och det liksom pajar hela grejer. Det är så litet och det tänker man inte på när man sitter där och bygger sitt API.
Nej exakt, och kanske särskilt inte när man faktiskt code reviewar.
Man får en code review på att vi har förändrat den här lilla featuren.
Och sen tänker man, ja men den är bra dokumenterad och koden ser vettig ut.
Vi har den här lilla ändringen på API-kontraktet.
Men, jaja.
Ja.
Åh, Gud. Jag vill inte göra viktiga saker.
Samtidigt är Code Review också kul på det sättet att man lär sig på ett annat sätt.
Som sagt, vi står för små programmering och partprogrammering.
Men ibland när man sitter och code-reviewer så kan man upptäcka saker som de kanske har gjort, eller som någon har gjort.
Som inte hade hänt i en mob, men som de implementerar på det här sättet.
För det är något jag kan i mitt huvud. Medan i en mobb hade man kanske stannat tidigare än att en implementation hade kommit dit.
Och då kanske man upptäcker och lär sig lite saker där.
Sen kanske jag inte tycker att det väger upp alla de andra nackdelarna.
Men jag tycker ändå att det är spännande att man kan se olika saker på olika sätt.
Beroende på hur Code Reviewen går till. Om den är live eller om den är mer i ett statiskt format.
Ja, absolut. Men jag tycker inte egentligen att man ska glömma hur sårbart det är med en code review.
Alltså åt båda håll. Det är ganska sårbart tycker jag att få sin kod granskad av någon annan.
För det ska det ju inte vara. Förhoppningsvis finns det en så pass trygg miljö att det inte är det.
Men på något sätt, för mig känns det verkligen så här, okej men det här är hur jag har tänkt och visar upp det här nu och någon ska granska det.
Det tycker jag är lite sårbart, men jag tycker också på något sätt det är sårbart när jag ska granska någonting om jag råkar påpeka någonting som inte är det fel eller vad jag tror, eller inte är på det sättet som jag förväntar mig.
så känns det också fel. Så jag brukar få sitta och på tal om att lära sig saker.
Saker som jag inte riktigt förstår eller inte kan.
De får jag sitta och testa igenom eller googla och läsa på om för att jag inte vill ha fel.
Vilket jag måste jobba på, men jag lär mig saker av det.
Ja, jag håller i verkligheten med.
Det är svårt, för den här pyramiden fokuserar väldigt mycket på
vilka frågor ska man ställa, vilka delar ska man fokusera mest tid på, och så vidare.
Det finns en helt annan del som handlar om det du är inne på,
hur gör man en sympatisk kurdreview?
Hur ser du till att det du skriver inte uppfattas som för aggressivt, vilket är väldigt lätt i text?
Eller hur får du Curdvuren att hjälpa personen mer än att kännas som en attack, vilket det är lätt att göra, särskilt om man inte har jobbat så länge?
Ja, men jag menar, vissa av de här frågorna han ställer, det skulle jag verkligen behöva googla länge på för att hitta ens vad jag vill komma fram till.
Typ "Is it secure? No SQL injections etc."
Det är så här, oj, så ska jag behöva sitta med ett tag.
Ja, så är det absolut. Men det känns ju också som att man kan ju inte kunna allt så att säga.
Så att man får utgå från sin egen kunskap när man codevjuar också.
Det är inte någon som förväntar dig att du ska sitta och kunna varenda litet fall som vi behöver kolla på när det kommer till säkerhet.
Som ditt exempel. När man gör en codevju.
Utan det handlar mer om att då får man ta det som det kommer.
Sen beror det lite på kontext. Jobbar man på en bank kanske det är lite viktigare med att secure är större del av code review.
Ja, man borde inte vara ett jobb som jobbar med finans.
Exakt.
Jag tycker ändå det är en väldigt bra utgångspunkt om inte annat.
På vart man kan tänka på och se när man börjar Curvio.
Ja, det tycker jag absolut. Det är en väldigt bra och pedagogiskt tydlig påminnelse hela tiden om vad vi vill titta på.
Det kan ju vara att man behöver fräscha upp sig igen.
"Just det, hur är det jag tänker på det här?"
"Ta som mig, att jag har suttit länge inte i Code Review."
"Ska tillbaka till Code Review."
"Just det, jag ska inte fastna på 'Is it dry?'"
"För det är inte så jäkla viktigt."
Nej, men exakt.
Jag tycker också att den är jättebra.
Jag har börjat på sistone, eller försöker i alla fall, att skriva ner mycket av mina åsikter.
Och försöka motivera dem för mig själv.
för att jag har insett att det inte alltid i stunden eller på längre sikt att jag kommer ihåg varför jag tycker saker.
Utan det är mer att jag vet att jag tycker så här, jag vet att jag haft bra underbyggda argument för varför jag tycker det här.
Men jag kommer inte ihåg argumenten just nu.
Och då var det ändå väldigt skönt att kunna "ja, just det, vänta, jag skrev ner det här någonstans, varför tyckte jag så här".
Och sen kan man ju omvärdera det där såklart, men det är ändå bra att ha det nerskrivet kan jag tycka.
Det känns väldigt engagerat av dig ändå. Det är bra underbyggt tyckande.
Jag är mer så här att jag bara viftar i luften. Som Don Quijote, Värdekvarnarna.
Precis. Jag ska väl erkänna att jag också viftar ganska mycket.
Det är inte så att jag i en diskussion bara "juste, vänta, jag ska bara kolla mina anteckningar".
Fast det hade varit en sån jävla power move om du började göra det.
Det är också ännu värre för att allting jag skriver skriver jag ju oftast som inlägg på min egen sida.
Så det blir snarare typ "Vänta, vänta, jag ska bara kolla det här inlägget jag skrev på min sida för ett tag så jag kan skicka en länk till dig om du vill."
Annars skulle jag jättegärna vilja att du printade ut allt och gick runt med en lunta och började bläddra i varje gång du skulle tycka någonting.
Jag ska bokstavligen bli en pärmbärare.
-Vart är toppen? -Det kanske är lösningen på allting.
Jag ska bara bläddra till rätt sida här.
Jag har ett register men det är inte uppdaterat.
Sluta med att jag är som en karaoke-pärm.
Jag har haft med mig den överallt för att kunna vara beredd.
Så att de är lite inplastade sidor och lite halvkladdiga för att de har klivit ihop och grejer.
Ja, och sen har du några bilder som ligger i sådana här gamla CD-fådrar.
När man hade CD-skivor som man kunde lägga i plastfickor.
Ja, exakt. Där ska jag stoppa in den här pyramiden.
Ja.
Det är kväll. Lite sent, det märks.
Men ja, jag tycker det är en jättebra grej, en jättebra påminnelse.
Jag känner också att jag blir lite taggad på det här, för jag känner ju alltid att jag...
Alltså, och det är väl lite på samma tema, men jag känner att jag verkligen kan någonting eller befäst min kunskap
när jag måste antingen förklara den för någon annan på ett väldigt tydligt pedagogiskt sätt, liksom,
eller när jag faktiskt måste skruva ner det.
Så det är ju egentligen ganska trevligt, tycker jag, ibland, att lägga tid på att...
Nu är det ju mer skriva code review.
Men också code reviewa någon och förklara varför jag tycker så eller tycker så.
Men jag glömmer ju bort allt jämt så jag kanske också måste bli en pernbärare.
Det kanske är resultatet av det här avsnittet.
Pernbärarnas återkomst.
Ja.
Ja, jag tycker det känns som en perfekt tillfälle att runda av.
- Jajamän. - Som vanligt, Vilmar och Snåst, då finns vi på Twitter.
Jättekul om man har åsikter om den här CoreView-pyramiden som vi inte har tagit upp
eller om man inte håller med oss eller vad som helst att höra av er.
Ge oss gärna en recension där vi finns. Det är lite överallt.
Ha det gott så länge hör ni.
Så här hörs vi. Eller det gör vi inte. Men ni hör oss.
Okej, ha det bra! Hej då!
[Outromusik]
