Madde (00:00)
Det han byggde var bara så här... Nej, det här är helt fel. Han hade nog en stolthet att han skulle göra allting själv utan att ta hjälp. Det hade verkligen kunnat lösas mycket bättre av att vi pratade och inte samarbete.

Sofia (00:25)
lyssnar på Developers, podden där du får följa med oss, Sofia och Madde, på allt inom mjukföroutveckling.

Madde (00:32)
Vi träffar spännande gäster, testar nya teknologier, söker inspiration och tar upp aktuella ämnen. Jag var på väg att göra bort mig ganska... Alltså inte rejält, men jag var känd som shit, det hade blivit pinsamt de där händer. Jag fick fråga av en person som jag jobbat med tidigare om jag skulle kunna hjälpa honom för att han håller på att en sån här typ ledarskapsutbildning.

Och då var en av delarna att de skulle samla in feedback i ett här stort formulär om då personens ledarskapsförmågor och sånt. Så jag bara, ja, men självklart, absolut. Kan göra det. Så vi kan kalla personen för Lucas. Så att jag fick då ett långt formulär om Lucas' prestation och så här. du vet hur man så här, när man ska alltså betona någonting, så kan man ju säga typ så här...

Han är en teamspelare med stort te.

Sofia (01:33)
Ja, du vet vad jag säger så.

Madde (01:37)
Så sektionen handlar om Lucas, om han exekverar, om han är bra på att göra saker, tar han initiativ och så här. Och så var det på engelska då. Så jag bara sitter och skriver, jag bara, Lucas is a doer with a big D. Och i samma sekund som jag skrivit det, bara, nej. Jag bara nej, det här kan jag inte skriva. Som tyd var så, jag kom ju på det då. Men alltså om jag skickade

Sofia (02:05)
Fin

komplement på flera

Madde (02:09)
Jag har inte någon koll på hans D, jag säga. Men ja, kul. Alltså, kan bli så pinsamt. Så man får försiktigt med vad man skriver.

Sofia (02:22)
Fy

okej, ja, det var bra. Jag är väldigt besviken på att du inte skickade in det.

Okej, jag har också faktiskt en grej jag måste klaga på. Nu vet vi att har pratat om Liquid Glass, alltså den nya redesignen på iOS. Vad är det för iOS-version nu? 18 tror jag. Ja, vi säger att det 18. Och när jag såg designen så tyckte jag ju inte om den redan då och du var såhär nej men den är nice. Jag bara okej, men alltså vad vet jag? är liksom världen, alltså...

Apple är ju designföretaget nummer ett skulle man ändå säga. Visst inte det kan vara på senare år, men det är ändå deras grej tror jag. jämför med alla andra. De innovativ design, de lägger verkligen krut på just det. Så, vad vet jag? Nu ganska nyligen så har uppdateringen kommit. Om man inte ville köra den här previewen liksom själv tidigare.

Madde (03:07)
Inom.

Sofia (03:26)
Jag har avvaktat mig att uppdatera tills man typ måste.

Gud vad, Gud vad jag hatar det. Det är så, och jag har sett att jag inte är ensam. Jag hatar, folk hatar ju det här temat. att, du vet, folk klagade ju redan innan på att det var för, alltså det är genomskinligt tema.

Madde (03:35)
Så.

Det så fort.

Kontrasten blir jättekonstig på vissa saker.

Sofia (03:52)
Ja, och folk var såhär, nej men det är ju typ svårt att se för att, du vet, allt bakom syns. Och då har de ju ändå tagit till sig av kritiken under sommaren. Då det här har varit i typ såhär developer-beta och sånt här. Så att man kan gå in på inställningar och så kan man välja typ såhär att liquid glass-temat ska vara lite mer frostat. Så jag har klickat i det och även då, det är bara, det är så...

Det är så plottrigt. bara så kan någon snälla hålla med med våra lyssnare för att jag ser på Reddit att folk klagar. Men det kan ju skilja sig. Det kanske är tusen personer som är arga på det och det de som hörs.

Madde (04:35)
Nej, men min känsla är att majoriteten inte tycker om det.

Sofia (04:40)
Men tycker du fortfarande om det då?

Madde (04:43)
Jag känner mig rätt neutral till det. Det kände jag också. Det inte så jag bara, wow, gud snyggt när jag såg det heller. Jag började inte jättemycket. Jag tycker det blev bättre när de gjorde de här förbättringarna. Att det är mer frostat så att det inte blir helt genomskinligt och allting där bakom lyser. jag har inte jättestark åsikt faktiskt.

Sofia (05:04)
Nej, det är inte som att det här tar upp hela min vardag. Men ändå är det en podd om teknik. Men jag tycker det funkar helt okej på datorn. Alltså där har jag inga problem med det. Det tycker jag är ganska schysst att det inte blir så plottrigt. För det har ju inte fönster som överlappar och att det blir svårt att liksom... Det blir ju lite... Det blir inte plottrigt för mig.

Madde (05:29)
Däremot har varit så mycket andra buggar på datorn tycker jag. minns inte om jag snackade om en kalenderbugg jag hade. Att när jag trycker fram en vecka åt gången så är det random vilken dag veckan startar på. det är typ så här måndag och sen skrullar man fram en vecka så är det typ så här onsdag och sen skrullar man fram så är lördag.

Sofia (05:47)
Vad

är det du gör att fel?

Madde (05:49)
Ja verkligen, det var skitirriterande. Nu har de löst det i senaste, alltså för typ två veckor sedan och någonting men det tog en lång tid innan de fixade. Jag vet inte, det kändes, men det har varit mycket sådana budgar som man borde ha sett i typ en betatestning eller någonting.

Sofia (05:58)
Kan man missa det?

Ja, det känns som att det där borde man fånga direkt som utvecklare. Det är så typiskt att man navigerar fram och tillbaka.

Madde (06:14)
Vi

kollade på Red också, det fler som hade samma problem.

Sofia (06:18)
Typ

gjort fel i USA så börjar de veckan på söndagen. Så det har hänt mig att jag gjort fel i vissa, alltså typ schemat lagt någonting fel.

Madde (06:28)
Jag har absolut bokat in saker på en söndag till exempel. Rant, klart. Jag har en till rolig grej jag kan berätta om faktiskt. Det var på jobbet häromdagen så vi använde Flask som är ett Python-ramverk för att bygga webappar typ. Så jag skulle göra Flask run för att starta upp backar.

Sofia (06:32)
Jaja, nåt väl.

Ja, vad är det något mer?

Madde (06:55)
Jag råkade skriva flask rum istället. Så jag sa, ho, nej. skrev på slacken bara, Dagens freudianska felsägning. vill ha en flaska rum typ så här. Men då var det en kollega som tipsade om ett... Ja, vad ska man säga? Ett add-on till ens terminal som heter The Fuck. Har du hört talas om det?

Sofia (07:19)
Nej, det tröta.

Madde (07:21)
Så det är alltså ett... vad ska man säga? Ett skript som korrigerar alla kommandon som du skriver. Om du har skrivit fel då, förstås. Så till exempel... Ja, men det vet man. Rokit skriva så här... Git rebay istället för git rebays. Och då får du ju upp typ så här... Kunna find that command, du mean git rebays typ. Och då kan du bara skriva... Fuck. Så autocorrigerar den liksom till...

Till det kommandot som är rätt. Även om du gör git push och inte har nån upstreambransch- så finns det ingen branchier origin. Do you want to create? Skriver du fuck? Skapa den då, branschen och allting. Det är så massa alias av alla kommando. Men nån anledning lyckas den ändå fatta vad du har skrivit och vad du vill skriva.

Sofia (08:17)
Okej,

så det är mer typ så varje gång Gitt då antar att det var det här du ville. Det är bara då den kan hjälpa dig.

Madde (08:26)
Nej

men det är bara gitt. Om man kollar på deras github så har de en lista på allt det jag störde. Hade jag då skrivit flask rum så hade jag kunnat i stället skriva fuck.

Sofia (08:41)
Det är jättebra. är som... Jag vet inte, jag har inte ens gjort det på senast tid. du vet, förut när man typ skrev in hemsidorsnamn i baren så är det vanligt att man kanske ska skriva Google-fel och då har de ändå köpt upp alla felstavade sidor och så redirekterar de tillräckligt. Det är ganska nice.

Madde (09:00)
Någonting som var lite extra kul tyckte jag var att vissa kommandon, om du ska installera eller någonting så får du upp så här, do you want to run all the scripts? Yes, no. Så om du har ett sånt script också så kan du skriva med flaggan dash dash yeah, så du skriver fuck yeah. Eller dash dash hard, fuck hard, om du är riktigt frustrerad och bara vill köra.

Sofia (09:24)
Det blir

lite så här inappropriate for work på något sätt. Det lite som det här with a big D.

Madde (09:34)
Ja, det var mycket inappropriate för mig då. Man kan insta i det med Brew i alla fall. Brew install the fuck. Eller man kan insta på Windows och sådant också. Men då är det lite manuala steg. Vi länkar till er i Skithub så kan man göra det om man känner för det.

Sofia (09:37)
Ha ha

Jättefint tips, men vi går vidare till att tacka våra Patreons då. Så tack till våra stjärnsupporter på Patreon.

Madde (10:00)
Tala

med inanför upprätt.

Sofia (10:04)
Tack till era fina små skärtar som stöttar oss. Alicia, Anders Nylund, Björn Jonsson, brother, Dag Rönnell, “Fyra Tre Johan Larsson, EZ”, Kajetan Kazimierczak, Lars Nyström, Martin Haagen, Molly Haglund, Oskari, Per Nåtby, Selim Hjorthall och Tomas Nilsson och “Skrev om, refaktorerade”.

Madde (10:24)
Stort tack till er och tack till alla andra som stöttar också på ett eller annat sätt.

Sofia (10:29)
Så till ämnet då, vi ska snacka om en artikel som både du och jag läste i helgen som var ganska intressant. var någonting som dök upp, alltså blev delat på Hacker News. Det är en artikel som hette Most technical problems are people problems. alltså den här artikeln var egentligen baserad på typ fyra andra artiklar. om du såg det i ingressen.

Madde (10:53)
Jo, det var typ såhär, Jeff Atwood har skrivit om det här och många långt bak i tiden. Tidigare var det 1987 eller någonting.

Sofia (11:02)
Ja, jag ska kolla. men precis, var typ så här. Någon har nämnt att Jeff Atwood skrev samma sak 2008 och Jeff refererar till Bruce Ekel från 2007 och Bruce refererar till Gerald Weinberg från 1985. att många personer har sagt samma sak. Det här är liksom ingenting nytt. Men det var intressant om att, ja, att de flesta tekniska problem är kanske inte tekniska problem egentligen utan det

Hur säger man det i en här people problems?

Madde (11:34)
mänskliga problem kanske.

Jag vet själv att det är ganska många gånger som har tänkt att det är störigt. Vi har så mycket buggar eller ingen vågar deployera koden. Men oftast är det inte det som är problemet utan är någonting bakomliggande.

Sofia (11:56)
Precis. Så den här personen började ju med att förklara väldigt enkelt scenario från... En erfarenhet den hade. Typ att det fanns Det fanns legacy-kod som behövde skrivas om. Och den tekniska lösningen på det är ju att vi måste skriva om det här så att det är modernare. Och så slåss man mot att management inte förstår... Om man förstår inte hur... Man märker att...

Du behöver ju övertyga folk om att det behöver göras, är det som är problemet. Och hur hamnar du inte där igen och lite sådana här diskussioner.

Madde (12:35)
Ja, det är alltid svårt att motivera refakturering eftersom systemet gör samma sak efteråt. Alltså det svårt att se ett värde. Det ingen skillnad för kunderna, användarna.

Sofia (12:44)
Ja, eller hur. Om man inte typ har väldigt så teknisk management, då har märkt att det är lite lättare. Det är väldigt skönt så här, det är på jobbet just nu, alla har varit utvecklare innan. Men det är väldigt svårt annars. Och dessutom så här, är just, han gav exempel på var ju att, även om du har fakturerat om dig då, och som du säger, blir inget skillnad, och sen efteråt så blir det lika mycket skit. Så blir det liksom...

Det ingen som inser efteråt heller att det här var ju mycket bättre för att ingenting har förändrats.

Madde (13:20)
Exakt. Nej, som sagt, jag känner själv att jag skyller till det och jag tror att det är ganska vanligt att man tänker att det är liksom ett tekniskt problem. Och det inte heller så att jag bara vill attackera tekniken. liksom... Det är inte så att jag... Jag gillar ju teknik och så. Men jag tror ändå att om man försöker bryta ner liksom de olika sakerna man säger så kan man ändå inse liksom vad det är egentligen som ligger bakom. Så när man säger liksom så systemet är för komplext eller...

Vi har för mycket teknisk skuld och så här. Så är det så ja men okej. Och hur ofta, av alla de gånger när man har försökt lösa det med mer kod eller en annan process eller någonting, hur ofta har det egentligen funkat? var ett pris som han skrev i artikeln, att det blev samma skit igen. om man tittar på det, varför är det så? Ja, alltså det är ju människorna bakom som skriver det. Varför har man, alltså...

Varför har man skrivit Slarvikål från första början? Det är lite det man behöver tänka. Det är så lätt att skilla på någon gammal person. Men om någon som varit med i systemet länge, har byggt länge. Hur kunde de fatta det här beslutet? Hur kunde de välja det här? Men om man bara tar ett steg tillbaka och tänker så är det så vanligt att det typ... Det var otydliga krav kanske. Eller det var typ...

Sofia (14:42)
Ja,

och det är mänsklig faktor.

Madde (14:46)
Ja,

exakt. Det hjälper inte all teknik du har. Sen är det klart att det är då enklare när du refakturerar för då har du på något sätt fasit i handen för då har ändå systemet växt fram. Och de här kraven har ju uppdagats i form av att man pärtsar lite, man slänger på någon ny lösning och det är ju allt det som blir den här tekniska skulden. Men det är ju fortfarande ett människoproblem eller ett mänskligt problem, eller vad man ska säga. Samma med typ alla edge cases och sånt.

Sofia (15:15)
Jag tycker det så typiskt också att, som du säger, om det tar så himla lång tid att deploya, att man just hoppar på det här, okej, men vi måste förändra så att det är enklare, vi har modernare deployskript. Alltså, det är ju det jag hoppar till också själv för att det känns som att, visst, jag får för mig säga, jag ofta medveten om den mänskliga faktorn som har lett dit, men sen när jag ska argumentera för

saken så kanske man presenterar bara så här, nej men vi behöver fakturera. Och det är också då det är svårt att köpa för någon för att. Eller så här, det kanske går att köpa men du gör ju inte riktigt den förändring som krävs då och det låter väldigt bra att så här, nej men Sofia hon bara fakturerar allting och löser det, det kommer bli skitsnyggt och det är ofta så här, de utvecklarna de får ju kanske cred för att du kommer upp med den här snygga PR-en som använder moderna tekniker.

Men det har kanske då inte löst problemet.

Madde (16:15)
Nej, exakt. En annan typisk symptom är alla edge cases och sånt man får. Det är skitsvårt. Vi har ett projekt som en e-mail integration. Jag visste att e-mail var jobbigt innan. nu... Innan har jag mest jobbat med att bygga e-mail-templets och sånt. Det är svårt att få dem att se bra ut. Nu handlar det också om att läsa in e-mail och importera.

Alltså vet du hur många olika sätt du kan skicka attachments på? Och vet du att det skiljer sig hur attachments funkar beroende på om du skickat det i Outlook desktop eller Outlook webb? Och sen kan man bädda in ens attachment. Alltså sånt är skitsvårt att veta. Och också jättesvårt att liksom spesa från början såklart. Och allt sånt skapar ju en stress också. Vilket också är liksom ett människorproblem.

Sofia (17:06)
Mm, mm.

Ja, nej jag vet inte. Jag tycker också så här, det var intressant som han skrev att folk som han jobbat med, eller så här, tillbaks till scenariot att man ska refakturera någonting för att det ska bli bättre. Att han menar att, men det spelar ingen roll om du ens fixar det då för att folk som han jobbat med har liksom uttryckligen typ så här kommit och sagt till honom att, vad var det typ så här, jag vill inte lära mig någonting nytt. Alltså att folk verkligen...

har den attityden och jag tror att vi alla har definitivt jobbat med folk som är så och att det finns verkligen också utvecklare som de som inte vill ha förändring kommer också att designa sina system så att de är sjukt svåra att förändra. Alltså att den buggiga koden du sitter med eller den här tröga releaseprocessen det har jag sett väldigt många gånger hos folk.

alltså skitsvåra branschingsstrategier och processer. Det är lite som att folk gör det med mening.

Madde (18:17)
Men typ att man är rädd för att deploya lite. Så då bygger du en krånglig process.

Sofia (18:22)
Ja, eller typ så här ofta har du ett, är bara en person i ett team som får deploya. två. Och alla måste vänta på den liksom. Varför gör ni inte om det? Nej, men det för komplicerat och alla. Det är egentligen att man bara inte, man bara pallar inte, lära sig någonting nytt och fixar det. Och då spelar det ingen roll. Jag har faktiskt gått in i ett team där det var typ ett sånt scenario och skulle bara så här innan jag lämnade ett konsultuppdrag. Hjälpa det här teamet att, ja men...

komma upp med en plan hur de kunde förändra. Det var det onödigaste jag gjort i mitt liv. Jag satt med alla och gick igenom vad de gör idag och presenterade hur de kunde bygga om det. Jag trodde ändå att jag gav dem ägandeskap. Jag gick inte in och bara löste det och skrev nya pipeline. Jag sa att det här kan ni göra. Ni kan skapa just det största och förändra det här.

Madde (19:17)
Vad händer efter du lämnar det?

Sofia (19:19)
Ja,

alltså nu har det gått typ två år snart. Inget det har hänt. Det har bara glömts bort eller liksom bara skjutits upp att det ingen som palla lära sig det där.

Madde (19:30)
Antingen det, eller så är det inte prioriterat att de har så mycket annat att göra. En produktägare som bara skjuter på nya saker eller att man har mycket buggar som man måste lösa som gör att man bara måste prioritera att släcka bränder typ.

Sofia (19:44)
Ja, absolut. Det finns ju säkert... Det klart de skulle vilja förändra det. Och det är svårt att förklara för en produktägare. Det är ju en annan del av det här. Man behöver lära sig att vara så himla bra på att prata och presentera sina idéer. Jag tror verkligen att ens framgång ibland som utvecklare eller inom vilket jobb som helst, det beror ju bara på hur bra man är på att prata och presentera sina idéer. De behöver ju inte ens vara avancerade, men att du...

att folk bara litar på det du säger. finns såna personer och folk lyssnar alltid på dem. Och man sitter där och bara, det jag säger är typ samma sak men inga gör någonsin som jag.

Madde (20:23)
Ja, visst. Mycket kommer ju ner till ens förmåga att kommunicera. Alltså så är det ju överallt alltid. Och det är ju där många problem uppstår också tror jag. Alltså om du nu inte håller med en person till exempel så kan det ju vara lite jobbigt att behöva säga det. så här. Den tycker att vi ska bygga på ett visst sätt. Nu ska vi lägga allting på en message queue.

Och så tänker man själv att nej men det tycker jag inte vi ska göra det blir onödigt komplext men så vågar man inte säga det. Då är det bekvämare att bara jag går väl med på det och så gör man någonting halvhjärtat. Det är klart det är bekvämare att bara refakturera och köra på än att behöva ta det här jobbiga samtalet eller ifrågasätta ett beslut eller någonting.

Sofia (21:09)
Ja men det är skitjobbigt att ta alla fightor. Man ska väl inte göra det heller. Ibland glömmer man bort att det här är bara ett jobb. Och det finns säkert tio lösningar på problemet. Och ingen av dem kommer vara perfekt. Bara så släpp det. Så det kan också vara sunt, men ja.

Madde (21:27)
Jo, förvisso.

Sofia (21:29)
Men jag har mycket genomsatt trygghet just. Alltså på gott och ont. Ingen vågar säga så jag förstår inte.

Madde (21:36)
När det blir jobbigt, då inser man att det inte är tekniken, en själv. Och dit vill man inte komma. Sen ska man inte heller bara skilja på individer heller. Det är ju ofta organisatoriska problem. Vi pratade innan om Conway's Law. Att det man bygger speglar hur organisationen ser ut. Och det har jag sett så många gånger. Att jobbar man i silosar, blir det ett system som är i silos.

Sofia (22:04)
Exakt. Jag vet inte. Vi kanske kan prata lite mer om Conway's Law för att jag tror inte alla har koll på det. som du sa, speglar ju oftast, det är du bygger, speglar din organisation.

Madde (22:19)
Det finns en fancyd definition på engelska som jag inte kommer ha i huvudet. Given an organization, blablabla. Du kommer alltid bygga i samma struktur som din organisation är organiserad.

Sofia (22:35)
Ja, och vad betyder det egentligen? Du nämnde ju så här siloade system. Problemen med silos för ett team är att om du... Alltså, du behöver ju lite silos absolut och du behöver kanske, om du har en så här hemsida, så kanske du tänker att det moderna sättet är att ha feature team. Där varje team har en DevOps-expert, har en databasexpert, har en frontend, har en backend, men det kan bli silos i det.

Och då har du, alla Featured Teams ska sedan ihop på samma site. Då har du sex team och sex varianter på en action button till slut. Eller liksom sex olika lösningar på en databas. Sex olika databaser.

Madde (23:25)
Exakt olika sätt att logga, olika sätt att felhantera. Någon gör det i loggare i en dashboard i Grafana, någon har bytt den i en dashboard i någonting annat.

Sofia (23:38)
Ja, eller typ så otydliga ansvar. Ingen vet riktigt vem som är ansvarig för att se till att den här releaseen sker eller synka något projekt. då blir det så här väldigt, jag vet blir en otydlig arkitektur också. Alltså det blir så här osäker kod på något sätt.

Madde (23:58)
Nej men eller hur? är ju verkligen så att systemen gör ju precis det som man säger till dem att de ska göra. Så det ju inte så konstigt. ja. Allt är ju inte people problems heller. Ibland kan det ju faktiskt vara tekniken som är problem. Så att vi ska ju liksom inte vara så här, det kan ju uppstå race conditions eller prestanda problem eller så här. Men det är ju värt att nämna det för skillnaden där är ju ändå att...

Man kan lösa dem, och man löser dem oftast bara en gång, sen uppstår de inte igen. Har du hittat ett race condition och varför det skedde, då dyker det inte upp igen. Då är det typiskt, inte ett people problem bakom.

Sofia (24:39)
Men hur ska man veta skillnaden då, när det uppstår?

Är det bara att det är legacy eller en dålig release-process, då borde man direkt känna igen det som ett mänskligt problem. Hur ska man identifiera det?

Madde (24:59)
Men tycker om man försöker zooma ut lite och titta på, även om vi tar releaseprocess som exempel då. Så får man väl titta på vad är man har, hur funkar det och varför har man satt upp det på det sättet. Är det då för att är många teams som är beroende av varandra och att det är otydligt vad de har releaseat så att plötsligt måste du hotfixa massa innan du kan få ut din release för att team C har testat dåligt. Om man försöker se det på det sättet tror jag.

Sofia (25:27)
Mm, okej, typ, okej, har ett, något som ser ut som ett tekniskt problem. Hur har det uppstått? Och då om man ser att, men på grund av att team är, som du säger, eller vad man bara säger, nej men det är fel implementerat, då är det lite skillnad.

Madde (25:45)
Jag tror det.

Jag hade faktiskt en grej på jobbet som jag tyckte var så här... Det var snarare tvärtom. Det var ett teknikproblem. Man försökte klä sig med people som man vände på det. Jag vet inte, det kanske finns en bra anledning till det. Men vi har här demo en gång i veckan. Och då har vi rullande schema. Vem det är som faciliterar demot och bjuder in till och allt sånt här. Och det finns liksom en lista.

Det är bara att folk glömmer att titta i listan och se att den här veckan skulle jag bjuda in till demo. Det händer ganska ofta på fredagar. Man får fredag förmiddag och har man bokat något annat på den slotten. Då blir jag så här, varför löser vi inte det här bara med teknik? Varför har vi inte bara en delad kalender som har en inbjudan som alla kan editera? Man kan fortfarande ha att en person är host för demot.

Det fel, det en återkommande inbjudning i kalendern som alltid finns där. Men som sagt, jag har inte hunnit fråga det här. Det kanske finns en vettig tanke bakom. Annars kommer jag bara skapa det här för det. Det är så lätt. Igår hoppade jag in och bara så här... var typ vid lunch, jag gjorde inte demo för att personen som skulle göra det hade glömt det. Och sen var det på semester.

Sofia (27:00)
För sådär är det så här, jag tror att det är lite folk i vår bransch. Är liksom inte jättebra på det här faciliterande skillen. Eller man har inte tid för det, man utvecklar inte den så mycket. Folk orkar inte vara Scrum Mastern i teamet. För det är alltså så mycket av att vara Scrum Master är att bara sitta och boka möten. Och du har ju varit det, så att du vet liksom, så det snälla.

Så här löser man sådant här problem. Du har ju varit personen som gör det.

Madde (27:33)
är bland bara många som vill göra.

Sofia (27:36)
Ja, exakt. Ingen pallar vara ansvarig för det sen. Och vara den som ska hela tiden se till att kalendern är cirkad och är det få som kan så ska jag avboka. Alltså ingen pallar med det. Det är så himla tråkigt.

Madde (27:53)
Vad ska man göra då när man har problem? Du inrikt på det tänkte jag. just med det här, hur hamnar man här istället för bara hur löser vi detta?

Sofia (28:05)
Men jag måste ju ärligt säga att jag är fortfarande dålig på att identifiera när det verkligen bara är liksom mänskliga problem. Just innan jag lämnade jobbet för Fräleledigheten så hade vi ett sånt, säg Jag vet inte exakt vad det är, men säg att är att releaser liksom är lite för krångliga. Och då så har jag absolut identifierat att det är ett mänskligt problem.

Så att man har gjort det överkomplicerat för att man är lite rädd. Men jag kan typ känna att när man inte kan nå fram, då vill jag heller bara brute force in en teknisk lösning. att då kanske de ser hur enkelt det är.

Madde (28:53)
Ja, jag trodde de hade känt så.

Sofia (28:56)
Men det är det.

Madde (28:57)
Det var lite samma i ditt gamla team. Att du ändå hade hjälpt dem att ta fram hur man kunde göra. Och sen gjorde de inte det ändå. Är man inte redo, man inte redo.

Sofia (29:07)
Exakt. Det var ju typ det jag gjorde när jag gick. Man var i samtal med olika team och försökte förstå varför är det så här. Man måste få med dem. Inte få dem på sin sida, men få dem att se att här får göra det tillsammans. Vi som team kommer inte in till er som ett hot och tycker bara att det ni gör är dåligt. Vi förstår deras problembild och varför det har blivit så. För i det här fallet var det så

extremt kompetent folk. Jag skulle aldrig tro att de har gjort det här för att de inte är kompetenta nog att sätta upp någonting mer automatiserat. jag tror att det handlar mycket om det att träffa liksom öka mot öga och verkligen avvapna situationen ofta och typ så här, hur löser vi det här tillsammans? För vi ser problem. Ni borde också se dem. Vad är det som har hänt? Verkligen lyssna på folk.

Madde (30:06)
Ja men inte titta så mycket bakåt och skilla på folk. Hur kunde ni göra såhär utan mer hur löser vi... Eller inte heller att man ska gå direkt till lösningsmord men att liksom... Vad kan vi göra?

Sofia (30:22)
Man

måste typ lyssna på dem. Det är som att gå till psykologen. De säger aldrig att de är deprimerade. Det här är stegen. Du måste få prata ut om varför du har hamnat där. Och älta lite grann. Låta folk prata. För tror att en pris, måste få förklara varför det är som det är. Och då när man känner sig...

psykolog grej. det är så, precis det är ju så mänskliga problem. De måste få berätta varför det är så. Och till slut så blir man vänner och så man drackit en kaffe och säger man, okej men nu ska vi lösa det här på något sätt. då kommer personen säga, ja ja men vi har redan idéer. Alltså vi har redan pratat om det här, så inser man ha. Jag behöver inte göra någonting, jag behöver bara lyssna på dem.

Madde (31:14)
Ibland vill man känna sig hörd och känna att man pratar samma språk.

Sofia (31:19)
Ja ja, och så märker man istället, eller de märker då såhär, shit, nu har vi ett till team som är allierat på att göra den här förändringen och så blir det jättebra.

Madde (31:31)
Och så nerde de Licklö i alla sina dörr och releaseade flera gånger om dagen.

Sofia (31:36)
Ja, men det förstår du vad jag... Eller förstår man allt så varför jag inte...

Madde (31:43)
Jo,

men jag fattar. Alltså, absolut. Som sagt, det handlar ju typ om att människor.

Sofia (31:48)
Jag har blivit vän med dem. Att man inte är ett hot, så kommer klagar. Men just det också det här absolut hålla deras rygg. inte vara den här, så här... alltså Maddes team, de är liksom... De har så sjukt dåliga release-processer. Jag kan inte fatta att de inte förändrar det här. Eller man kan säga det lite grann kanske till sin chef eller så för att få stöd. Men på ett sätt som...

inte förminskar deras kompetens för det kommer på något sätt komma ut och de kommer märka att du går och snackar skit om dem och klagar på dem.

Madde (32:27)
Man kan vara mer konstruktiv såklart.

Sofia (32:30)
Jag pratar med dem först och så här hur kan vi då se tillsammans så att det inte blir du har gått bakom ryggen.

Madde (32:37)
En annan sak också tror jag, kanske i synnerhet om man har någon mer ledande position också, är att man på något sätt, förgår med gott exempel och normaliserar och säger att det här är svårt. Så att man inte känner det här, att man vågar inte ställa frågor, att man vågar inte säga att man inte förstår arkitekturen eller någonting. Skapa det utrymmet för att kunna känna osäkerhet. Så blir det liksom inte det här man ska hålla på.

mörka och försöka göra någonting. Det påminner mig så mycket om ett team jag var i för länge sedan. var det en konsult som inte var så kunnig som man kanske trodde. Och jag frågade honom flera gånger så typ, behöver du hjälp? Är det någonting som är oklart liksom? Förstår du inte kraven? Alltså är det någonting jag kan hjälpa dig för att du ska förstå bättre? Han bara nej nej, det är lugnt, det lugnt. Kommer han kanske att implementera så här HMAC, Authentication, Authorization eller vad säger man.

Och det han byggde var bara så här... Nej, det här är Helt fel. Men han hade nog stolthet att han skulle göra allting själv utan att ta hjälp eller nånting. Det hade verkligen bara kunnat lösas mycket bättre av att vi pratade och inte samarbete.

Sofia (33:54)
Ja, men som du säger att visa att jag tycker det här är skitsvårt. Jag försöker också säga det när man presenterar Någon så här, så här ska vi göra autentiseringssystemet. Det är skitsvårt att förstå. För mig, jag fattar knappt det här. Jag svårt att hålla reda på det i mitt huvud. Så bara så vet, jag har hållit på med det här i flera månader nu. Så om du inte förstår det på tavlan direkt.

så är det okej. Du kan fråga mig tusen gånger. Jag lovar. Alltså verkligen. Och till och det räcker inte ofta.

Madde (34:32)
verkligen. Det inte lätt. tror att många känner nog igen sig i det.

Sofia (34:34)
Nej.

Ja, och särskilt vid så här, originalförfattaren av artikel skrev att han har jobbat med folk som inte vill lära sig nytt, pallar inte, är liksom dåliga. Alltså om du inte kan göra någonting åt det, liksom, ja, de är kassa. De är ganska inkompetenta. Det sämsta man kan göra är också så fortsätta få dem att vara dumma. Då får man kanske också så här

Man kanske får göra samma sak och säga, men det här är jättekomplicerat. Fråga mig tusen gånger för att då vågar de.

Madde (35:12)
Man får väl komma till roten. Varför känner de sig osäkra på att lära sig nåt nytt? Många har samma problem. Det handlar bara om hur mycket man pratar om det.

Sofia (35:23)
Jag är absolut nyfiken på att höra om folk har varit med om sånt. Hur gjorde ni det här förändringsarbetet? Vad gjorde du för fel i början?

Madde (35:36)
Ja, det får man gärna skriva på vår Discord och berätta lite.

Mm. Nej men ska vi ta och knyta ihop

Sofia (35:44)
Så gör vi.

Och så går vi och äter några saffronbullar. För idag är det faktiskt... tre... tredje? Ja, det vänder. ⁓ shit.

Madde (35:50)
Jag fanns

Vad sa du igår?

Sofia (35:54)
Ja, okej. Hör det bra.

Madde (35:57)
Ha det bra allihopa, hejdå!

Sofia (35:59)
Hej!