Bra/Dåliga Rekryterare

Det här otyget med att tvingas ”gradera” sin egen kunskapsnivå känner jag igen från många ”massförmedlare” av uppdrag och anställningar. De ser säkert detta som genialiskt, för sin bedömning, men bedömningen är helt meningslös, för jag som kandidat har ju ingen som helst aning om vilken nivå andra kandidater befinner sig på. Så deras system är helt enkelt ”hål i huvudet”.

Jag har 30 års erfarenhet som utvecklare. och jag har använt hur många olika tekniska buzzwords som helst i mitt yrkesliv.

Men rekryterare som kollar efter Buzzwords är ju totalt inkompetenta.

När man ska rekrytera utvecklare så är det viktigaste att kandidaten förstår de grundläggande principerna för hur man ska programmera objektorienterat, inte vilket programspråk, eller komponent man redan har jobbat med, det är fullkomligt ointressant.

Det är viktigt att man som utvecklare kan förstå användarnas krav och kan omvandla dem verksamhetskraven till programvara som är lätt för användaren att förstå och använda.

Det är ju helt absurt om man ratar kandidater som har skrivit att man kan ”ADO” i sitt CV men rekryteraren vill ha någon som kan ”ActiveX Data Objects” (de som är insatta vet att det är samma sak, men rekryteraren visste inte det, så jag fick inte uppdraget). Men det är vad som händer om rekryteraren letar efter Buzzwords som de inte förstår.

De rekryterare som letar efter rätt ”buzzwords” i mitt CV är fullkomligt inkompetenta.

Jag har träffat 4 kompetenta rekryterare i hela mitt liv, de frågade helt andra saker.

Exempelvis hur jag ”tänker” när jag programmerar, hur jag löser större uppgifter (delar upp i mindre delar givetvis). En del andra mycket intressanta frågeställningar. Jag kände mig riktigt glad och upprymd efter att ha blivit intervjuad av dem. Jag gav till och med komplimanger till rekryterarna som var så bra. De ställde såna frågor som jag också tycker är viktiga och som jag vill lyfta fram i min profil.

Såna riktigt kompetenta rekryterare behöver vi se mer av!

Format på prislista till VISMA/SPCS

Jag tror jag blir galen!

Hur svårt ska det vara att hitta en teknisk specifikation på hur en prislista (CSV-fil) ska se ut som passar att importera i VISMA/SPCS Administration?

Jag håller på att hjälpa en snickare som har fått en prislista med ett 350-tal artiklar från sin leverantör att importera den prislistan till hans artikelregister för faktureringen.

Jag letar efter en filspecifikation på en prislista för import i SPCS Adminiistration, jag har hittat ett prisfilter (”Excelpriser.flt”) som kan svälja en CSV-fil man skapar med Excel, men jag behöver en specifikation på en faktisk prislista så jag kan generera en fil att importera i SPCS, men gått bet på att hitta ett enda Exempel.

Jag behöver så att säga veta vad kolumnnamnen ska heta och vilka typer (text, numeriskt, kod) det är. Det förekommer även stafflade priser (olika pris vid olika antal, typ ett pris om man köper 1 artikel av en vara och ett annat pris om man köper en lastpall med 120 artiklar av samma).

Det program jag gjort läser in olika prislisteformat och exporterar till flera olika andra format. Varav VISMA/SPCS är ett.

Det är INTE aktuellt att ge VISMA i uppdrag att ordna detta, då jag är utvecklare och vill försöka lösa detta själv. Då det är en intressant uppgift.

VISMA/SPCS har inte publicerat någon filspecifikation, därför min fråga här i forumet. De gör sånt jobb på uppdrag mot betalning, nu vill jag lära mig detta, då jag bygger ett program som ska klara att konvertera från flera olika leverantörers prislistor till flera olika faktureringsprogram.

Checklista för nya medarbetare i utvecklingsteam (2020-02-25)

Jag brukar använda några enkla principer för att det ska gå snabbare att få in nya medarbetare i teamet så de blir produktiva så snabbt som möjligt :

* Självfallet Enhetstester och Integrationstester
* Dokumenterad kodstandard beskrivet i ett dokument
* Software Architecture Document (SAD)
* Diskutera regelbundet kodstandard och rutiner samt kom överens i teamet hur man löser sånt som olika utvecklare löser på helt olika sätt (det brukar vara sånt som behöver dokumenteras så alla jobbar någorlunda lika i teamet)
* Några små enkla färdiga inroduktionsprojekt som visar hur man VILL att koden ska se ut. Dessa kan den nya utvecklaren alltid gå tillbaks till och se hur man kan lösa vissa uppgifter.
* Fokuserade halvdagskurser för nya medarbetare INNAN de får jobba i projekt
* Webquests (lite som Multisoft gör vid sina rekryteringar)
* Det är en omöjlig uppgift att kräva att alla utvecklare ska ha alla kunskaper från dag ett. (det har man inte ens om man har 30 års erfarenhet), varje team har sina rutiner
* Utse en mentor som jobbar intensivt med den nya projektmedlemmen i minst 2 veckor, prio är kunskapsöverföring, INTE att maxa kod-output under den tiden
* Se till att etablera en ”social trygghet” i teamet, så ALLA vågar ställa dumma frågor, utan att skämmas, eller ”bannas”, annars är det kontraproduktivt.
* Nya teammedarbetare, SKA ställa massor av ”dumma frågor” annars har man inte tillräckligt social trygghet i teamet. När prestige dominerar så blir det problem.
* Parprogrammering är ett alldeles utmärkt sätt att snabbt få in nya medarbetare i de etablerade stabila rutiner man redan har.

Jag brukar alltid ställa en miljon dumma newbie-frågor de första 2 veckorna i ett nytt team (det är ett sätt att snabbt lära känna de andra teammedlemmarna), detta trots att jag har jobbat över 30 år som utvecklare. Vissa medarbetare/Projektledare förstår inte att det är bättre att fråga 30 gånger för mycket än en gång för lite.

Ja, det har inneburit att jag blivit utslängd ur vissa projekt, men det var väl lika bra det. Om inte personkemin funkar från start så blir det inte bättre.

/Conny Westh 2020-02-25

VS2015 C# Best Pactices (2016-02-22)

Microsoft Visual Studio 2015