[00:00:00] Adam Tornhill: Jag och mina kollegor vi gjorde en ganska stor studie på AI-genererad kod. Jag tycker någonstans det är rätt fascinerande att med all AI-assisterad programmering så fokuserar vi jättemycket på att hjälpa oss att skriva kod snabbare Vi automatiserar kodskrivningssteget. Men tittar man på vad vi utvecklar och spenderar vår tid så är det ungefär 5% av vår arbetsvecka.

Det är inte det som är flaskhalsen utan flaskhalsen är att förstå existerande kod förstå existerande system.

[00:00:32] Sofia: Du lyssnar på Developers, podden där du får följa med oss, Sofia och Madde på allt inom mjukvaruutveckling. Vi träffar

[00:00:40] Madde: spännande gäster, testar nya teknologier, söker inspiration. Och tar upp aktuella ämnen.

[00:00:47] Sofia: Ja, här sitter man i värmen. Jag har en fläkt riktad på mig bakifrån så jag hoppas att den inte blåser in i micken.

Men ja, jag håller på att avlyda lite smått.

[00:00:57] Madde: Samma här, det är galet varmt. Men ja, vi ska se till att det inte blir så lökigt för er att lyssna på i alla fall. Vi har ju en gäst med oss idag som vi tänkte vi hoppar rakt in på det ganska snabbt. Men innan vi gör det så ska vi tacka våra stjärnsupportrar på Patreon.

Så stort tack till Alicia, Anders Nylund, Björn Jonsson, Dag Rönnell, Kajetan Kazimierczak, Lars Nyström, Martin Haagen, Molly Haglund, Oskari, Per Nåtby, Selim Hjorthall, Stygg Hest och Tomas Nilsson

[00:01:26] Sofia: Tack till er och tack till alla andra som stöttar på Patreon. Ja, så idag har vi med oss en gäst som heter Adam och han är programmerare men han har både ingenjörs och psykologibakgrund och han är grundare och CTO för Codescene där han bygger...

Vad ska man säga? Smarta verktyg för att analysera kod. Vi kommer gå in mycket mer på det. Men han är också forskare inom mjukvara och författare till den bästsäljande boken Your Code as a Crime Scene plus tre andra tekniska böcker. Och han är integrär vid rekordbasen och nördar han i sig tydligen i modern historia, musik och kampsport.

Välkommen hit Adam!

[00:02:13] Adam Tornhill: Tack så mycket. Trevligt att vara här.

[00:02:15] Madde: Verkligen kul att ha dig här. När vi har diskuterat inför det här avsnittet så berättade jag att jag såg dig på en konferens Beauty in Code. Det är nog tio år sedan nu. 2015 tror jag det var. Precis när du höll taks där om Code as a Crime Scene. Så det är lite kul faktiskt att få prata med dig här också.

[00:02:33] Adam Tornhill: Ja det kan stämma Boken var ju helt ny då. Den kom ut slutet av 2014 tror jag i sån här beta-version och sen släpptes officiellt i samband med en konferens sedan.

[00:02:42] Madde: Jag minns det som ett bra tak i alla fall.

[00:02:45] Sofia: Vi pratade faktiskt om dig också för några avsnitt sedan när vi pratade om att komma tillbaka från föräldraledigheter och sånt om att man kanske skulle lära sig Då var det closure på föräldraledigheten.

Vi såg att du skulle prata om det på Öredöv. Och enligt Stack Overflow-surveyn i alla fall så säger de att man blir rik som ett troll om man kan closure.

[00:03:11] Adam Tornhill: Jag kan ju säga att jag inte är rik som ett troll men jag har haft tio väldigt roliga år med closure. Så jag kan varmt rekommendera det.

[00:03:19] Madde: Man ju vara rik på annat än pengar.

Man är rik på glädje och erfarenhet.

[00:03:23] Adam Tornhill: Och programmeringsupplevelser.

[00:03:25] Sofia: Mm. Man kan bli rik som ett troll på COBOL också, men det kanske inte är det som är det roligaste att kåda i.

[00:03:32] Adam Tornhill: Jag tog faktiskt några veckor förra sommaren och lärde mig COBOL.

[00:03:37] Sofia: Asså? För

[00:03:38] Adam Tornhill: jag var väldigt, väldigt nyfiken på varför det har lyckats hänga kvar.

Jag kan bekräfta från förstahandsinformation att Clojure är betydligt roligare.

[00:03:46] Madde: Ja men bra att veta ifall vi får för oss att vi ska testa något annat program i en språk Då väljer vi kanske Clojure framför COBOL. Ja.

[00:03:53] Sofia: Men du har ju verkligen hamnat i kodkvalitetsträsket och varit där väldigt länge. Hur kommer det sig att du brinner så himla starkt för det och bara fortsätter och har byggt företag på det och forskar inom det och skriver böcker inom det?

[00:04:08] Adam Tornhill: Det korta svaret är att anledningen till att fokuserar så mycket på kodkvalitet är för att det är otroligt viktigt, inte bara för oss som utvecklare utan också för Businessen och för management och företagsöverlevnad. Det mycket längre svaret är att jag hamnade av misstag eller jag fick de här insikterna av misstag.

Jag jobbade i slutet av 90-talet på ett stort programutvecklingsföretag. Vad jag märkte var att det var otroligt svårt att lyckas med mjukvara. Vad jag menar med det är att varenda projekt jag såg det levereras sent eller det hade bristfällig kvalitet eller vi lyckas inte implementera allt vi hade lovat.

Jag började helt enkelt fundera på varför det är så svårt att lyckas med mjukvara. Jag hittade inte riktigt svaren inom programvaruutveckling så jag bestämde mig för att göra något annat. Jag bestämde mig för att bara plugga psykologi. Så jag halkade in på det spåret att jag tänkte om jag kan förstå psykologi för det är ju trots allt hur vi tänker och resonerar och löser problem och samarbetar med andra så borde jag få bättre insikt i mjukvaran Så på den vägen var det och det upptäckte jag ganska snabbt.

I början fokuserade jag väldigt mycket på kognitiv psykologi som handlar om våra tankeprocesser och problemlösning. Vad jag ganska snabbt märkte var att den här frågeställningen jag hade, varför är det så svårt med mjukvara? Ja, det var ju intressant men det var egentligen en helt fel fråga att ställa.

För ju mer jag lärde mig om kognitiv psykologi desto mer insåg jag att den mänskliga hjärnan inte är anpassad för programmering överhuvudtaget. Vi

[00:05:37] Madde: har

[00:05:39] Adam Tornhill: så enormt många kognitiva flaskhalsar. Vi har ett arbetsminne där du effektivt kan resonera kring tre, fyra saker. Men bara tänk på senaste klassen vi designade Hur många instansvaror hade vi där?

Fler än tre då vi röt. Så någonstans tänker jag mig att rätt fråga att ställa är varför har det möjlighet att programmera överhuvudtaget? Vad gör vi för att klara av det? Och tänker man där så hamnar man ganska snabbt i vikten av kodkvaliteten

[00:06:05] Sofia: Jag hade nog aldrig hamnat i att jag hade kommit på att jag skulle plugga psykologi om jag såg problem i mitt mjukvaruprojekt.

Eller absolut så här, om man ser att det är problem i teamet, att det är mer att det skär sig mellan utvecklare och så. Men det är väldigt speciellt. Ja, eller även typ UX

[00:06:24] Madde: kan jag tänka är lite mer så här beteendevetenskap och psykologi och sånt. Och ledarskap Inte för kodkvalitet. Nej. Det är väldigt intressant.

[00:06:33] Sofia: Men okej så då märker du att kodkvalitet verkar vara det viktigaste för att lyckas leverera i tid. Och de här allra mer typiska problemen som du upptäckte då som fortfarande är kvar. Har det blivit bättre?

[00:06:49] Adam Tornhill: Ja och nej Jag tror, ja på så sätt att det är en stor skillnad nu jämfört med så här förr. 15-10 år sedan jag började prata om teknisk guld och kodkvalitet.

Skillnaden då var att ganska oftast fick jag börja med att definiera vad är teknisk guld? Det visste de flesta faktiskt inte. Idag är teknisk guld ett mainstreambegrepp och vi har givetvis har vi i god tradition stretchat det så långt så det knappt betyder något längre. Men det finns i alla fall en medvetenhet om det.

Och jag tror att allt det som händer nu med AI, det sätter ju någonstans fingret på otroligt viktigt. Det är Med kod av hög kvalitet. Så jag tror att vi är på rätt spor. Däremot så ser jag fortfarande att väldigt många företag har en utveckling som är betydligt dyrare och betydligt mer riskfylld än den skulle behöva.

Så det är min uppgift i livet att försöka belysa de områdena.

[00:07:45] Madde: Ja, jag tror att många likställer ju ofta teknisk skuld och lägga sig typ att så fort någonting är lite äldre så är det en teknisk skuld och så behöver det ju verkligen inte vara. Det kan ju finnas jätteresilenta system som är äldre och det kan finnas nybyggda som definitivt har tagit genvägar.

Men hur skulle du då definiera vad är bra och dålig kod liksom?

[00:08:07] Adam Tornhill: Ja, vad bra och dålig kod. Det är superintressant. Det jag tog med mig inför utompsykologin var att en av mina absoluta favoritböcker när jag växte upp när jag var tonåring var en bok som heter Sennan Dart of Motorcycle Maintenance. Det är en rätt så känd bok, men cover storyn där handlar om en professor som blir galen genom att försöka definiera kvalitet.

Där vill jag inte hamna, så jag plockade inspiration från ett annat psykologiområde Det är faktiskt attraktionspsykologi. Det låter ganska yda, men det är ett superintressant område när man tittar närmare på det. Vad jag speciellt tog med mig därifrån är att attraktiv kod hälsosam kod, det är egentligen en kod som saknar fulhet.

Det låter som ett cirkulärt resonemang men vad det egentligen betyder är att vi som utvecklare kan ganska ofta enas om vad dålig kod är. Till exempel upprepad copy-paste, djupt nästlad logik, låg korrektion, det vill säga vi har tryckt in 30 saker i samma fil. Det kan vi alla enas om, men vi kommer aldrig kunna enas om vad bra kod är.

Så det är så jag har approachat kodkvalitet, jag har definierat kodkvalitet som avsaknaden av kodsmälls av dålig kod Och det är det vi har byggt upp vårt kodalf-mått kring.

[00:09:33] Sofia: Det är faktiskt sånt Det är lätt att enas om det här ser ut som att vara riktigt fin .net-kod eller Java-kod Vi vet typ hur en sån ser ut.

Men är det inte svårt ändå När man ändå ska kvantifiera det sen i era verktyg som man bygger. Alltså är det då att vi ska titta efter solid-principerna och vi ska titta efter dry och kiss. Men

[00:09:59] Madde: det var väl snarare tvärtom, att titta på avsaknaden av dålig kod. Eller missuppfattar jag det?

[00:10:04] Sofia: Ja, eller jag kanske inte heller förstår.

Hur listar man de reglerna i ett system som sedan ska kolla efter den dåliga koden eller den bra koden

[00:10:15] Adam Tornhill: Vad vi egentligen gör är att vi utgår från att koden är perfekt. Det är utgångspunkten. Sen så försöker vi bevisa motsatsen. Och det gör vi genom att testa. Det finns i alla fall 25-26 stycken regler vi testar då.

Och en del av dem kan vara saker som single responsibility. Andra kan vara relaterade till användandet av logik och branscher och så Kodduplikation och ju mer av de här problemen vi hittar desto sämre kodhälsa och ju djupare problemen går desto sämre kodhälsa sen så finns det ju såklart intressanta aspekter på det vad jag ofta märker när jag pratar med utvecklare kring detta är att vi tenderar att enas kring majoriteten av de här kodhälsoreglerna men det finns alltid några som är mer subjektiva till exempel på långskannfunktion där kan vi ha en ändlös debatt ju

[00:11:10] Sofia: Det beror verkligen på vilket språk man kodar i också.

Skiljer ni också på språken och hur typ stilarna i de språken är?

[00:11:18] Adam Tornhill: Ja, precis. Det är jätteviktigt. Om vi har ett språk som är golang, som är relativt robust, då får man naturligt lite längre funktioner Men i Clojure till exempel, 50 rader kod är en evighet. Det är ett halvt system i Clojure. Där vill man ha mycket kortare och minimalistiska funktioner.

Så det finns absolut en språkkomponent.

[00:11:42] Sofia: Jag kan tänka mig att det blir mycket diskussioner internt hos er också. Vad som är bra och dåligt för alla utvecklare kommer från lite olika bakgrunder kanske. Eller är ni helt överens alltid om vad som är fin och inte fin kod?

[00:11:58] Adam Tornhill: Nej vi är inte helt överens för det finns alltid kontextuella undantag såklart Men vad som har varit viktigt för mig egentligen från dag ett när jag började jobba med detta, när jag började jobba med CodeSyn, det var att vi visserligen är ett akademiskt företag Vi tror väldigt mycket på den vetenskapliga metoden.

I stället för att vi sitter och har en massa subjektiva uppfattningar så är det viktigt att mäta och faktiskt bevisa att sakerna fungerar Så sättet vi har utvärderat de här olika faktorerna och kodehälsmåttet på det är genom att koppla till saker som faktiskt betyder någonting som utvecklingshastighet.

Kan vi förstå koden snabbare och därmed snabbare implementera en feature? Levererar vi färre buggar om koden är hälsosam versus om den inte är det? Så på så sätt har vi kunnat validera reglerna och se att det vi mäter faktiskt har en mening och en impact på riktigt

[00:12:55] Madde: Som du säger, många är ju överens om de här kodsmälsen så att säga.

Hur kommer det sig att vi skriver så dålig kod? Alltså utvecklar vi inte fulländare? Jag vet ju själv, man hamnar ju i kodbaser som är i bästa fall är de ju okej i vissa fall är de direkt undermåliga. Vad är det som gör att man hamnar där?

[00:13:16] Adam Tornhill: Jag tror det finns många olika förklaringar. En anledning är att med mjukvara så För det mesta av tiden så löser vi problem för första gången.

Så mjukvara är ju inte som ett sånt här assemblyband utan vi löser nya problem. Och det gör vi iterativt för så fungerar mänsklig problemlösning. Så vi behöver prova oss fram. Det kan visserligen vara snabba cykler och effektiv utvecklarmetodologi bygger mycket på det. Att hålla väldigt korta kontinuerliga cykler, till exempel TDD.

Men det gör ju också att vi ibland... Har kört på fel spår och nu måste vi backa. Och där behöver vi ha disciplinen och faktiskt slänga kod även om vi har lagt vår själ i det. Och det kan vara väldigt väldigt jobbigt. Ja, det kan vara jobbigt. Det tycker jag också. Det är jobbigt, men det är rätt sak att göra.

Sen tror jag också att det finns... Det är trots allt så om vi tittar på, ni nämnde Stack Overflow innan tittar man på deras service så ser man att ganska många utvecklare är relativt juniora Vi har kanske bara jobbat ett par år i industrin Och i alla fall för mig det tog ganska många år innan jag greppade programmering.

Jag tror helt enkelt att mjukvara är otroligt svårt Vi behöver tid, vi behöver bra mentorer, vi behöver bra utbildningar och böcker att lära från. För det är komplext att skriva kod överhuvudtaget.

[00:14:36] Sofia: På något sätt känns det som att man aldrig blir bättre på det med tiden heller För att det är fortfarande att den kod man skrev igår är skit idag.

Ja

[00:14:48] Madde: men det är alltid nya domäner och allt sånt också. Det är ju så mycket komplexitet som kommer som inte bara har med koden att göra dessutom. Och sen lite tidspress på det också så är man ju

[00:14:56] Sofia: rökt. Ja så blir man ju bättre och bättre på att se allt det dåliga man gjort. Genom tiden. Så det är på något sätt så att allt man gör blir värre och värre.

Men Jag är också nyfiken på, för jag har hört dig prata på konferenser och så förut och då pratar du ofta och hänvisar till forskning och också forskning som du själv gör tillsammans med, jag kommer inte ihåg namnet.

[00:15:21] Adam Tornhill: Doktor Marcus Borg.

[00:15:23] Sofia: Marcus Borg, kan inte du berätta lite om vad det är ni gör? För det är ganska lite forskning annars tycker jag i mjukvaruutveckling.

Vi faller ofta på lite service och artiklar som enstaka jättesmarta programmerare har gjort. Men det är väldigt sällan det är riktig forskning. Så vad är det ni gör?

[00:15:43] Adam Tornhill: Nej, precis. Det är ju anledningen till att vi... Vi gör den här forskningen att mjukvaruindustrin vi har väldigt många åsikter och vi är väldigt subjektiva.

Vi har många best practices som vi inte har utvärderat överhuvudtaget. Så vad vi gör är att vi samlar in den typen av data vi har tillgång till. Och det handlar dels om kodkvalitetsdata som vi mäter med CodeHealth, men det handlar också om data som vi kan få igen och samköra versionshanteringsdata med verktyg som Jira eller Azure DevOps.

När man har produktplaneringen. Och genom att koppla ihop den här datan så kan vi då få räkna ut till exempel ledtider för att implementera ny feature. Vi kan också se vilken typ av jobb som görs Till exempel är det en bokfix eller är det en ny feature eller någon rework vi gör. Det kan vi också se till exempel i IRA.

Och genom att bara samköra de här metrikerna så kan vi då hitta de här olika korrelationerna till exempel att ohälsosamt kod är Upp till tio gånger så långsamt att arbeta med, som hälsosamt kod. Genom att ha de sambanden så blir det också mycket lättare för oss som utvecklare att komma till vår manager och säga att den här koden vi bör refaktorisera den, och gör vi det så kommer du bli tio gånger så snabb med alla de här featuren du har planerat i din roadmap.

Så det finns en return on investment även för produktorganisationen och för management. Det tror jag är jätteviktigt för att Vi ska få den tid och prioritet som det här arbetet kräver.

[00:17:11] Sofia: Vad tror du är de vanligaste misstagen som just ledare och managers och organisationer i stort gör?

[00:17:20] Adam Tornhill: Oj, det finns en del.

[00:17:23] Madde: Renta på.

[00:17:26] Adam Tornhill: Vi ska börja med kanske absolut vanligaste. Det är att vi ofta är ganska blinda. Till hur mycket teknisk skuld kostar oss. Och det är egentligen inte så konstigt för om man tänker sig synbarheten så vad alla ser i en organisation det är produktens features och capabilities och UI. Det är väldigt lätt att ha en åsikt kring.

Det är väldigt lätt att sätta värde på en ny feature. Du kan få ha en kund eller en marknad som är i skriande behov av en viss feature. Så du vet att om jag gör den här feature så får jag ett antal fördelar Och så fort du har gjort featuren så ser du de här fördelarna komma så det är väldigt lätt att prioritera den typen av arbete.

När det kommer till teknisk skull så går det inte att se om du inte själv är tekniker och kan promenera genom koden och det gör ju att det är väldigt lätt att bortse från det. Så även om vi ser symptomen att vi blir långsamma vi är oförutsägbara så är det väldigt svårt att ge prioritet till någonting du inte kan se och kanske inte ens fullt ut förstår Där tror jag att vi som utvecklare har jätteansvar att lyfta upp och kvantifiera teknisk skuld och impacten till management.

Min förhoppning är att den typ av verktyg vi gör kan hjälpa med just den uppgiften. Så det är ett exempel.

[00:18:46] Sofia: Där vill jag tillägga att precis som att en manager inte kan kolla på koden och bedöma den, Så är det ju också en skill som vi som utvecklare behöver ha att även vi ser kanske att kod är dåligt men vi kan inte heller avgöra om den bör skrivas om, för vi Vi måste kunna domänen och förstå businessen för att se hur kritiskt det är att vi underhåller just den delen.

Så jag och Madde pratar ju ofta om det, att vara en bra utvecklare är inte bara att skriva kod du måste förstå verksamheten verkligen. För annars är det lite svårt att argumentera för att skriva om någonting. Det kanske ser skit ut, ja, och så är det en person som använder den biten av kod. Då är det inte så värdefullt att skriva om det kanske.

[00:19:28] Adam Tornhill: Jag håller med till 200%. Det är jätteviktigt att förstå domänen. För det är ju egentligen där man kan göra de absolut största optimeringarna. Förstår man domänen riktigt väl ut så ganska ofta finns det kod man kan radera. För den behövs helt enkelt inte. Det är den absolut bästa koden vi kan ha den vi kan delita.

Sen handlar det också om kodkvalitet och du är inne på det där att kodkvalitet är mer eller mindre betydelsefullt baserat på kontext. Så du kan ju ha kod vi pratade lite om läggas innan du kan ju ha kod som är av låg kvalitet, det är ohälsosam kod rent objektivt Men det är kod som varit stabil i produktion, fungerat fantastiskt under fem år, du behöver aldrig röra den.

Är det då egentligen akut? Nej det är det ju inte, det är teknisk guld men den har extremt låg ränta Så den aspekten tror jag också är jätteviktig att väga in och väga in relevansen och impacten av kodkvalitetsproblemen.

[00:20:22] Madde: Det är ju ett jätteintressant mått faktiskt att ha, hur mycket ränta den kostar.

Det har jag inte alls tänkt på innan att det kan vara högre ränta på vissa saker. Vad blir slutändan i kronor liksom?

[00:20:32] Adam Tornhill: Ja precis och den ränteaspekten är ju helt osynlig i själva koden. Från koden kan vi bara avgöra om den är bra eller dålig men vi vet inte impacten av det. Då behöver vi titta på en annan typ av data för att kunna kvantifiera det.

[00:20:45] Sofia: Fler misstag idag. Du vill bara höra ämnska historier. 90% av dem som lyssnar på den här podden är utvecklare och de flesta har jobbat i mer än 10 år och vi vet så att folk väntar.

[00:20:59] Adam Tornhill: Jag har ju en speciell position. Jag har ju Jag har jobbat som manager i många år men jag skriver fortfarande kod så jag kan ha båda hattarna.

Men jag kan ge ett annat ganska vanligt exempel. Det är att man behandlar organisationen och systemet alltså människoorganisationen och systemet som två helt separata och parallella system. Det blir ofta problem. Ett ganska konkret exempel är för 6-7 år sedan så blev det väldigt populärt med featureteams.

Man ville bygga upp team som kunde ta ett helhetsansvar från Feature och det är väldigt praktiskt. Problemet då är att man kan inte ta sin existerande organisation så att det är organiserat traditionsenligt med kanske ett databasteam och så ett backendteam och så ett frontendteam och så splittrar du upp det i I ett antal feature-teams och så släpper du loss dem på features.

Vad som händer nu är att du har en obalans i ordet organiserad versus vad din arkitektur kan stödja. Och det gör att ganska snart så hamnar utvecklare från olika team i samma del av koden och ändrar koden men i olika riktningar för de jobbar på olika features. Och det som händer är att ganska snart så kommer du märka att du får enormt mycket defekter.

Du spenderar enormt mycket tid på att hantera de här kodkonflikterna. Du sitter med komplexa merches och komplexa kodgranskningar. Din kalender fylls upp, har läknat schackbräd och det står synkmeeting på allting. Så... Det där är ett jättevanligt problem och igen är det svårt att förklara det för arkitektur är också något som inte är så supergreppbart.

Vi kan rita upp våra boxar och så men det inte mycket till arkitektur.

[00:22:42] Sofia: Det här känner jag igen väldigt mycket som en som precis startat upp ett produktteam som helt plötsligt ska äga allt från frontenden ner till databas och det kan vara väldigt svårt då. Kommunicerad. Vi måste fortfarande ha en arkitektur som hänger samman i lagren så vi inte bryter kontrakt.

Det

[00:23:06] Madde: är lite det. Conway's law. Att koden blir ju byggd enligt den organisationen du är i. Och har man då tidigare haft en organisation som är så separerad i databasteamet och frontendteamet, då blir det väldigt svårt att visera dig att du ska jobba vertikalt plötsligt för att Det stödjer ju inte det alls.

[00:23:24] Adam Tornhill: Ja, det finns ju många relaterade problem till den organisatoriska aspekten Jag tror att en av de stora tragedierna i mjukvaruvärlden är att organisationen vi utvecklar som bygger koden vi är osynliga i själva koden. Och man kan aldrig egentligen resonera kring hur effektivt ett system är att bara titta på en statisk snapshot of code, man måste förstå det historiska kontextet så jag kan dra en historia jag var i för några år sedan i Tyskland, jobbade med ett företag gjorde en analys av deras kodbaser för att hjälpa dem att prioritera teknisk skull och bli effektiva vi analyserade två stycken kodbaser åt dem och vi hittade en del problem vi diskuterade en actionplan Och sen nämner en av våra utvecklare att vi har en tredje kodbas också.

Så jag sa okej ska vi titta på den då? Nej, det behöver inte göra, menade de för att den har så otroligt låg kvalitet. Jag sa, ja men, det kan ju hjälpa till extra mycket, så vi måste absolut titta på den. Så vi gjorde det. Och det visade sig att om vi tittar på kodhälsomåten så är den här tredje kodbasen precis lika bra som de andra två, rent objektivt Det var ju ganska förvånande för teamet Vi spenderar mycket tid att kika på kod och diffa exempel och få övertyga.

Sen slog det mig att det är nog någonting annat bakom det här. Och när jag frågade teamet så visade det sig att den här kodbasen var skriven av ett helt annat team, till och med en annan världsdel och det teamet hade blivit nerlagt och de hade fått arva kodbasen. Så anledningen till att de tyckte att den var svår att förstå det hade inget att göra med själva koden utan det var helt enkelt som ni var inne på innan avsaknaden av domänexportis och kunskap Och har man inte den rätt typen av information, om man inte gör en sån här root cause-analys, så kommer man att resera fel problem.

För det hade varit väldigt, väldigt lätt att slösa bort ett år på en omskrivning som inte hade hjälpt. När teamet egentligen behövde en schysst handover och en onboarding.

[00:25:17] Sofia: Det här har man verkligen sett. Det räcker med att ett annat team har skrivit det. Och särskilt om det är i ett annat språk då vill man väldigt gärna skriva om det.

I sitt favoritspråk i sitt favoritramverk för då tror man att det kommer gå så snabbt vi bara migrerar allting till väldigt favoritspråk så blir det jättebra.

[00:25:38] Madde: Och det är det jag tror är så farligt också för det det som har gjort eller jag tror att det har gjort att många managers är så tveksamma till att våga betala för de här refaktureringarna som krävs eller omskrivningarna för att de ser bara här shit, vi måste skriva om allt från scratch det kommer bli skitdyrt.

När det i själva verket handlar om att vi som utvecklare vi behöver ju lyfta fram och göra de här omskrivningarna när det faktiskt verkligen behövs. Inte bara av bekvämlighet eller för att man tycker det kul med det nya, senaste hetaste. Så att vi skjuter oss själva lite i fötterna kanske. Ja, det

[00:26:11] Sofia: är klart de inte litar på oss.

Särskilt managers som har varit utvecklare förut som vet. Ja, de vet exakt. Det är därför

[00:26:17] Madde: det är så bra att ha sådana här objektiva verktyg tänker jag. Då får man ju verkligen svart på vitt. Mm.

[00:26:21] Sofia: Mm Men där kan man också bli lite lurad, tänker jag. Det finns ju så många verktyg som inte heller förklarar hela sanningen.

Det känns också svårt. Jag kan tänka mig, Adam, att ni också får utvecklare som inte vill bli mätta på det sättet.

[00:26:40] Adam Tornhill: Ja, det stämmer ju absolut. Det finns ju rena micromanagement-verktyg också där ute. För oss är det viktigt att hjälpa organisationen på allvar, vi mäter aldrig individer, jag tror det är fel nivå att mäta på, jag tror till och med det är farligt och kontraproduktivt.

Jag vet själv att om jag mäts på någonting så kommer jag optimera för det och det kommer jag göra på bekostnad av andra saker vilket skulle till exempel kunna vara att hjälpa en kollega eller skriva en gemensam dokumentation. Jag kommer att fokusera på mig, inte på teamet. Så vad vi gör på kodsen är att vi mäter inte individer men vi mäter team.

För det tycker jag är fair att göra och det tror jag är hjälpsamt för organisationen också.

[00:27:22] Madde: Det skulle kännas väldigt jobbigt om man får veta att nu står du här för 80% av alla nästlade if-satser som inte går att läsa. Det är väl bra i och för sig att bli medveten men man kan ju faktiskt göra det på ett annat, lite mer helikopterperspektiv Så att inte blir så himla utpekande mot en specifik person.

[00:27:41] Sofia: Det kan man göra lite privat kanske i ens... Alltså att man får någon, att man har någon linter i en CD eller att det syns bara på en spullrequest så att det är lite skyddat inom teamet. Men på tal om det så är det väl någonting som ni typ nyligen har utvecklat, ett plugin till ens ID?

[00:28:03] Adam Tornhill: Ja, det stämmer. Vi ville komma mycket, mycket närmare och utveckla så man kan fånga problemen direkt när man inträffar.

Och också då faktiskt fungera som just den här lärande feedback loopen vi pratar om. Så vi har utvecklat ID extensions och... Jag använder dem själv och det gör att jag i realtid kan direkt se hur jag påverkar kodhälsan. Och det är speciellt viktigt när jag kanske gör lite större ändringar eller om jag skriver helt ny kod.

Då vill jag veta det. Men sen också såklart nu, om man ser den trend och hype som pågår nu kring AI-assisterad kodning. Så det enda vi kan vara säkra på är att vi kommer skriva mer kod än någonsin tidigare de närmaste åren. Och då är ju väldigt, väldigt viktigt att all den koden som genereras är hälsosam.

Så därför tror jag att den här realtidsfeedbacken på kodehälsa kommer vara helt avgörande

[00:28:55] Madde: Ja, det är någonting vi verkligen har sett nu med alla vibe-coding och liknande. Att koden är ju oftast inte den bästa. Den kanske fungerar för ett väldigt specifikt scenario. Men det är sällan de har edge-cases och liknande.

Och kanske väldigt dålig säkerhet och liknande. Har ni kunnat se någon nedåtgående trend eller liknande i kodkvalitet? Eller ni kanske inte mäter så på det stora hela?

[00:29:18] Adam Tornhill: Vad vi har gjort är att... Jag och mina kollegor gjorde en ganska stor studie på AI-genererad kod. Och vad vi specifikt studerade var refactoring.

För jag tycker någonstans det är rätt fascinerande att med all AI-assisterad programmering så fokuserar vi jättemycket på att hjälpa oss att skriva kod snabbare Vi automatiserar kodskrivningssteget. Men tittar man på vad vi utvecklar och spenderar vår tid så är det ungefär 5% av vår arbetsvecka. Det är inte det som är flaskhalsen utan flaskhalsen är att förstå existerande kod, förstå existerande system.

Så därför är jag så intresserad av refactoring för kan AI hjälpa oss att refactorisera så kan det också hjälpa oss att göra koden lättare att förstå och automatiskt betala av teknisk skuld. Men vad vi såg ganska snabbt när vi studerade de LLM som fanns på marknaden i vår studie det var att de Tar sönder koden eller gör en sämre mer ofta än de faktiskt löser problemen.

Vi hade failure rates på 60-70%. Det vill säga i majoritet av alla fall så kommer AI ge dig kod som antingen är sämre eller inte fungerar.

[00:30:28] Sofia: Så det var ett deprimerande

[00:30:29] Adam Tornhill: start.

[00:30:30] Sofia: Ja. Man märker det på något sätt att förslagen man får är ju Väldigt tränade på exempel som finns i publik dokumentation och det är väldigt förenklat och de förstår ju fortfarande inte ens domän och löser problemen på ett krångligare sätt än vad det skulle behöva vara ibland tror jag men det är klart de kommer ju bli bättre och bättre men jag upplever, kanske jag vet inte om det var det du sa men de är ju De är väldigt riktade mot att använda LLM för att skriva ny kod, men inte så mycket bearbeta det vi redan har.

Och för ny kod så är det asgött, alltså för någon som mig som är skitdålig på att komma igång, det är jättetrevligt. Men det tar en inte vidare Men innan vi går in på AI för mycket, för jag tänker att vi ska prata om det lite mer sen. Vi har rantat om managers i lite organisationer men jag vill bara höra lite om, i och med att du sitter på båda stolarna, vad är de vanligaste misstagen som utvecklare gör?

För vi pratar om kodhälsa och kodkvalitet hela tiden. Men det också vi som skriver all skit i kod. Även de bästa av oss skriver riktigt dålig kod.

[00:31:54] Adam Tornhill: Ja, det stämmer. Och jag tror allt för ofta så skyller vi på management trick. Men jag tror ett av de vanligaste fel vi gör som utvecklare det är att vi gör lokala optimeringar men orsakar global skada.

Och vad jag menar med det är att vi kanske har... Vi kan få feedback från en kollega i en kodgranskning att det här skulle behöva struktureras annorlunda. Eller de här tre funktionerna skulle kunna använda det här approachen istället Kanske redan finns något liknande. Eller har vi verktyg som meddelar oss att den här koden har brister och du bör göra det annorlunda.

Men om vi kör de här verktygen för sent eller vi har en kodgranskning som händer i slutet så blir det jobbigt för mentalt är vi redan färdiga med uppgiften. Och så känner jag att det kommer ta mig 20 minuter att fixa det här. Jag vill ju hoppa vidare på nästa uppgift. Men vad jag kanske missar är att det tar mig 20 minuter men om jag inte fixar så kostar mina kollegor 20 timmar.

Det är det jag menar, att det är väldigt lätt att se sin lokala del och optimera från den, men missa hela teamet och hela organisationen och impacten vi kommer ha. För kod skrivs en gång men vi kanske läser 200 gånger bara en produktcykel. Något jag också tror är relativt vanligt är att vi slutar vara nyfikna.

Många som blir programmerare, i alla fall traditionellt blev det för att man tyckte det var kul att jobba med helt enkelt. Någonstans är det kanske lätt att bli bekväm när man känner att man kan lösa de flesta problemen nu. Jag får alltid ihop koden oavsett vilken uppgift det är. Men programmering är ett område där, enligt min bedömning, man aldrig blir färdiglärd.

Jag har kommit i 30 år och jag finner fortfarande att lära mig något nytt nästan på daglig basis. Jag tror det är jätteviktigt att fortsätta ha den nyfikenheten fortsätta fördjupa sig, lära sig nya språk lära sig nya paradigmer. Lära sig språket man programmerar till full och förstå standardbiblioteket.

Titta på andra utvecklar metodologi jag har aldrig gjort TDD så det är väl värt att prova ett exempel det tror jag är jätteviktigt mentaliteten med kontinuerligt lärande och det är klart att det kan vara jobbigt jag tror inte någon orkar med att göra det dagligen men jag tror det är viktigt att ha någon form av kontinuitet i sitt lärande För det är ett område som rör sig snabbt också.

[00:34:26] Sofia: Är det viktigt för kodhälsa att man läser till exempel på om nya features i sitt språk och språk Jag säger att det har kommit records i det språket man använder, är det liksom viktigt att man tar in det i sin kodbas för att det faktiskt är någonting som påverkar kodkvaliteten för jag vet att vissa argument är att nej men skriv inte om det för att jag vet inte jag har hört argument om att det tar bort historiken om du bara skriver om allt det här och nej det finns inga gains med till exempel att använda Record istället för vanlig klass med getters och setters överallt Att det finns många som tycker man ska låta det vara det som fungerar.

[00:35:14] Adam Tornhill: Ja, och det är ett ganska vanligt argument. Jag tror också att det finns inget självändamål i att ändra kod bara för sakens skull. Men däremot... Om jag arbetar aktivt med kol så tror jag att en del av min skyldighet är att försöka förbättra den och göra det bästa jag kan göra. Ju större min verktygsbox är, ju mer jag kan av standardbiblioteket och principer och designteknik desto enklare blir det jobbet.

Och ganska ofta när man behärskar ett språk till full då så kan du ta 30 rader kod och ersätta det med ett enkelt androk till ett standardbibliotek. Och det är en jätte, jätte vinst för allt det där är kod som du inte längre behöver underhålla eller förstå. Och det är det jag menar med ett kontinuerligt lärande För att det ska fungera så behöver ju resten av teamet förstå vad koden gör.

Men jag tror även i ett större perspektiv vi pratade innan om att lära sig domänen och så. Och det Det är någonting som jag tycker är minst lika viktigt som programmerare att ha en jättebra förståelse. Jag brukar alltid rekommendera att vi utvecklar, vi ska träna som slutanvändare. För jag tror har vi den förståelsen så skriver vi bättre kod och vi gör mer effektiva lösningar.

[00:36:22] Madde: Man får ju ett helt annat perspektiv när man sätter sig i de skorna.

[00:36:25] Adam Tornhill: Ja, och det kan vara ett obehagligt perspektiv ibland också.

[00:36:29] Sofia: Säkert. Hur mäter ni då kodkvaliteten mer specifikt? För jag tänker, i många typ så här... Böcker om tekniskt redarskap som jag läser så har det varit att man kan till exempel mäta antalet buggar, det är jättebra om nästa månad så har antalet buggar gått ner men det känns väldigt reaktivt det är bara resultat av vad du redan har gjort man kan jobba mer proaktivt kring det ja precis, mer proaktivt

[00:37:03] Adam Tornhill: Det är klart att det är viktigt att mäta trender till exempel i post-release-effekter.

Det gör vi också internt på CodeSyn. Men det är ju ännu viktigare att kunna vara proaktiv. För så kan vi ha en riktig skillnad. Så vi mäter ett antal olika grejer. vi har... Givetvis högnivå KPI och på kodbasnivå där du kan se var befinner man sig i kodhälsa, hur illa är det? Men ännu viktigare att se trenden, vart är jag på väg?

Blir koden bättre eller sämre? Så det är alltid vad jag rekommenderar som steg noll när man börjar hantera teknisk skuld att lägga en kvalitetsriba på det du redan har. Gör det inte värre, det är det absolut viktigaste. Men sen har vi också... Visualiseringar vilket jag tror är jätteviktigt Vi visualiserar kompletta mjukvårdssystem.

Vi försöker visualisera dem som kartor Så att man kan förstå dem även som icke-tekniker. Vi visualiserar ut kodhälsan som gult rött eller grönt. Så man direkt kan se var är problemområdena var är de områden koden som är under god kontroll där vi kan sätta full fart. Och kanske viktigast av allt så försöker vi göra det här actionable genom att lägga på ett organisatoriskt perspektiv och verkligen mäta vad vi har jobbat som utvecklare.

Det är det jag kallar hotspots i Your Code is Crime-syn. Och om vi då kan hitta överlappet mellan dåligt skriven kod som vi jobbar med ofta då har vi prioriterad teknisk skuld som påverkar oss just nu och som vi behöver agera på.

[00:38:36] Madde: Så

[00:38:36] Adam Tornhill: det är en av de saker vi gör.

[00:38:37] Madde: Det låter ju riktigt

[00:38:39] Sofia: nice. Alltså det här skulle jag ju vilja prova.

Det känns som att när man har sett dig visa de här, om du säger att det är en karta. Det ser ut som ett neuralt nätverk det ni visar och så blir det helt rött där det är riktigt illa. Så fort folk ser det så blir de så här, vart kan jag testa det här på min kodbas? Och jag vet ju att våra lyssnare kan få göra det här va?

För du har någon trial med dig.

[00:39:06] Adam Tornhill: Ja det har jag. Det är helt gratis att testa. Det kommer finnas en länk men det är egentligen bara att gå in på codesyn.com och starta trial. Det kostar ingenting och så kan man mäta och visualisera sin kodhälsa och se vilka insikter man kan dra av det. Och är man intresserad så kan man givetvis koppla in automatiska kodgranskningar och få alla infon i pull request eller direkt i sin ID.

[00:39:31] Madde: Ja gud vågar man det? Nej, det är hellre att vara medveten om det, så man vet vad man kan förbättra. Man ska inte vara struts och bara gräva ner huvudet i sanden, låtsas som att det inte finns.

[00:39:42] Sofia: Ja, det kan vara läskigt men det är också ganska kul när man väl ser det för det behöver inte betyda att det är värsta svåra kodändringarna, men det blir så...

Det blir ett så enkelt verktyg också för att lyckas argumentera för att skriva om en del av kodbasen.

[00:40:01] Madde: Vi började ju prata lite om AI. Du berättade ju det här att vi såg att det var en väldigt hög fill rate på AI. Hur tycker du vi som utvecklare ska ställa oss kring AI? Är det liksom big no-no-användare eller har vi som mer seniora utvecklare kanske lite, vad ska man säga, att vi borde coacha nya utvecklare hur man använder AI?

[00:40:22] Sofia: Och jag undrar också Adam, jag tror du har nämnt att du har en son som kodar AI Och det är intressant att höra hur du tänker också kring när han skriver sin kod om han kan använda AI-verktyg eller om du svarar nej du ska lära dig det här från scratch.

[00:40:39] Madde: Det behövde vi göra på min tid.

[00:40:44] Adam Tornhill: Riktigt så illa är det ju inte.

Jag ska berätta lite mer om det, men... Jag tror när det gäller AI så är jag ingen AI-motståndare Jag använder själv AI. Vi bygger en AI-produkt på Codesyn ett automatiskt refactoring-verktyg Så jag gillar AI. Jag tror att rätt använt så kan det hjälpa oss väldigt, väldigt mycket. Och det

[00:41:05] Sofia: är inte bara för att alla företag måste säga AI, för annars är det ingen som köper ens grejer.

[00:41:12] Adam Tornhill: Nej, det är rätt roligt. produkten vi bygger är egentligen baserat på en vision som en produkt i det vi hade 2017-2018 tror jag. Problemet vi egentligen försökte lösa då det var ju att Codesyn har alltid varit bra på att hitta flaskhalsen och peka ut problemen. Men då är nästa flaskhals är ju då vi som utvecklar och vi som management team måste prioritera och göra något åt det.

Och där kan det ofta stanna då. Och då tänkte vi att kan vi bygga en lösning som automatiskt fixar de vanligaste kodhälsoproblemen Så tog man ju bort den flaskhalsen. Och vi kikade på det redan 2017-2018. Vi hade lite prototyper med machine learning teknik Jag insåg ganska snabbt att det här kommer att bli fruktansvärt dyrt att bygga.

Men sen kom då modern AI med LLM och helt plötsligt så var jag där inom räckhåll. Så det är egentligen en gammal dröm som nu förvarkligas.

[00:42:09] Sofia: Ni hade idén innan det blev hajp då. Innan det blev möjligt

[00:42:13] Adam Tornhill: i alla fall.

[00:42:14] Sofia: Kallade ni det för AI då när ni tänkte på det? Eller pratade ni i termer av machine learning?

[00:42:22] Adam Tornhill: Jag har faktiskt aldrig marknadsfört det vi gör på Codesyn som AI eller machine learning. Och i detta fallet så gick det projekt under interna namnet The Fix-It-Button

[00:42:36] Sofia: Jag gillar det Det är kul för förut var liksom Ingenting var AI, det kanske var på sin höjd Machine learning, men oftast så var det bara features Och nu är Alla de här featuresarna är AI Det är också ett problem

[00:42:50] Adam Tornhill: Mycket AI idag är ju extremt Tun, det är en tun rapper runt en LLM Vad vi såg ganska snabbt Var ju att vi kan inte Vara en tun rapper runt en LLM För de är inte tillräckligt bra Så vi lägger på en massa validering och mekanismer för att försöka göra LLM-erna så deterministiska vi kan.

Men när det gäller AI generellt så förändrar det ju uppenbarligen hur vi utvecklar mjukvara. Eller i alla fall hur vi ser på kodningssteget. Och jag tror att AI rätt använt är ett lyft. Men jag tror att det absolut viktigaste vi behöver vara med oss som utvecklare är, och jag brukar rekommendera det här att Acceptera aldrig kod som du inte fullt ut förstår.

Det tror jag är jätteviktigt och det är sant, även om vi kopierar en för stackar av flow eller om vi använder AI det är superviktigt för att förstå och förståelse det är verkligen A och O när det gäller mjukvara och börjar vi slida på det och bara generera mer och mer kod, då bygger vi ett berg av osäkerhet framför oss och till slut kommer det att kollapsa och ingen kommer att förstå hur vi ska kunna fixa systemet Så jag brukar säga använd AI för att automatisera de här tråkiga enkla uppgifterna som du redan vet hur man ska göra.

Men använd det aldrig för ny problemlösning för då plockar du ut dig själv ur loopen. Och jag tror att det sänker vår innovativa förmåga redan på kort sikt.

[00:44:16] Madde: Nej det är klart det är ju en förmåga att öva upp precis som alla andra förmågor. Så då måste man ju faktiskt göra det också. Inte bara låta ett AI komma på den.

[00:44:24] Adam Tornhill: Ni pratade innan om min äldsta grabbar. Han plogar teknisk linje. Han är precis på att lära sig Python. Vad jag rekommenderar till honom är att försöka alltid lösa problemet själv först. Använd sen AI för att få ett alternativt förslag som du då kan lära dig om att kontrastera de här två problemen Men jag tror speciellt som junior att använda A1 där som är shortcut, det finns redan studier som visar att din inlärning där är extremt låg.

Du slutför uppgiften men du har egentligen inte lärt dig något och då tappar egentligen poängen med en utbildning.

[00:45:02] Sofia: Men det är också det vi ser att de som går och pluggar på universiteten nu, de använder A1 Bara de här AI-verktygen för att generera allting och om alla dina kurskamrater gör det då blir det liksom, det är så man lär sig programmering idag.

Vi har inte riktigt sett effekterna av det än men har du några teorier om vad vi kommer se eller vad kommer hända när alla de kommer ut i jobben?

[00:45:28] Adam Tornhill: Det blir väldigt intressant. Jag tror att AI, om vi använder den för att Och kritisera det jobb vi har gjort så tror jag det är ett fantastiskt användande av AI.

Men om vi använder AI för att shortcut-katta vår inlärning så kommer det ställa till skada. Jag tror att det som kommer hända är att vi kommer få väldigt svårt att bygga mentala modeller av hur mjukvaror egentligen fungerar och hur programmeringsspråken fungerar. Och jag tror att vi kommer få svårt med...

Innovationsaspekten, för väldigt mycket av innovation kommer från att observera en outcome, göra någonting, bygga en riktigt djup förståelse observera hur blir det, lära sig, försöka något nytt och rätt som det så ser man där möjligheten. Jag tror att plockar vi bort det här steget där vi faktiskt måste anstränga oss så kommer någonting att hända rent kognitivt.

Exakt hur illa det blir, det vet jag inte. Men någonstans och det är nog första gången i mitt liv så jag är tacksam att vara så gammal som jag är.

[00:46:31] Sofia: Det känns som att vi som mer seniora utvecklare i fall har en så stor uppgift framför oss också att när vi kommer få in de här juniora kollegorna som pumpar ut kåda de kommer kunna komma igång med sitt arbete väldigt tidigt vilket är ju bra för företagen.

De blir produktiva snabbt. Men att vi hamnar i någon slags... Men kodgranskningspositionen, vi har inte varit det tidigare. Jag tycker det är jättesvårt att sitta och vara i och undra om det är där vi kommer hamna Att bara kontrollera allt som kommer in.

[00:47:04] Adam Tornhill: Det tror jag absolut. Jag tror att det AI leder till är att öka ett fokus på att förstå kod Kontra att skriva den som vi kanske traditionellt fokuserat mycket på.

Och då är vi nästan tillbaka där vi startat. Det gör ju att kodkvalitet är viktigare än någonsin. För om en AI-sportare har en massa kod vill vi vara säkra på att det är kod som är enkel att granska. Lustigt nog så börjar det visa sig att kod som är enkel för en människa att förstå är ofta kod som en AI kan göra ett väldigt bra jobb med också.

Vi ser till och med det i våra egna data som vi samlar in att är koden riktigt riktigt dålig så tenderar vi att få fler AI-handelssignationer och sämre resultat. Så om det finns någonting riktigt riktigt positivt med AI så är det att vi kanske som organisationer och företag börjar ta teknisk skull på allvar och faktiskt veta av den för att kunna AI-säkra våra kodbaser.

[00:48:00] Madde: Ja,

[00:48:01] Sofia: man kan ju verkligen hoppas. Jag tror du brukar också ta upp en studie Var det Microsoft som hade gjort den med GitHub också att man från många av de här stora företagen som bygger AI att man också... Försöker sälja in hur mycket snabbare utvecklarna blir när de använder AI och särskilt så här mycket snabbare blir en senior person och det låter väldigt attraktivt men jag för mig att ni läste den lite mer noga och såg att det där stämmer ju inte riktigt

[00:48:35] Adam Tornhill: Ja, just det.

Jag reagerade på det för något år sedan Jag fick upp på min privata github att du kan bli 55% snabbare med CoPilot.

[00:48:44] Sofia: Just det, så pass. Det var så sjukt Det

[00:48:46] Adam Tornhill: var ett intressant claim. Vi satt oss jag, Marcus och mina andra kollegor, och så läste vi igenom forskningen på riktigt. Det är jättebra forskning Effekten är riktig.

Men precis som alla andra bra forskning så är de väldigt noga med att spesa upp begränsningarna. Så till exempel 55% snabbare. Men om du jobbar på någonting annat än att skriva en webbserver i Node.js i en Classroom-sättning så är det ingen som helst garanterat att det den effekten. Det kan man inte garantera att det generaliserar.

Likaså så såg man att de var 5% snabbare. Det var för väldigt, väldigt juniora utvecklare. För seniora var det betydligt lägre. Det som kanske oroar mig mest med studien är att de också är supertydliga med att de inte har studerat kodkvalitetimpakt överhuvudtaget.

[00:49:34] Madde: Det känns ju som en grej som man verkligen borde ha med sig.

[00:49:37] Adam Tornhill: Den är rätt intressant med tanke på att 90-95 cent av livscykelkostnaden för ett mjukvårdssystem sker ju efter att koden är skriven i första versionen.

[00:49:47] Madde: Ja, det är så otroligt kortsiktigt tänka med att bara tänka att nu ska jag bli snabbare här och nu. Det är inte alls det som är det enda viktiga, tvärtom.

[00:49:55] Sofia: De senare siffrorna har varit mer typ så här att det är någonstans runt 7 procent eller något sånt och det är ju väldigt... Jag kommer inte ihåg om det var det, men det är väldigt mycket ändå men där kanske man fortfarande inte mäter kvaliteten utan bara hur mycket snabbare du blir klar med din uppgift.

[00:50:14] Adam Tornhill: Ja, det är lite vad vi pratade om innan med att optimera för quick task completion versus att optimera för det som är rätt för hela verksamheten

[00:50:24] Madde: Och

[00:50:25] Adam Tornhill: det är mycket möjligt att 7% snabbare, det är mycket möjligt att det är en riktig effekt och det är mycket möjligt att det inte har några negativa effekter och det är ju fantastiskt.

Men därifrån till att ta det till ett läge där vi har maskiner som gör allt jobb som utvecklare, det tror jag är en utopi eller dystopi baserat på vem du frågar. Men jag kan inte se att vi med dagens rödtekniken rent teoretiskt skulle kunna ta oss dit. Och det kommer ju betyda att under de närmaste decennierna så kommer vi ha kod som är skriven av både människor och maskiner.

Och båda måste förstå den. Så igen så tror jag att en av de bästa försäkringarna vi har nu för framtiden är att se till att den kod vi skriver håller absolut högsta kvalitet.

[00:51:09] Madde: Ja, det ska jag verkligen ta med mig. Jag har alltid tyckt att det är klart det är viktigt med kolkvalitet, det säger ju sig självt.

Men verkligen nu efter att ha pratat med dig här så känner jag att det är viktigt Ännu mer viktigt än vad jag faktiskt har tänkt. Så ja, superintressant samtal.

[00:51:28] Sofia: Avslutningsvis tänker jag, i och med att vi får många mejl och frågor och på Discord och även kollegor som är alltså både juniora och seniora Som säger att de är väldigt rädda med sina jobb.

För att många av AI-företagen säger att vi inte att ha en mänsklig utvecklare om fem år. Vad skulle du säga till de utvecklarna? Vad tror du att vi är om fem år eller tio år? Många av oss ska jobba ganska länge till.

[00:51:58] Adam Tornhill: Jag tror så här att en duktig utvecklare en duktig problemlösare, det kommer det alltid finnas ett stort stort behov av.

Sen om man tittar på vad som händer... Ja, jag tror att mycket av det som vi gör idag kommer vi inte längre att behöva göra manuellt. Det tror jag. Så uppgifter kommer absolut att försvinna Men tittar man historiskt så varenda stort teknologiskifte har ju lett till att vi tar oss an större och större problem.

Vilket i sin tur kräver mer och mer arbetskraft. Så jag tror att vi befinner oss på en starkt expanderande marknad Men att vår roll som utvecklare kommer att ändras och ställas högre och högre krav i framtiden Det är min spekulation.

[00:52:40] Sofia: Men är det lönt då som juniorutvecklare att lära sig syntax? Varför ska jag då inte fortsätta bara generera upp kod?

För som du säger lite, det där kommer ju att automatiseras senare. Vart ska fokuset ligga liksom?

[00:52:55] Adam Tornhill: Jag tror att fokuset ska ligga på större problemlösning. Men jag tror också att vägen dit är lång. Jag tror vi pratar om flera års inte bara studier utan en sån arbete. Och någonstans måste vi börja. Och det finns givetvis ingen anledning att börja för grundläggande.

Men att ha en djup förståelse för de verktyg som både vi och språkmodellerna använder Programmeringsspråken och dess byggstenar. Det tror jag är viktigt och det kommer nog alltid vara viktigt. För även om vi i en hypotetisk framtid pratar om AI som gör allt och vi bara promptar om. Att instruera en maskin via text för mig är det också programmering.

Så jag tror att det här är skillset vi bygger upp. Vi ska inte fokusera så mycket på enskilda teknologier men förmågan att lära sig nya teknologier och förmågan att lära sig nya språk kommer alltid vara viktig. Och någonstans ska vi börja så min rekommendation är absolut för att börja med fundamenten.

Jag är hundra procent på att man kommer igen det.

[00:53:56] Madde: Det känns ändå lite

[00:53:57] Sofia: betryggande. Vi gick inte i skolan eller universitetet för så länge sedan. Man fick ju lära sig assemblingsspråk att lära sig hur hårdvaran fungerar. Det kanske är lite samma sak att faktiskt förstå programmeringsspråken i grunden Verkligen superintressant.

[00:54:15] Madde: Jag ska i alla fall testa den här trialen och se på något projekt man har och identifiera. Lite läskigt, men spännande också.

[00:54:25] Sofia: Vi kommer ju att länka allting du har med dig i avsnittbeskrivningen. Det är ju dels den trialen men också i det pluginet. Är det bara att testa det? Är det gratis? Det

[00:54:36] Adam Tornhill: finns en gratis variant för VS Code.

Men som rekommenderat till en utvecklarpublik så skulle jag rekommendera att titta på vårt Code Red whitepaper. Det är förenklad paketering av forskningsrapporten. Men det pappret illustrerar vikten av kodkvalitet i business-termer. Så om du någon gång haft problem att övertyga en produktägare eller din chef att investera i kodkvalitet eller betala av teknisk guld Så tror jag och hoppas att det här pappret kan hjälpa dig.

Super. Det

[00:55:10] Sofia: var jätteintressant

[00:55:11] Madde: att få prata med dig. Ja, stort tack att du var med oss här idag Adam. Superintressant.

[00:55:16] Adam Tornhill: Ja, tusen tack för att jag fick komma och tusen tack för pratstunden. Supertrevligt.

[00:55:21] Sofia: Och vi hörs ju nästa vecka om det. Det gör vi. Hej då.