[00:00:00] Madde: Kanske inte självklart för alla. Kanske särskilt inte för management eftersom de verkligen vill göra det här. Men det är ju verkligen så. Bara för att du lägger på fler utvecklare så kommer det inte nödvändigtvis leda till att du blir klar snabbare.

[00:00:21] Sofia: Du lyssnar på Developers, podden där du får följa med oss, Sofia och Madde på allt inom

[00:00:27] Madde: mjukvaruutveckling. Vi träffas senare

[00:00:35] Sofia: Vi har ju fått lite feedback på Discorden att vi borde ta tillbaka de här Would you rather-frågorna. Ja. Man vet liksom inte vad som är uppskattat och inte. Och det är så här, när man får feedback av Nu är det ändå några stycken som har skickat in frågor själva men man blir såhär, är det vi och tio andra som tycker det är kul eller är det vi och alla lyssnare som tycker det är kul?

Så ni får gärna, om ni hatar ett segment, skriv det. Om ni älskar ett segment, skriv det, för vi har ingen aning, vi bara testar lite. Nej.

[00:01:11] Madde: Nej men det var väl på tiden, det var länge sedan nu.

[00:01:14] Sofia: Så vad har du? Den här kommer från vår frågelåda, eller vad man ska säga. När man kan skriva in frågor till oss så var det någon som skickade några förslag.

Den här är genererad med ChatGPT har personen skrivit, men det går väl också. Så skulle du hellre arbeta med en chef som är tekniskt kunnig men är krävande när det gäller detaljer eller en chef som är mindre tekniskt kunnig men ger dig mer handlingsutrymme

[00:01:46] Madde: Åh alltså en chef. Jag vill bara spesa först vad man menar med en chef.

Jag tänker mer att det kanske är någon produktägare som faktiskt har att göra med det man utvecklar. Jag

[00:01:59] Sofia: tänker engineering manager, alltså personen som har ditt personalansvar och performance review och sådär.

[00:02:08] Madde: Jag har aldrig jobbat med en engineering manager så för mig känns det så... Men typ

[00:02:12] Sofia: konsultchef?

[00:02:14] Madde: Ja, okej Men om det skulle vara konsultchef så skulle jag nog vilja ha en mindre teknisk som ger mig handlingsutrymme. Det skulle vara helt bizarrt om min konsultchef kom och ställde krävande detaljer om mitt konsultuppdrag Då är ju inte den personen med att göra. Ja,

[00:02:32] Sofia: ja. Men jag kan tänka mig att det finns sådana som försöker blandas i ändå De sitter på andra sidan och ändå så här Vill ge en råd?

[00:02:41] Madde: Ja, kanske. Det hade varit lite obehagligt.

[00:02:45] Sofia: Men om det hade varit en... Säg då om du ser produktägaren mer som chef. Eller typ en engineering manager.

[00:02:53] Madde: Ja men då är det kanske lite mer att man ändå vill ha en mer tekniskt kunnig. Tänker jag. Men sen så har jag väl att ha en teknisk kunnig som ger mig handlingsutrymme.

[00:03:02] Sofia: Nej, men det är ju inte så här frågan är formulerad. Nej.

[00:03:08] Madde: Vad innebär krävande när det gäller detaljer Är det att den personen ska bestämma eller är det bara att den behöver känna till alla detaljer?

[00:03:16] Sofia: Jag tolkar det som att det här är någon som micromanager som sitter och tycker istället för att vara coachande.

[00:03:25] Madde: Okej men om det är någon som micromanager så väljer jag i så fall också en som är mindre teknisk i så fall.

Du då?

[00:03:32] Sofia: Jag tyckte den här var svår, för jag vill såklart ha en teknisk som ger mig handlingsintrymen, men det är inte det som jag vill. Det är klart att det inte är det man kan välja. Jag hade nog valt den som inte är så teknisk.

Ja, ja. Jag tänkte att nu, vilket datum släpper vi det här? Typ den... Den tredje, och då har du börjat ett nytt jobb Är det en tredje idag? Nej, det är en tredje. Okej, vi släpper den sjunde, förlåt. Men du har ju redan börjat ett nytt jobb så kan inte du berätta om det?

[00:04:11] Madde: Vad ska jag säga? Jag har ju också börjat på ett nytt jobb precis som du gjorde nyligen.

Jag började den första november på ett konsultbolag som heter BBA. Som har funnits i ett år ungefär tror jag, i Stockholm. Men de är inte så många, de är typ tio pers. Och jag kommer in och ska vara med och starta upp det här nere i Skåne. Vilket ska bli väldigt roligt. Och jag kommer in på rollen som CXO, alltså Chief Experience Officer.

Oooo Det känns lite konstigt men när det är ett så litet bolag så är det liksom inte så. Men väldigt kul faktiskt att få vara med i ledningsgruppen och vara med och jag kommer ju jobba mycket med typ employer experience eller employee experience och liksom kultur inte så, alltså kulturen är ju någonting som alla jobbar med såklart det är inte en person som äger det, men jag är den personen som Enablar andra att kunna jobba med kulturen och se till att det finns utrymme för det.

Och onboarding och personal. Intern kommunikation och kompetensutveckling och allt sånt. Men jag ska säga, jag jobbar 20% just nu. Jag är fortfarande mamma ledig i resten. Så det är liksom inte jättemycket jag jobbar än. Och dessutom

[00:05:43] Sofia: så delar du upp det lite så här kanske över veckan. Exakt så

[00:05:47] Madde: det är liksom inte en dag.

Utan jag kommer börja jobba mer sen i typ mars. Men då undrar ju alla lyssnare så här, men vadå Madde ska du sluta koda? Ja, precis. Jag kommer fortsätta konsulta lite grann sen när jag går upp till heltid. Men just nu då när jag jobbar med de 20 procenten så är det mer fokus på just CXO-bitarna. Det låter

[00:06:12] Sofia: ju rimligt.

Det är lite svårt att komma in i ett nytt konsultavdrag på CXO 20 procent?

[00:06:18] Madde: Ja, eller om jag då skulle gjort för jag kommer konsulta typ 40 procent ska jag då konsulta 40 procent av åtta timmar. Jag är med på daily. Det har så stor impact. Nej, men det ska faktiskt bli jättespännande. Men det var ju också väldigt vemodigt att sluta på tretton37.

Jag har jobbat där tio år och det kändes Jag grät liksom när jag sa upp mig och allting och sånt. Men jag tror det är bra för mig. Jag behöver liksom komma utanför min comfort zone lite. Så det ser jag väldigt mycket fram emot.

[00:06:52] Sofia: Ja, men det är en skitcool roll som passade så bra. Det var så... Det var så självklart när man hörde.

Det är typ såhär allt du har gjort utanför ditt vanliga konsultande. Så det är kul att få testa det nästan på heltid då.

[00:07:09] Madde: Ja men precis. Men som sagt, jag börjar ju i fredags, första november. Och har jobbat typ några timmar. Så jag har inte så jättemycket att komma med ännu. Får återkomma om några avsnitt och berätta mer.

Ja,

[00:07:22] Sofia: skitbra. Men... Jag vill också påminna alla lyssnare om att det är typ sista chansen att köpa biljetter till Jfokus med rabattkoden. Jag tror vi sa att den gällde till mitten av november. Ja, 15 tror jag vi sa. Ja, så det här släpps den 6 för Patreons, 7 för alla som inte är. Och då borde det vara verkligen läge att gå till sin chef och säga kan jag gå, jag har en rabattkod dessutom.

Så länken finns i beskrivningen av kontot Avsnittet.

[00:07:57] Madde: Och så ska vi också påminna om vårt 200-avsnitts firande. Som vi ska ha den 4 december i Malmö. Det får ni också signa upp till. Det har vi också i vår avsnittsbeskrivning. Men ja, vi behöver inte snacka om det. Vi pratade om det ganska mycket förra avsnittet.

Nej men om man har missat.

[00:08:14] Sofia: Det är på en onsdag. Och vilken tid är det? Det är efter jobb. 16.30. Och sen börjar live på den 17.00 Okej perfekt. Ja, vi har fått två nya stjärnsupportrar. Vi är supportade av Snelhest och Thomas

[00:08:37] Madde: Nilsson Ja, kul och roligt med någon som egentligen har ett lite annorlunda namn.

Jag har ju önskat det. Ja, men det var lagom det var ändå peko. Och sen ska vi tacka våra gamla godingar. Alicia, Anders Nylund, Björn Jonsson, Dag Rönnell, Kajetan Kazimierczak, Hjorthall, Lars Nyström, Molly och Per Nåtby.

[00:09:00] Sofia: Tack och tack till er alla andra patrons för ert stöd. Tack. Jag har en nyhet med mig idag.

Det är också ett segment som vi kör ibland och ibland inte. Någon kan väl säga såhär är det det bästa ni vet? Jag vet att en person har frågat, kan inte ni klippa ut bara dem och släppa som en mini-podd För det är det den här personen vill höra. Så kom gärna med feedback. Men jag tänkte bara nämna, såg du att OpenAI släppte en search-funktion?

[00:09:32] Madde: Nej.

[00:09:33] Sofia: Nej, jag har inte sett det. Så Nu vet jag inte när vi spelar in hur länge sedan det var. Då blir det typ två veckor sedan. Men de kom ut med att du kan söka i Google fast med chat-GPT. Och de hade en demo på det. Och vi har ju pratat tidigare om det här slutet för Google. Google är ju med i en massa rättegångar mot Google och deras monopolöversök.

Och man försöker på något sätt... Alltså splitta upp Google. De verkar inte kunna betala sig ur det. Och då i takt med att alla de här AI-sökfunktionerna kommer så undrar man ju så här. Vad är Googles framtid? Att söka på det sättet kanske inte är det vi vill längre. Det är inte det bästa sättet att göra det.

Så de kom med AI-featuren. Och...

Alltså det var ju inte så imponerande. Jag trodde man skulle bli mer såhär. Ja

[00:10:45] Madde: men alltså när du säger att de släpper sök. Vad är liksom annorlunda från det man kan göra idag?

[00:10:52] Sofia: I Google, tänker du? Nej i

[00:10:55] Madde: ChatGPT. Alltså du kan ju ställa en fråga och få ett svar. Är det då att du googlar typ... Att du skriver i ChatGPT typ...

Jag kommer inte på någonting alls googla på. Men Jag kan

[00:11:16] Sofia: dra det de visade vilket var såhär det enda jag

[00:11:20] Madde: kom på att googla på var såhär Maria bebådelsedagen jag vet inte var jag fick det ifrån det var typ det enda kom på vad skulle jag kunna tänka mig att googla på heter det än så

[00:11:30] Sofia: faktiskt för jag vet inte ens vad det är då kanske man ska testa och ChatGPT Nej men, jag kommer inte ihåg exakt vad querying var, de googlade på, vi säger fortfarande googla, det är väl allmänt accepterat som att twittra någonting, men de sökte typ på, hur skapar man en trevlig trädgårdsmiljö, eller något sånt där, alltså typ med trädgårdsmöbler och sånt.

Ja. Och då, alltså du söker ju så att du får ändå svar men också länkar till sidor. För just nu, det de har gjort är att de har bara skrapat webben precis som alla andra AI-företagen De har ju en massa, vad heter det lawsuits, vad heter det? Ja men, jag

[00:12:22] Madde: vet inte riktigt vad man ska

[00:12:23] Sofia: säga. Det är en massa lasuts mot dem från alla nyhetssidor och alla som publicerar, alla som arbetar på att skriva alla de här bloggarna och allting.

Att de bara skrapat allt. Så det de försöker göra nu är på något sätt att rädda det genom att visa att nu har vi en sökfunktion och du söker på hur jag gör en mysig trädgårdsplats. Så ger de dig dels typ ett summerat svar men också så visar de... Länkarna och förslag på andra källor och då skriver de ut så här det är trädgårdsforum.se och deras lilla ikon

[00:13:04] Madde: och

[00:13:05] Sofia: det var ganska schysst de bryter inte webbens kontrakt för det har de gjort lite nu när de bara skrapar allt det som var Jag vet inte.

Det som var roligt, jag hörde dem på The Vergecast prata om det från tidningen The Verge. Och de skrattade så mycket åt att det svar man fick var typ så här... Ja, men du kan ställa lite mysiga möbler och du kan hänga lite mysiga lampor för det skapar en mysig känsla. Och det var det som var lite kul att...

All den här AI-infrastrukturen håller ju typ på att koka vår planet. Och OpenAI har ju haft den största investeringsrundan som ett bolag har haft någonsin. De är typ så här, vi behöver biljarders miljoner för att kunna köra det här. Och det enda du får ut av det är så här, ja men köp lite trämöbler och häng lite lampor.

Alltså det är ju ingenting som jag bara... Men herregud det här har jag saknat. Det är inte som att jag inte har kunnat googla på det. Visst det enda dåliga senaste åren är väl att hade jag googlat på det så hade jag kommit till någon blogg där det är massa SEO-skit. Det tar typ så att du får scrolla en kvart för att komma ner till svaret.

Ja, precis. Men det känns ju inte som att... Jag vet inte, är det här lösningen på allt det? Kanske Men... Det var ändå så lite antiklimax och så här okej det här var ju inget. Nej, det förstår jag.

[00:14:50] Madde: Ja, nej man kommer väl ändå fortsätta googla. Alltså vissa saker passar sig för googling och vissa passar sig för chat-GPT.

[00:14:57] Sofia: Ja, och sen kommer de ju fram till det här från två olika håll men ändå så är de på väg mot samma sak. Alltså Google har ju det de har redan en sökplats En sökfunktion som är väldigt bra, och så ser man ju att de har börjat generera AI-svar, som är ganska kassa. Typ googlar jag på äpple, så får jag förslag på, kan man äta äpplen?

Det är ingen som någonsin har frågat det, nu har jag nog inte sett det, det kan vara så sjuka förslag. Så de kommer nog komma till samma sak från två olika håll

[00:15:39] Madde: Ja, vi får se hur det utvecklar sig. Jag berättade ju för dig igår att jag har en låt i mitt huvud som jag inte kan komma på vilken det är och jag försöker fråga en massa folk och jag har till och med haft en lång konversation med Chet GBT om den kan lista ut vilken låt är.

Men vi har inte kommit så mycket vidare ännu heller. Men där... För jag har ju försökt googla också, men det är ju helt dumt, för det har jag sagt till dig, det är typ såhär, det är ju dumt dumt dumt alltså så.

[00:16:04] Sofia: Nej, du behöver typ en sjung en AI som kan höra hur du sjunger den.

[00:16:09] Madde: Ja, det skulle jag kanske behövt typ som Shazam, fast mer sofistikerad.

Men det har ändå varit bra att kunna konversera, för att KöttGPT har ju frågat mig såhär okej men påminner det om den här låten eller påminner det mer om den här, och såhär. Ja, okej. Vi får se om jag lyckas leda vidare. Vi kanske

[00:16:28] Sofia: får testa Claude. Den är väl bäst just nu. De har en kapp löpning. Varje månad släpper någon någonting.

Den här är lite bättre, den här är lite bättre. Den här är lite bättre.

[00:16:41] Madde: Det får bli mitt första försök med Claude. Se om den kan identifiera den här himla låten jag har i huvudet. Jag tänker inte sjunga den i podden så att någon poddlyssnar. Det är så det skrattar inte.

[00:16:51] Sofia: Du sjöng den lite för mig och jag bara så...

Alltså, du har väldigt lite att gå på. Du sa dung-dung, dung-dung och sen kanske tjejen sjunger bla-bla-bla. Men det är oklart. Jaja. Okej vad har

[00:17:09] Madde: du mer i då? Du

[00:17:11] Sofia: har ju

[00:17:11] Madde: lite... Jag har med mig någonting idag. Det var faktiskt för ett par veckor sedan så såg en artikel sysa förbi på jobbslacken som hette typ såhär, nine laws that every software developer should know.

Och jag tänkte såhär det här låter ju ändå... Vettigt. Jag tänkte att det kanske är lite GDPR och accessibility-akt och allt sånt som kommer nästa år. Det kanske ändå är bra att göra ett avsnitt om. Även om det kanske inte är det mest exciting. När jag tänker nu så låter det faktiskt ganska tråkigt. Som tyvärr så handlar ju artikeln inte om det utan den handlar om någonting annat.

Den handlar mer om sådana här principer som man har. Eller typ... Det är inte lagar att det är nu måste jag på det här sättet utan det är mer någon gubbe som har kommit på någonting.

[00:18:03] Sofia: Accessibility Act är väl inte så tråkigt för jag är ju med och anordnar Öredev-konferensen och alltså antalet talks om accessibility vi fick i år var helt absurt från alla olika tracks.

Absolut Men GDPR kanske

[00:18:21] Madde: inte är så himla kul att sitta och snacka om. Nej det är ju inte sexigt. Men ja, jag tänker typ såhär Conways lag till exempel har säkert många hört talas om. Alltså det en ganska vanlig man tar upp i mjukvaruutvecklingssammanhang. Och den kommer jag gå in på sen också. Men De här lagarna då, eller vad man ska kalla principerna, de stämmer kanske inte alltid till hundra procent.

Men det är ändå bra att känna till dem för att det blir något slags ramverk att förhålla sig till eller en guideline man kan tänka på. Man kan låta lite smart när man bara såhär, det är ju the Pareto principle.

[00:19:00] Sofia: Ibland slänger sig folk med något sånt. Och så sitter jag där och bara, är det här något som är självklart Eller inte.

Och så vågar jag inte fråga. Jag kan inte komma på vad det är nu, men Ja men typ så här, du har skrivit ner Linus la. Jag har ingen aning vad det är för la. Nej den har jag

[00:19:19] Madde: aldrig hört talas om heller innan. Men vissa av de här är ju extremt självklara. Och det är så här, ja det här kunde jag också ha sagt och så här har det blivit Mellins la.

När får man typ ta patent på en sak som man har kommit på som inte bara är helt självklart. Men man

[00:19:33] Sofia: låter ju så smart när man istället för så här, det är klart man kan äta äpplen Så bara, du vet, Apple Bottoms Law. Exakt.

[00:19:45] Madde: Men jag tänkte att vi går igenom dem ändå. Jag berättar lite om dem och så kan vi prata om dem.

Så först ut har vi Brooks Law som säger så här. Adding human resources to a late software project makes it later. Då påkommet av Fred Brooks. Och... Det är ju en av de här som jag tycker kan vara lite självklara. Men det kanske inte är självklart för alla. Kanske särskilt inte för management. Eftersom de verkligen vill göra det här.

Men det är ju verkligen så. Bara för att du lägger på fler utvecklare. Men det är ju inte nödvändigtvis ledande till att du blir klar snabbare. För att man behöver ju lära upp dem. Du behöver onboarding De ska sätta upp sina utvecklingsmiljöer. Alltså allt sånt. För det första. Och bara lära känna domänen.

Det ju också det tar ju sin tid jag älskar ju den här metaforen som är typ att du kan ju inte ta nio kvinnor och föda ett barn på en månad, det måste ju ta nio månader för en kvinna, alltså så

[00:20:50] Sofia: ja, det här är så sant man ser det tycker jag med outsourcing att såhär, nej men våra tre utvecklare hinner inte med det här så vi kastar 20 outsourcade resurser på det och så blir det bara Skit och pannkaka och går långsammare eller är helt trasigt.

Exakt.

[00:21:08] Madde: Jag tänkte på scenarier där det faktiskt kan funka att lägga på fler folk. Det beror nog lite på vad för typ av resurs som behövs. Om det gäller att man ska sätta upp pipelines eller vi ska sätta upp terraform eller någonting som man kanske inte kan. Då kan det vara vettigt att ta in en expert som bara gör det.

De får en tydlig kravspes här. Bygg vår terraform och så är det klart. Så det kanske inte alltid är att det är Brooks Law som stämmer. Men när det gäller att få in utvecklare som ska bygga klart ens user stories. Nej Då tror jag nog att det stämmer. Ja. Sen har vi då Good Hearts Law. Som säger, det är en gubbe som heter Charles Good Heart.

Som säger att

Och det låter ju lite snyggt och fancy. Men jag blev såhär, vad betyder det här egentligen? Alltså jag fick tänka några gånger innan fattade vad det faktiskt stod. Men det handlar ju om att Om man börjar titta på en specifik metric och gör om den till ett mål så blir det ofta att man glömmer bort varför man mäter från första början.

Alltså för att göra det tydligt då, som att börja mäta antal rader kod för att mäta produktiviteten. Alltså så här, vi vet alla att antal rader kod har inte att göra med produktivitet för det är så mycket mer. Men om du då börjar fokusera på antal rader kod... Då tappar du hela tiden vad handlar produktiviteten om

[00:22:49] Sofia: när du börjar mäta till exempel antal rader kod som är väldigt så bra exempel är att även utvecklare som är väldigt medvetna om att det inte hjälper och så här Alltså skriva mindre rader eller fler rader Att du ändå börjar skriva då kanske fler rader om det du säger är bra.

Precis. Bara automatiskt av någon anledning.

[00:23:11] Madde: Ja, och det blir ju helt fel att man börjar fokusera på saker som egentligen inte är det man vill göra. Och det är ju helt onödigt. Det är samma sak när man mäter typ så här code coverage för att se om man har bra testkvalitet. Det är ju inte heller rätt eller...

Hur många story points man har klarat när man vill mäta velocity. Det är ju ändå ganska vedertaget att man gör det. Men det behöver ju inte innebära.

[00:23:38] Sofia: Om man nu mäter. Jag tänker om man har sådana metrics. De är bra att ha. Du behöver ju ha det om du leder ett team.

[00:23:47] Madde: Men

[00:23:47] Sofia: att man inte sitter och tittar på dem varje dag som är såhär.

Stänga buggar rate. Gå ner och upp. Det är mer för att Den som leder det kanske kan titta på det, men du ska ju inte riktigt... Prata om det, eller kanske ta upp det ibland när det är relevant, att du ser att okej nu har antagligen buggar gått upp upp senaste tre månaderna kan vi ta ett retro om det här och se?

[00:24:15] Madde: Absolut, alltså det är ju fortfarande, det finns ju fortfarande en poäng att vara datadriven och använda datan, alltså det är inte så att man ska mäta saker och sen skita och titta på det Mm Men man ska inte ha som mål att vi ska ha noll buggar, till exempel. Det kanske är ett bra mål ha, men det kan ju tyda på andra saker.

Så man får ju ändå utvärdera att man mäter rätt sak.

Okej nästa lag då. Nu har vi Hyrums lag, jag tror man säger så. Det här är ett förnamn Hire them right heter den. Och den här tyckte jag om. Den sägs här. With a sufficient number of users of an API it does not matter what you promise in the contract. All observable behaviors of your system will be depended on by somebody.

[00:25:05] Sofia: Det måste jag tänka. Jag tänker det är samma med features också. Så det han säger är att när du bygger någon Eller är det så här, om du råkar bygga en feature som egentligen kanske är en bug eller liksom det är inte som du har tänkt så kommer ju folk bara vänja sig vid att den

[00:25:25] Madde: finns där ändå. Exakt. Jag menar har du tillräckligt många användare som använder ditt API eller ditt system så det kan ju finnas saker man bygger som man inte riktigt hade för avsikt att det skulle funka på just det här sättet.

Mm. Men folk lär ju sig att använda det. Jag tänkte på detta när vi pratade om den här njösvånåsappen för några avsnitt sedan. Folk hade ju lärt sig de här quirksen som var lite krångliga att använda. Och sen när de tog bort det så blev ju folk syra för att det inte längre funkade. Och det är ju så här, även om du bygger någonting...

Så kan det bli att folk använder det på fel sätt, men de har ändå gjort sig beroende av det. Och det visar ju att det är jättesvårt att till exempel ha bakåtkompabilitet för att du kan ändra saker som du inte ens vet att folk använder det på det sättet. Det är väldigt komplext att kunna förbättra ett API när man har så många användare.

Men när ska man slänga sig med det här

[00:26:29] Sofia: begreppet då, tänker du? Ja

[00:26:33] Madde: Det är ju inte någonting som man använder så utan det är väl kanske mer bara för att visa på att det finns en komplexitet och att man därför behöver jobba mer med bakåtkompabilitet till exempel. Kanske att man är tydligare med sin dokumentation från första början så att man inte bygger in de här konstiga beteendena som ska finnas.

Att man tänker på det när man bygger sin arkitektur och liknande.

[00:26:58] Sofia: Mm. Jag antar att det kan appliceras så mycket, att man ska vara noga med att använda metrics och göra user

[00:27:06] Madde: behavior-tester

[00:27:10] Sofia: innan du produktsätter, precis efter att du gör det, för det är då det kan påverka det.

[00:27:17] Madde: Ja, precis Ju tidigare desto bättre.

Sen har vi då Conways Law. Och den är ju ganska känd. Den säger så här. Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure. Och den är då myntad av Melvin Conway. Och det här är alltså inte samma Conway som finns i Conways Game of Life, om man nu känner till det.

Vilket jag var så här taket på. Är det samma person som har kommit på Game of Life och Conways Law? Haha Jag upptäckte också när jag googlade på Game of Life är att man får upp Game of Life i Google. Det var faktiskt jäkligt coolt. Alltså att Game of Life är ju det här att det är två noder bredvid varandra och så regler kring vilken som ska tändas och släckas.

Så hela fältet bara blev en enda stora Game of

[00:28:09] Sofia: Men

[00:28:09] Madde: den här snubben heter John Conway som har gjort Game of Life.

[00:28:12] Sofia: Ja, men okej Och den brukar man väl... Jag vet inte. Jag tycker jag hör den. Alltså att folk använder den här lite slentrianmässigt.

[00:28:23] Madde: Ja men det kanske är att man vill låta lite pålästa. Jag kan I can't always law.

Men det handlar ju om att programvaran man bygger, strukturen och arkitekturen tenderar att spegla organisationsstrukturen på det som man har skapat. Att det blir väldigt likt. Så om man har en väldigt komplex organisation så får man också komplex programvara. Mm.

[00:28:45] Sofia: Jag brukar typ tänka på, om det kanske är fel, när folk jobbar väldigt mycket i silos så märker man det i programmen också.

Det finns typ inga enhetliga kontrakt över hur API-er ser ut. Precis,

[00:29:02] Madde: och det kan bli jättesvårt att kommunicera i systemet och bygga det i kapphåll. Det kan bli att det inte alls passar verksamheten egentligen Men det som är fint är att det finns en inverse Conway maneuver som egentligen är att man använder sig av lagen fast man gör det proaktivt.

Så istället för att bygga programvaruarkitekturen först så organiserar man om sina team och kommunikationsvägar så som man vill att arkitekturen ska vara. Och sen bygger man. Och då får man rätt arkitektur från början. Sen vet jag inte, är det ens möjligt att göra det? I en stor organisation, du kan ju inte bara omorganisera dig hur som helst och byta team och vem som är chef här och där.

[00:29:50] Sofia: Men det är väl det de gör hela tiden, omorganisationer på stora organisationer. Det kan man se. Bara att tänka på min egna så är det, man ser det väldigt mycket i hur typ vi har en... Arkitektur vi vill uppnå på den stora organisationen och då ser man ju också att om det finns plattformar och det finns produkter att man delar upp det så att Azure är en plattform och produkter är mer du och jag bygger någon specifik service så är det ju ett plattformteam som behöver se till att plattformen fungerar som en enabler men sen ska ju inte sådana Och plattformteamen är ju inte, alltså produktteamen är ju någonting annat.

De behöver ju en product owner, en UX och sådana saker. Så jag tycker att jag ser det men det är svårt, det är klart. Alltså det kan ju inte återspegla ett system exakt i människor. Nej

[00:30:55] Madde: det blir väldigt svårt för man har ju inte den här etipmappningen. Nej, men den är bra. Sen har vi ju då Linus Law som du nämnde.

Ja, vad är det? Jag har inte hört den innan heller. Men den säger, given enough eyeballs, all bugs are shallow. Och det är då Eric Raymond som har myntat den här. Jag vet inte vad som händer där. Varför heter den

[00:31:20] Sofia: Linus Law? Är du döpt efter någon så här... Hans barn eller? Ja,

[00:31:26] Madde: kanske. Men den här var också ett exempel på en väldigt uppenbar kan jag tycka.

Vad betyder den? Jag tror inte jag förstod. Jag tolkar den i fall som att ju fler människor som tittar på koden, desto större sannolikhet är det att man hittar buggar som andra kanske missar. Jaha, okej. Jag tänkte, vi nämnde ju i förra avsnittet när vi pratade om par-debugging till exempel. Att det är oftast lite lättare...

Och vara fler och hitta buggar och hitta

[00:31:54] Sofia: problem.

[00:31:55] Madde: Ja,

[00:31:55] Sofia: nu fattar jag en sån typ så här. Ju fler som tittar så flyter buggarna upp till ytan, menar han. Bugs are shallow, eller?

[00:32:05] Madde: Ja men precis. Och att, ja men till exempel om vi pratar kodgranskningar. Om vi har tre personer som granskar en PR istället för bara en.

Så är det mycket lättare att hitta problem Buggar. För att man tittar efter olika saker och då kanske man tycker att de ligger lite närmare ytan så att säga. Ja.

[00:32:27] Sofia: Ja, men den här är väldigt bra. Men det lät verkligen som så här Madeleine's la.

[00:32:35] Madde: Ja men lite så. Men här visar det lite att det kan vara väldigt effektivt med open source jämfört med stängd programvara.

Då är det många fler som tittar på koden. Jag vet faktiskt inte om man har gjort någon mätning eller om det finns någon data på att open source skulle ha färre buggar än icke-open source. Det har varit intressant att veta.

[00:32:56] Sofia: Det brukar ofta vara att folk försöker skrika om tvärtom och visa hur osäkert det är och så, men det kanske är för att du hittar ju många fler buggar, det används av många fler det är ju många fler som tittar.

Precis. Intressant.

[00:33:11] Madde: Mm. Det jag kände var att går detta emot Brooks law lite? Alltså det här med att ju fler resurser du har desto senare blir det. För jag tänker det kan ju inte vara vem som helst som tittar på det och så hittar man buggar. Utan det måste ju ändå vara folk som är insatta i kodbasen.

[00:33:29] Sofia: Nej, du kanske inte kommer snabbare fram om du sätter 50 BureaQuest-reviewers på BureaQuest.

Det tar ju lite tid. Det finns ju typ en balans mellan, alltså man får kolla såhär, det är ju där metrics är så himla bra. Det är där de kommer in, att när vi byggde och vi hade två kodgranskare så fick vi såhär många buggar tillbaka in i vårt system. Men sen när vi blev fler eller färre, alltså hur många får vi då?

Att man kan Börja dra de slutsatserna.

[00:34:02] Madde: Ja. Och sen är det ju svårt också. För jag menar antalet buggar är ju inte konstant. Det beror ju helt på vem som har implementerat och featuren i sig. Alltså så här. Ja. Det är ju komplext. Absolut. Absolut.

[00:34:14] Sofia: Ja. Nej men det är därför retrospektiv är så bra. Alltså att bara så här.

Hur. Alltså hur någonting upplevs är också viktigt. Vi upplever att vi har färre buggar. Eller att buggarna som kommer in är av en annan sort. Alltså det är... Fan vad krångligt allt är.

[00:34:32] Madde: Ja. Nästa. Hofstadters law. Jag vet inte hur man uttalar det. Nej Nej It always takes longer than you expect, even when you take into account Hofstadters law.

Ja, Douglas Hofstadter. Nej men gud vad väldigt egocentriskt. Ja, han ville verkligen få in det liksom två gånger. Men ja, det är ett... Den här tycker jag visar tydligt på att det är inte lönt att estimera. Lönt kan det vara, men man måste alltid lägga på lite extra padding. Det tar längre tid än vad man tror.

Man gör fel estimeringar. Men det kan vara ändå ganska bra att ta till när man har något projekt och man tror att någonting ska ta lång tid. Så ja, lägg på extra buffert och hantera förväntningarna på rätt sätt.

[00:35:25] Sofia: Ja, det är så livsfarligt när folk säger så här, det här är skitenkelt. Ja, alltså rent implementationsmässigt kanske, men nej det dyker inte upp

[00:35:38] Madde: komplexitet.

Nej det är så mycket. Det påminner mig lite om en kompis som byggde hus, byggde sitt egna hus från scratch och de estimerade liksom in på minsta skruv vad det skulle kosta. Nu var det inte tid utan det var kostnad men jag tycker ändå det var roligt. Så de estimerade in på minsta skruv och sen bara tog de det dubbla och det blev ungefär ett estimat liksom.

Oj! Ja.

[00:36:04] Sofia: Det var sjukt. Materialkostnad. Man

[00:36:08] Madde: vet ju inte exakt vad man behöver. Hur ska du kunna estimera hur många skruvar du behöver för att bygga ett hus?

[00:36:13] Sofia: Det är som att frågan utvecklar. Hur många rader kod kommer du att lösa det här med?

[00:36:19] Madde: Det var sjukt det hade varit om man hade börjat estimera det.

Tecken. Kom ihåg lägg på lite extra padding. Även om du tror att du har lagt på extra så lägg på lite till. Dubbla det. Minst. Mm. Sen har vi Kernigans Law av Brian Kernigan som säger att Everyone knows that debugging is twice as hard as writing a program in the first place. So if you are as clever as you can be when you write it, how will you ever debug it?

Alltså fattar du? Om du är så smart som du bara kan när du skriver programmet och det är dubbelt så svårt att debugga hur ska du någonsin kunna debugga det? Ja. Ja Jag vet inte om man kan kalla det för en lag alltså såhär, det är inte riktigt alltså det är bara ett konstaterande typ Ja,

[00:37:09] Sofia: ska vi se Ja Jag tycker om det här Det handlar om såhär simplicity att att Bara gör det så enkelt som vi kan.

Vi har precis haft den här situationen på jobbet. Att så här...

Vi i vår team vill implementera någonting som bara låter så sjukt bra att göra. Det känns som att det är rätt väg för framtiden. Men nu har vi suttit med det i en vecka. Och lyckas liksom inte exakt lösa det. Och då är jag så här... Kan vi inte bara skita det och göra det som är enkelt just nu för att om någon annan ska sättas in i det här efteråt så kommer de absolut inte fatta det, det kommer också ta dem en vecka att göra det här, det är precis det här, vi ska liksom hitta på något jätteförnurligt och smart ja Nej, jag gillar verkligen inte komplexkod.

Man ska

[00:38:13] Madde: bara förstå den direkt. Vi har ju pratat om det jättemånga gånger. Om de här lite seniora som vill skriva någon superkysig algoritm Och man blir lite imponerad. Men som sagt det är jättesvårt att underhålla Man fattar inte det sen.

[00:38:25] Sofia: Fast det är ju de som inte är helt seniora.

[00:38:29] Madde: Eller? Det är väl de som har lite prestige i sig kanske då, om man säger så.

Alla

[00:38:36] Sofia: vi hamnar i det här man har liksom fattat ett koncept som ingen annan fattar och då känns det ju så självklart för en själv. Men som sagt keep it simple, stupid som

[00:38:49] Madde: vi pratade om för några avsnitt sedan också.

[00:38:52] Sofia: Men okej så Kernighans law, då ska jag börja slänga med det istället för att säga att det här känns lite overengineered, så ska jag säga det.

Det känns lite Kernighans law här.

[00:39:02] Madde: Ja, det låter verkligen fancy. Okej vi har två stycken kvar. Vi har Peter Principle. Åh, här tog jag upp för några avsnitt sedan. Ja det gjorde du just det men den säger för att fräscha upp minnet då people in a hierarchy tend to rise to a level of respective incompetence Lawrence Peter men det är ju helt enkelt det här att alltså folk befodras och till slut kommer till en nivå där man är helt inkompetent du kan liksom inte det längre.

Ja. Och det är ju ofta det här att man, när man ser att utvecklare befordras till managers till exempel. Man har varit jättebra utvecklare och du blir senior och sen så vill du fortsätta bli befordrad och sen så blir du manager. Och det är inte alls säkert att du kan hantera människor eller ha de här kompetenserna som krävs för det.

Nej,

[00:39:58] Sofia: det är så vanligt. Jag tycker den här är så himla bra och jag har tänkt mycket på det. Vi ska prata om det i något avsnitt snart. Du vet karriärvägar för utvecklare. Säg att en självklar karriärväg skulle kunna vara junior, senior, arkitekt, enterprise arkitekt och typ kanske CTO. Men vad en enterprise-arkitekt gör, till skillnad från vad en utvecklare gör, är helt två olika professioner.

Alltså det är, om du älskar att skriva kod, det är när en enterprise-arkitekt gör, är någonting helt annat. Så att det är verkligen inte självklart att man blir befordrad på det sättet. Man kanske hade passat jättebra som arkitekt, för du är någonstans mittemellan

[00:40:49] Madde: Exakt. Många enterprise-arkitekter som jag har träffat kan ju inte ens skriva kod heller.

Men det kanske man egentligen inte behöver. Nej, för de ska titta typ 20 år in i framtiden. Ja, och se helheten på ett helt annat sätt. Men det kan vara värt att tänka på i alla fall att man ska inte alltid bara bli befodrad för sakens skull. För att du vill ha mer pengar utan det ska faktiskt vara inom det du vill jobba med.

[00:41:18] Sofia: Ja, men därför är det ju också viktigt att det finns liksom, att du kan utvecklas inom en roll du har.

[00:41:25] Madde: Och

[00:41:25] Sofia: det är ju alltid lite svårt. Ibland känns det som att det är ett krav att kliva typ upp en nivå eller byta roll helt.

[00:41:34] Madde: Ja, nej vi får helt klart göra ett avsnitt om karriärvägar för det tycker jag det är mycket att prata om.

Sist ut har vi Pareto Principle. Den är också en sån kändis. Man brukar kalla den för 80-20-regeln. Den är formlerad så här. For many outcomes, roughly 80% of consequences come from 20% of causes. Och det är Vilfredo Pareto som har myntat det här. Förenklat så är det att 80% av ditt resultat skapas av 20% av arbetet Om man vänder på det så innebär det också att de sista 20 procenten kräver 80 procent av arbetet.

Den går att applicera på så mycket grejer. Jag älskar den här. Jag tycker faktiskt att den är så bra. Särskilt, alltså jag har kämpat ganska mycket med perfektionism och att man vill att saker ska vara helt felfria. Men när man tänker på det här, är det värt att lägga 80 procent av tiden på de sista 20 procenten Eller är det tillräckligt bra att få 80 procent av Och det är såhär, ja, det kanske faktiskt är tillräckligt bra.

Det inte värt det här sista

[00:42:45] Sofia: Ja, den går att applicera på jättemycket i just mjukvaruutveckling. Jag tror att jag har hållit ett tag där jag tar upp det här och då tar jag upp att 80% av dina användare använder 20% av din applikationsfeatures. Så det är så bra att tänka på så här, vad är de här 80% av features som ingen använder?

Så det är bara att tänka på typ Microsoft Word eller Excel, alltså hur många... Knappar klickar du på egentligen där. Eller hur? Men de är ju, där är det så intressant för de är så använda av så många miljontals människor, så även om de har en knapp som du inte ens vet vad det är så är det typ en miljon som använder den.

De kan inte ta bort saker Nej

[00:43:30] Madde: det är klart Det är lite annorlunda när man har en så stor användarbas. Men den är så riktigt bra. Ja. Det hjälper en att fokusera på vad som faktiskt är viktigt och vad som ger mest resultat Det är liksom the bang for the buck. Ja. Mm Grymt Ja, så det är nio stycken lagar att kanske tänka lite extra på om man vill briljera också och ha lite kött på benen när man ska argumentera med någon som bara tycker att man ska göra på ett visst sätt Ja, gå och släng med de här termerna Ja, och vi länkar artikeln som jag läste också för det var lite bilder och sånt också som hjälper en att förstå lite mer Vi hörs nästa vecka.

[00:44:14] Sofia: Det

[00:44:15] Madde: gör vi. Ha det bra allihopa.