On Dec 31, 2:20 pm, Joakim Ohlrogge <joakim.ohlro...@gmail.com> wrote:

Ja, jag har själv väldigt länge tyckt att underhållsbarhet är oerhört
viktigt, och den förmågan borde helt klart vara ett viktigt kriterium
vid en anställning, men det känns tyvärr som en väldigt avlägsen dröm
med tanke hur de flesta rekryteringerna brukar gå till.
Alldeles för många företag använder sig av rekryteringsföretag med
näst intill obefintlig (enligt min erarenhet i alla fall) kompetens
(trots att företagsnamnet kan ibland ha ett "IT" som suffix för att
försöka antyda att de har kompetens inom området).
En gång för ganska många år sedan blev jag t.ex. kontaktad av ett
rekryteringsföretag som tyckte att min CV såg intressant ut bortsett
från ett potentiellt bekymmer, nämligen att det inte stod något om
HTML-kunskaper.
Det hade jag medvetet utelämnat från CV:n eftersom jag tyckte det
kändes lite för trivialt att ens nämna HTML när jag bl.a. hade nämnt
ASP, JSP och XHTML.
Det var tydligen feltänkt då man tvingas befatta sig med amatörer som
inte har en aning om t.ex. skillnaden på XML och SQL, och inte duger
till mycket mer än att jämföra exakta bokstavsförkortningar (men html
och xhtml kan tydligen bli för avancerat att skilja på) och försöka
jämföra kandidatens antal årserfarenhet av språk X, ramverk Y,
applikationsserver Z etc.
Dessutom klarar de även av att vid en intervju kontrollera att
kandidaten har välputsade skor och ser generellt välvårdad ut, men det
finns nog inte många på rekryteringsföretagen som är i närheten av att
kunna bedöma en utvecklares kunskaper om förvaltningsbar källkod.
Det baserar jag på min egen erfarenhet, och jag har faktiskt under
årens lopp träffat rekryterare från de flesta av vanligaste
rekryteringsföretagen och det brukar se likadant ut, dvs ingen som
helst spetskompetens inom det aktuella verksamhetsområdet dvs
systemutveckling.

Dock kan eventuellt situationen ha förändrats de senaste två-tre åren
(även om jag tvivlar) eftersom jag succesivt har blivit alltmer
irriterad på de företag som anlitar rekryterinsgföretagen att jag
numera sällan brukar bry mig om att söka sådana jobb, även om
jobbbeskrivningen i princip kan låta intressant ibland.
Anledningen till att jag inte gärna söker jobb där företagen har
anlitat rekryterare är helt enkelt att jag vill jobba tillsammans med
likasinnade (dvs de mest intresserade 5-10%:en utvecklare som Nicas
Nilsson nämnde) och jag har lite svårt att se att sådana personer
(under förutsätning att de har inflytande över rekryteringsprocessen)
vill anlita ett rekryteringsföretag som i princip bara kan servera
kreti och pleti kandidater (såvida de inte av ren tur råkar hitta
någon som faktisk har en seriös kompetens och inte bara välputsade
skor).
Det är f.ö. inte heller bara rekryterinsgföretagen som är dåliga på
rekryteringar, utan många andra verkar också vara beredda att köpa
grisen i säcken, och tror att man automatiskt är kompetent bara för
att man har X antal års erfarenhet av något.
Jag har själv tackat nej till ett erbjudande från ett konsultföretag
för några år sedan just pga att erbjudandet kom så oerhört
lättvindigt, och det kändes som IT-chefen lika gärna ha plockat in vem
som helst från gatan, och ställde knappt några frågor alls till mig,
och ingen fråga över huvud taget som syftade till att försöka
undersöka min kompetens...
Då tänkte jag nämligen att det var stor sannolikhet att kollegorna
(som har blivit rektyterade på samma sätt) tillhör den majoritet som
producerar hemsk ravioli/spagetthi-kod utan något större intresse/
kompetens för långsiktigt förvaltningsbar kod.

On Dec 31, 3:07 pm, Per Arneng <per.arn...@anyplanet.com> wrote:

Jag är tveksam till att kräva ett omfattande arbetsprov (men de som
gör det borde då åtminstone erbjuda lite betalning som vissa gör) men
tror faktiskt man skulle kunna komma ganska långt med att tillämpa
kodgranskning på en intervju.
Med andra ord skulle man kuna låta kandidaten titta på lite dålig
källkod som inte är bra med avseende på olika aspekter, t.ex. dålig
semantik i typerna/metoderna/variablerna, dålig inkapsling, multipla
likadana if/switch-satser i en klass (istället för att använda
polymorfism med State eller Strategy pattern), duplicering, magic
value, återanvändning av samma variabel men med nytt innehåll längre
ner i metoden, metoder som tar emot en till synes "generell" typ men
som i implementation kräver en specifik (dvs byter mot Liskovs),
metoder som använder HashTabeller (istället för domänobjekt) eller
"Object" i publika metodsignaturer och som måste downcastas till vissa
typer eller hanteras på annat sätt utan intention-revealing
interfaces, high coupling, low cohesion o.s.v. o.s.v.

Det förekommer att vissa företag tillämpar kodgranskning, men i de
fall jag har fått göra det så har det varit relativt få kodexempel,
och jag tycker att en diskssussion om konkreta kodexempel borde
användas i mycket större omfattning i rekryteringar.
Bl.a. för att det helt enkelt är mycket mindre tidskrävande för
kandidaten, men tror också det är lättare att tydligt försöka fånga
upp faktiska kunskaper om olika viktiga aspekter av förvaltningsbar
kod, jämfört med att låta kandidaten skriva egen kod. Jag kan nämligen
tycka att det alltid finns potential för förbättringar, och om man
själv ska skriva kod som skall bedömas så kan det vara svårt att veta
var man skall lägga ribban.
Det är nämligen så att om man gör det lite för snyggt och onödigt
flexibelt så kan man få YAGNI-kommentarer, men å andra sidan om man
inte gör det tillräckligt flexibelt så kan man i stället få
kommentarer om att man i större omfattning faktiskt borde ha lagt in
fler hook points (open-closed principle).
Genom att helt enkelt sitta tillsammans och diskutera kodexempel så
tror jag faktiskt man har goda möjligheter om en utvecklare har det
rätta tänket om vad som gör kod förvaltningsbar/icke-förvaltningsbar.

/ Tomas Johansson