[Conny Westh]

Vad har programmeraren gjort tidigare, är det en person med många uppdrag bakom sig så bör de kunna lösa problem som de aldrig gjort tidigare.

Man kan ju provanställa som någon mer föreslog och du märker på de två första veckorna hur de funkar med personkemin. Parprogrammering håller jag med om att det är en bra idé att köra med. Men det är viktigt att personen får en fair chans att göra ett bra jobb.

Parprogrammering brukar anses som ksotsamt men enligt min egen erfarenhet så gör två personer som fungerar bra ihop tre mans jobb på samma tid. Dessutom är det mer kompetensutvecklande för de enskilda individerna än någon annan arbetsform jag testat (inkluderat lärarledd utbildning).

Ett stort problem i alla projekt är kontinuerlig kompetensöverföring mellan individer. Det kan man oftast lösa med just parprogrammering. Dessutom höjs kvaliten och buggar minskar.

Är det en nybörjare så kan man aldrig använda stresstest för att testa dem, då måste de ha betydligt längre tid på sig typ 6 månader. Men då är oxo kraven man kan ställa betydligt lägre, det är ju en newbie, alla har varit newbie en gång i tiden.

Generellt är stresstester för att testa programmerare väldigt felriktade. En programmerare ska vara en lugn och sansad person som verkligen sätter av tid för att fundera på att ta fram en bra lösning. Det är totalt kontraproduktivt att göra stresstester på den typen av kompetens. Man riskerar tvärtom att få slarvputtar som klarar detta men som inte klarar att lösa komplexa problem.

Bättre anser jag det är att använda en kravspec som är realistisk från ett tidigare litet projekt med funktionella krav (dvs verksamhetskrav) och se hur programmeraren lägger upp sitt arbete och hur programmeraren lägger upp en metod för att lösa problemet.

En programmerare som självständigt klarar att lägga upp en tillförlitlig metodik för hur han ska lösa ett problem är det sannolikt mycket högre chans att de kan lösa komplexa problem i framtiden. Det är mycket kontraproduktivt att testa befintliga kunskaper i ett specifikt programspråk. Pogramspråken kommer och går, de växlar hela tiden men arbetsmetodiken för att lösa problem är mer generisk och tidlös. Det är viktigt att programmeraren har en analytisk och kreativ inställning (ja det är en paradox) och att man är unlyssnande till beställarens krav.