Understrukna ord finns i lektionsordlistan. Tryck på ett ord för att se alla översättningar. Lägg till eller redigera ord i messages/glossary.json (alla språknycklar du lägger till visas i rutan).
Core workplace & communication
Agreeing/disagreeing about technical decisions
Jag håller helt och hållet med om att vi ska använda det ramverket för projektet.
Det låter faktiskt som en väldigt robust och bra lösning på problemet.
Jag tror också att det absolut bästa är att bygga en separat mikrotjänst för detta.
Jag är helt med på din idé, det kommer att bli både snyggt, snabbt och rent.
Det där är en riktigt smart metod, vi spikar det och kör på det spåret!
Jag håller med dig, den arkitekturen kommer att spara oss mycket tid framöver.
Du har helt rätt, applikationens säkerhet måste naturligtvis komma i första hand.
Jag stödjer det tekniska förslaget till hundra procent, det är klockrent.
Jag förstår precis hur du tänker, och jag tycker att det låter oerhört vettigt.
Det där var ett riktigt bra argument för att äntligen uppgradera vår gamla databas.
Jag förstår din poäng och vad du vill uppnå, men jag är inte helt säker på att det är rätt väg.
Jag är lite orolig för att den föreslagna lösningen blir för tung att underhålla på sikt.
Har vi verkligen tänkt på hur det här vägvalet påverkar systemets prestanda?
Jag förstår varför du föreslår det mönstret, men finns det inte en betydligt enklare väg?
Jag tror faktiskt att vi måste tänka ett varv till på arkitekturen här innan vi bestämmer oss.
Jag håller delvis med i ditt resonemang, men vi måste lösa skalbarheten först av allt.
Min största oro är att vi tyvärr bygger in oss i ett hörn om vi gör på det sättet.
Kan vi åtminstone överväga att använda en annan typ av databas för just den här datan?
Jag tror faktiskt att en enklare och mer rak lösning är mycket bättre för oss just nu.
Låt oss inte överarbeta och komplicera det här problemet, vi behöver bara en snabb fix.
Jag är personligen inte helt övertygad om att det där är rätt teknisk väg att gå.
Vad är den egentliga anledningen till att vi inte bara gör på det beprövade standardsättet?
Skulle vi inte få betydligt bättre prestanda och svarstider om vi gör så här istället?
Jag förstår din innovativa lösning, men jag tror tyvärr att den skapar ny teknisk skuld.
Jag föreslår att vi systematiskt jämför båda alternativen innan vi fattar ett slutgiltigt beslut.
Jag respekterar din åsikt fullt ut, men jag tror att ett annat bibliotek skulle passa oss bättre.
Kan vi ta upp den här komplexa frågan på nästa arkitekturmöte för att vara helt säkra?
Jag ser ganska stora risker med att lansera funktionen utan att ha skrivit fler integrationstester.
Jag håller helt med om slutmålet, men vägen dit kan vi nog göra på ett lite annorlunda sätt.
Det kanske fungerar felfritt just nu, men det skalar nog inte särskilt bra i framtiden.
Jag gillar verkligen din idé, men vi saknar tyvärr tid i sprinten för att genomföra den nu.
Låt oss A/B-testa din idé i produktion och se vad statistiken och användarna säger!
Jag tycker det är alldeles för tidigt att börja mikro-optimera koden just på det stället.
Det där känns lite som en omväg logiskt sett, kan vi försöka göra koden mer direkt och läsbar?
Jag stöttar din nya design fullt ut, användargränssnittet ser väldigt modernt och fräscht ut.
Jag motsätter mig inte alls förslaget, men vi måste se till att informera kunden om ändringen.
Jag tror att det övriga teamet skulle föredra att vi strikt håller oss till vår kodstandard.
Vi kanske borde bygga ett litet bevis på koncept (proof-of-concept) först innan vi binder oss?
Ditt nya förslag minskar komplexiteten i systemet avsevärt, vilket jag verkligen uppskattar.
Jag är väldigt tveksam till att introducera ännu ett helt nytt programmeringsspråk i kodbasen.
Det är ett fantastiskt bra initiativ, men faller det verkligen inom vår nuvarande tidsbudget?
Jag är ärligt talat orolig för att just den integrationen kommer att ta alldeles för mycket tid.
Låt oss helt enkelt rösta om saken i teamet om vi inte lyckas komma överens.
Jag viker mig i den här frågan, vi kan testa ditt förslag nu och sedan utvärdera resultatet sen.
Ditt starka argument övertygade mig faktiskt, vi släpper mitt förslag och kör på din linje.
Jag är väldigt skeptisk till den där tredjepartslösningen på grund av deras bristande säkerhetshistorik.
Vi verkar vara ganska oense om metoden här, kan vi be en senior utvecklare om en tredje åsikt?
Jag tror vi krånglar till det helt i onödan med den där avancerade mappstrukturen.
Din lösning på problemet är extremt mycket mer elegant och effektiv än min.
Låt oss enas om att det här är en väldigt bra och rimlig kompromiss för båda parter.
