Hej, jag vill fört påpeka att syftet med denna krönika och även andra krönikor jag skriver är framtagna på ett sådant sätt att jag vill få igång en tankeverksamhet hos alla som läst dem.

Jag satt för ett tag sedan i en open space diskussion med en hel del högt uppskattade programmerare i Sverige. Vi pratade om allt möjligt; bla OR-Mappers, refactoring av kod, om redundant kod etc… Det fanns en hel del motståndare till saker som sades, mycket handlar om att många idag tror sig bygga bäst för att det är det bästa de känner till.

Hur skall man kunna skriva snyggare och bättre kod om man inte vet hur man kan göra annorlunda? Jag tänkte för mig själv många gånger när det klagades på OR-Mappers, när det klagades på att ha många korta funktioner istället för få men stora, hur orkar folk skriva all denna kod? Och återigen ha alla dessa klassiska fel de alltid om och om återskapar.

Ok jag är lat och bekväm av mig men jag är lat på ett bra sätt eftersom min lathet handlar om att slippa göra samma saker om och om igen. Jag vill inte ha redundant kod för det tar bara längre tid att skriva. Jag vill inte använda TSQL om jag kan slippa i 90% av fallen, jag orkar inte skriva TSQL och debugga dem och stå ut med alla problem de kan orsaka som gör att affärsnyttan i applikationen, dvs domänen, blir lidande istället för fokusera på det som är viktigast.

Jag optimerar inte min kod från start för det tar tid, Speciellt då jag inte vet om jag verkligen måste optimera koden. Optimeringstester m.m. är det sista jag gör för att hitta flaskhallsar och optimera på just de ställen istället för att göra det i onödan på många ställen. Varför skriva flera Stored Procedurer för att hämta tabeller som man sedan ändå fyller upp klasser med? När så triviala saker kan skötas automatiskt så jag kan fokusera på affärsnyttan istället. Varför skriva redundant felhantering, redundanta loopar när det går att refactorera dem till en mer återanvändbar kodbas, för att slippa skriva samma saker om och om igen?

Är nu en lat/bekväm utvecklare även den bättre? Många kan se lathet som något negativt. Lathet är inte alltid positivt, men man kan se lathet på oliak sätt om man vill: bra såväl som dålig. Den bra latheten handlar om att effektivisera sitt arbete. Man vill fokusera på nyttan och komma ifrån sånt som är onödigt,  vi effektiviserar saker för att underlätta vårt arbete. På så vis är den rätta lata utvecklaren också den bättre.

Det är i o fs bara halva sanningen. För att kunna vara den lata utvecklaren måste man vara icke lat för att lära sig att bli latare. Man måste hela tiden lära sig hur man kan effektivisera sin kod för att enklare bli produktiv med bra kvalité. Lära sig de nya verktygen, nya principer, nya refactoreringar m.m. Som lat utvecklare skriver man inte bara lite och återanvändbar kod.

Som lat utvecklare gör man massa andra lata saker. Exempelvis skriva enhetstester för att inte man orkar testa samma sak om och om igen utan man vill hellre automatisera dem. Man orkar inte med massa kryptiska felmeddelanden utan bygger en tydlig felhantering och tydliga kontroller för att exempelvis kontrollera inputparametrar. Som lat utvecklare försöker man hitta nya sätt för att bli ännu latare för att helt enkelt slippa göra samma saker om och om igen.

Vad har dumhet med saken att göra då? Att vara en dum utvecklare är nästan viktigare än att vara lat. En dum utvecklare tänker och lever alltid utanför boxen, de ifrågasätter allt. Man är som ett barn, man accepterar inte nej som ett svar utan vill hela tiden veta varför. En dum utvecklare är kreativ i sitt tankesätt och låter sig inte bara lita på sådant som redan finns idag.

Dumma idéer blir oftast smarta idéer. Se bara på produkten IPhone.  Du behöver inte vara smart för att använda den, ändå är den marknadens hypade telefon idag.

Jag vet, med erfarenhet från mitt jobb att så fort en dum fråga ställs brukar det oftast vara den bästa frågan.  En dum programmerare tillåter sig inte bara få ett krav utan frågar alltid varför och ju barnsligare fråga ju bättre.  Vi kan ta ett exempel angående en diskussion som jag en gång lyssnade på.

Kunden:  Man skall kunna skriva ut på ett A4 så det blir tydligt.
Utvecklaren:  Ok, Men vad skall vi skriva ut då?
Kunden: Allt skall man kunna skriva ut.
Utvecklaren:  Hur vet vi om det är tydligt då?
Kunden:  För jag säger att det skall vara det, det är ett krav ni skall lösa. Hur svårt kan det vara?
Utvecklaren: Vad är det för skrivare? Laser, bläck? Nålskrivare?
Kunden: Är du korkad nu eller gör du dig till?
Utvecklaren: Förlåt att jag är dum men jag förstår inte kravet.
Kunden: Jag sa ju kravet.
Utvecklaren:  Ja men, hur vet vi vad som är tydligt när vi inte vet vad man skall kunna skriva ut på?
Kunden:  Utgå från laserskrivare, det har nog alla idag.
Utvecklaren:  Men om man inte har det?
…
Den diskussionen blev personlig efter ett tag då kunden och andra utvecklare idiotförklarade denna utvecklares frågor.  De tyckte han var dummare än ett barn som ställde så korkade frågor. Lustigt nog var han den som byggde bästa utskriftmodulen till applikationen.

När jag sätter upp ett utvecklingteam eller får välja vilka jag skall arbeta med, brukar jag alltid ha som krav att ha med minst en eller två mer oerfarna utvecklare än de andra och även några som är mer erfarna än mig själv. Den stora anledningen är just att det är oftast de som ställer de dummaste frågor som leder till de bästa lösningarna. Detta är guld värt.  Det blir så lätt att man blir så hemmablind i det man gör att man glömmer av de enklaste detaljer. Sen så lär sig de mindre erfarna att bli bättre vilket till slut lyfter upp hela laget.

Vad jag syftat på hela tiden är den smarta latheten, inte den lathet som handlar om att man slarvar eller kör med copy & Paste för det är enkelt. Den dumma latheten är den som orsakar problem istället. Medans den smarta latheten faktiskt handlar om att bli mer produktiv och effektiv i sitt arbete.
Hur lat (effektiv) och dum (kreativ) är du?