Code reviews är hell

Fast förr eller senare vill man ju ha sådana saker lösta. Och då finns det ju ingen anledning att de inte är lösta innan man presenterar arbetet för sina kollegor, snarare än efter. Så att kollegorna kan, för att använda dina ord, "fokusera på viktiga saker".

Om man bygger upp sin identitet kring en enda ctrl-d eller vad lint gör autmatiskt, då är det något som är fel.

Jag var nr2 i Sverige inom ett helt annat gebit när jag slutade. Inom det yrket, så sket jag i sk importer och indenteringar och gick på lite svårare saker. Och du skall veta hur många kommentarer jag fick kring importerna och indenteringarna från autister. Jag helt enkelt ignorerade detta autistiska draget många har, alltså att det måste se ut på ett sätt, eller vara på ett sätt och la min kraft på det som är viktigt. Jag har, som jag tidigare sa, suttit och kliat mig i huvudet när 2 seniora programmerare slogs om hur en if /else sats skulle se ut. Gör man det, så handlar det bara om prestige. Och det blir jobbigt för människor runtomkring.

Det spelar inte så stor roll att toarullen sitter bakofram, om man ändå får papper i slutet. Sedan kan ju människor som bara måste ha saker enligt så kallad "lag" få panik när inte rullen sitter åt rätt håll.

Det är en ren läsbarhetsfråga. Ungefär som att försöka stava rätt när man skriver prosa. Av oklara skäl så verkar du försöka göra det, även om det, antar jag, bara är autister som bryr sig om stavning.

Att inte trycka på Ctrl+D (eller vad det nu råkar vara) innan man checkar in sin kod är bara respektlöst mot sin omgivning. Kod är svår nog att ta in utan den kognitiva overhead som kommer med att behöva bena ut flödena när den är oindenterad.
Utöver det så har du nu troligen spenderat mer tid på att bara här på Flashback försvara ditt ställningstagande att inte indentera kod än det hade tagit dig att indentera den från början (Ctrl+D, som sagt), så du framstår inte riktigt som någon som utnyttjar sin tid särskilt väl ;-)

Och självklart är det lämpligt att toarullen sitter så att man får hjälp av hållaren att riva av pappret. Att man inte bryr sig om grundläggande ergonomi för sin omgivning är inte en kvalitet, det är en defekt.

Men sedan så kommer du inte bli nr 2 i Sverige på något heller.

Weird flex. Hur mäter man ens något sådant?

Vad spelar det för roll? Jag blev det, och jag blev det inte för att jag höll på att bry mig om människor satte toarullen på fel håll. Jag såg till vad som var viktigt och utnyttjade denna svagheten andra hade i att de måste ha obetydliga detaljer på samma nivå som väldigt viktiga detaljer. Selektiv noggrannhet kanske man kan säga. För egentligen så var jag inte så bra på yrket. Kan låta konstigt.

Vid en review skulle jag inte ens märka om det fanns för många importer eller om if else satsen stod fel för någon annan. Medan en annan gäng som bygger hela sin identitet på att hävda sig, skulle såklart känna tillfredställesefaktorn gigantisk. Men sedan förblir de nog medelmåttor som följer andra.

Det spelar roll eftersom att ungefär 99 % av allt som skrivs här är hittepå.

Tro det eller ej så går det att både vara noggrann och samtidigt bygga saker som fungerar och är robusta. I många fall är det just noggrannheten som gör koden robust.

Sammanfattningsvis... det finns fortfarande alldeles för många aspbergare och folk med medberoendeproblematik i branchen. Alternativt, jobba inte med banksystem.

Varför måste folk kritisera under code reviews? Klarar man inte av att visa på risker, funktionella problem, integrationsproblematik, avvikande kodstil eller what ever, utan att den som skrivit koden känner det som ett nedslående påhopp, så ska man inte göra code reviews i ett team. Eller ens vara en del i teamet. Oavsett hur duktig man är i övrigt. Eller om man så kände Turing.

Och ett råd till TS. Separera dig själv känslomässigt från jobbet om du har aspbergare som kollegor. Eller ännu hellre, sök dig någon annanstans där du kan utveckla din passion med nyfiken glädje.

Om det är så att dina kollegor är ok och det är komplexitet och bristande överblick över alla system- och verksamhetsbegränsningar som är jobbigt.. välkommen till javautveckling i bankvärlden.

Ah, det är både och skulle jag säga. Det finns verksamhetsbegränsningar och kollegorna löser det genom att vara väldigt aspiga om skitgrejer för att de inte kan påverka det som verkligen betyder någonting. Eller det är min uppfattning i alla fall.

Det är min erfarenhet med. Och det där är en frustration och dissonans som är rätt jobbig att leva med. Har ni förresten inte Kotlinifierat kodbasen än?

Hur många års erfarenhet har du av att jobba som utvecklare på heltid?

Hur många års erfarenhet har du av att jobba inom domänen fintech?

Tror inte du skall ställa allt för höga krav om du är ny (som jag spontant uppfattar dig som väldigt junior utvecklare).

Vi måste alla lära oss och utvecklas med vägen, och det bästa du kan göra är just att lära dig, och inte ta kritiken/fel som misslyckanden eller personliga påhopp.

Om du jobbar flera dagar på en sak utan feedback från dina teamkamrater är det inte konstigt att det blir så som du beskriver.
Det låter också som att du kanske tar review lite för personligt. Review ska vara sakligt och utvecklande för dig och de andra i teamet. Det ska skapa diskussioner om hur ni vill att er kod ska se ut så att ni kan komma överens.

Hur många rader kod har ni i genomsnitt i en MR/PR? Jag förespråkar så små som möjligt. En MR behöver inte vara en komplett funktion i hela vertikalen. Kanske bara ett interface som man kan diskutera kring i teamet. Blir mycket bättre review av det. Men framförallt diskutera arkitektur med seniora utvecklare innan du bygger nya grejor.

En annan sak jag kan rekommendera är conventional comments för att få tydliga och konkreta kommentarer.
https://conventionalcomments.org/

Review är kanske inte alltid roligt, men helvete ska det inte vara.