mjukvaruföretag, inte sabotera inte din långsiktiga success_

Under årens lopp har jag betalat mycket uppmärksamhet till hur företag rekryterar programmerare. Under den tiden har jag märkt hur chefer ofta gör anställningsbeslut som verkar vettigt på kort sikt, men som leder till långsiktig kaos. Jag har sett den typ av förödelse som detta kan utlösa, och hur förödande det kan vara att företagets framtid.

Jag skulle vilja säga några ord om detta i dag.

De företag som jag har observerat typiskt uppmärksamma frågor som industrin bakgrunder, år av erfarenhet, och så vidare. De vill veta vilka typer av projekt som sökandena har arbetat på, som kompilatorer och operativsystem de är bekanta med, vilket kommunikationsprotokoll och programpaket som de har använt, och så vidare. Många vill också veta om de anställdas arbetsmoral och personlighet, men i slutändan, de anställningsbeslut ofta koka ner till den anställdes arbete erfarenhet och hur mycket utbildning som personen skulle kräva.

Alla dessa är viktiga, förnuftiga överväganden. När jag observerade dessa företag men jag har märkt att de flesta av dem, ungefär 80% eller mer-betalats liten eller ingen hänsyn till huruvida den sökande hade en ren, lättläst programmering stil. De var djupt oroad över huruvida sökanden kunde få jobbet gjort, och inte verkar bry sig så mycket om huruvida deras programvara kan lätt förstås och modifierad av andra, år på vägen.

Till viss del är detta förståeligt. När allt är det omedelbara målet för de flesta företag att utveckla arbetsmetoder produkter som de kan sälja. Vad många glömmer är dock att de ska vara maratonlöpare, inte sprinters. De måste tänka mer i termer av efterbehandling hela loppet, och mindre i termer av att uppnå kortsiktiga segrar.

Det förråder också en viss naivitet om den omedelbara skador som kan orsakas av dålig programmering stil. När allt är även den bästa mjukvaran sällan felfri. En programmerare som skriver ren, kommer läsbara programvara kunna felsöka sitt eget arbete mer tillförlitligt än någon som skriver lapptäcke kod. Det senare kan sägas ge fixar snabbare (och även det är diskutabelt!), Men resultaten kommer att vara otillförlitlig-och när tiden är kort, det är en lyx som företagen inte har råd.

Arbetsgivarna bör också komma ihåg att bra programmering stil är inte något som lätt har lärt. Alla behöriga programmerare kan lära mekaniken i språket syntax och samtal funktion, men det är någon som förstår lite om artisteri av strukturerad programmering eller ordentlig objektorientering osannolikt att bemästra dessa saker på jobbet. Jag har sett detta hända (eller snarare, inte att hända) gång på gång. Detta, trots överflödet av böcker och tidskrifter som diskuterar denna fråga mycket utförligt.

Jag tror också att företag bör ägna större uppmärksamhet åt den blivande medarbetarens tekniska skrivkunskaper, trots allt, kan extern dokumentation (t.ex. manualer, designen dokumentation) är kritisk till programvarans underhållet. Dessutom, enligt min erfarenhet, programmerare som skriver bra på engelska är mer benägna att skriva programvara för. Och varför inte? Programmeringsspråk är ytterst just det språk. Någon som kan uttrycka sig väl på engelska är mer benägna att kommunicera tydligt och effektivt i sin källkod också.

Av dessa skäl uppmanar jag alla företag som är anställa en programmerare för att ställa skarpa frågor om en sökandes kodning stil. Hur namnger han sina variabler? Hur många rader kod bör en funktion ockupera? Använder han globala variabler, och i så fall när? Vilka typer av böcker har han läst på programmering stil? Helst ska företagen också be om prover av en sökandes källkod och teknisk dokumentation, för att kontrollera att dessa lärdomar omsätts i praktiken. Det tar lite extra ansträngning, men det kan hjälpa ett företag att undvika att offra långsiktig framgång för den skull tvivelaktiga kortsiktiga vinster.