10x programmører er et varmt emne at diskutere i softwareindustrien i dag, så jeg tænkte, at det ville være en god idé at dele mit synspunkt i denne henseende.
Helt ærligt kender jeg ikke den nøjagtige definition af en 10x programmør, men jeg antager, at det refererer til hyperproduktive programmører (hvilket måske ikke svarer til præcis 10 gange produktivitet, men til et betydeligt niveau tæt på eller mere end 10 gange).
Baseret på få succeser, jeg havde, mens jeg leverede ultra-store stykker software til startups og virksomheder, og arbejdserfaring med et par top-notch udviklere, kan jeg dele nogle indsigter om dette emne.
Den 10x programmør dengang
Software udviklet for 20-30 år siden var meget enklere sammenlignet med moderne software, med hensyn til funktionalitet, sikkerhed, ydeevne og skalerbarhed. På den anden side var der dengang kun en håndfuld biblioteker eller frameworks til rådighed til at implementere alle funktionaliteter.
Så software, der blev skrevet for 20-30 år siden, involverede en betydelig indsats i programmeringen.
Det er forholdsvis nemt at definere en 10x-programmør i den sammenhæng. Forskellen mellem mængden af kerneprogrammeringsindsats for at implementere det samme sæt funktionaliteter hos 10x-programmører og almindelige programmører.
10x-ingeniøren nu
Hvor vi går i yderligere detaljer, skal vi gøre én ting klart: softwareudvikling er en kompleks proces, og programmering er blot et af de områder, der bidrager til moderne software.
På grund af den øgede brug af software, især over internettet, af både forbrugere og organisationer, er software meget komplekst, og det kan være en vanvittig beslutning at bygge noget fra bunden. Ærligt talt, medmindre det er en helt ny platform eller et nyt styresystem, er den centrale programmering, der kræves for at udvikle moderne software, mindre intens sammenlignet med ældre bestræbelser.
Mens viden om programmering og indsats stadig er meget vigtig, er den mængde indsats, der kræves for at bygge god software (fejlfri, sikker og salgbar), inden for ingeniørvidenskab.
Så på dagens kontekst giver en 10x programmør måske ikke meget værdi i branchen, men en 10x ingeniør skaber en meget bred indvirkning i udviklingsprocessen.
Jeg vil gerne tilføje mine 3 cent her.
1. De gør den bedste brug af værktøj
Softwareudvikling er en kompleks proces, som involverer en masse forskellige former for indsats. Udover kodning involverer den indsatser fra dokumentation af processen til formatering af data, fra læsning af logdata til afsendelse af rapporter, fra automatisk testning til manuel testning, fra kompleks debugging til manuel undersøgelse af problemer osv. osv.
En enorm indsats kan gøres yderst effektiv ved at bruge det rigtige sæt værktøjer og platforme (der passer til kundens budget og andre begrænsninger).
Redigeringsprogrammer
Skrivning af software involverer en eller flere redigeringsprogrammer, hvoraf nogle også kaldes IDE (Integrated Development Environment). Moderne IDE’er, såsom Visual Studio eller Eclipse, tilbyder en stor mængde funktioner, der gør udviklere produktive, men en betydelig del af disse funktioner er ikke kendt af de fleste udviklere.
Populære IDE’er har også kommercielle og gratis plugins (såsom Resharper), som muliggør endnu mere produktivitet for udviklerne.
Som IDE’er er andre editorer såsom NotePad++, MarkdownPad osv. også meget nyttige i en relevant sammenhæng.
Hjælpeprogrammer og onlinetjenester
Hjælpeprogrammer og onlinetjenester såsom læsning eller søgning i store logfiler, http-debuggere som Fiddler, build- og deployment-værktøjer osv.
Egne værktøjer
10x-ingeniører laver også deres egne sæt værktøjer til at udføre gentagne handlinger, som den passende software måske ikke er tilgængelig eksternt.
I mange tilfælde synes virksomhedsejere i et softwareudviklingshus ikke at være interesseret i at investere meget i værktøjer til udviklere, men ved at bruge det rigtige sæt værktøjer kan man opnå en overraskende stor produktivitet.
For softwareudviklere, som er nogle af de dyreste mennesker at ansætte, er det værd at bruge penge på det rigtige værktøj til dem.
Som leder af et .net-udviklerteam udviklede jeg en ASP.NET Core & Visual Studio-startskabelon efter den nyeste .net-kodningspraksis, hvilket hjalp mit team med at øge den samlede produktivitet tre gange.
2. De opfinder ikke hjulet på ny
Softwareindustrien er blevet meget moden i de sidste tre årtier. Næsten alle problemer, som udviklere forsøger at løse ved at kode, er blevet løst og er tilgængelige som API’er (enten som binære eller webtjenester), hvoraf nogle er kommercielle, mens andre er gratis.
Open source frameworks giver desuden også stor fleksibilitet til at forstå den underliggende API-adfærd eller tilpasning efter brugernes behov.
Hvor de kaster sig ud i programmeringen, sikrer 10x-ingeniører sig faktisk, at dette problem ikke er blevet løst helt (eller delvist) før, eller hvis det er tilfældet, at de ikke er tilgængelige til brug.
3. De skriver (løbende) smukt konstrueret kode
At skrive god software kræver, at man definerer en god arkitektur, der ikke kun følger gode designmønstre og principper, men også udnytter moderne infrastrukturer. At producere velkonstrueret kode gør det ikke kun muligt at skrive nye funktionaliteter hurtigere, men reducerer også fejl betydeligt.
Men smuk konstruktion kræver løbende forbedringer.
Jeg har set overraskende meget kode af lav kvalitet i forskellige softwareprojekter i min professionelle karriere, som løbende tilføjer teknisk gæld. Et simpelt projekt, der startede for 5 år siden, er fuld af ikke-teknisk grim kode og kræver 20+ mennesker til at håndtere udviklingscyklussen (hvor de bruger 80% af deres tid på faktisk at rette fejl).
En af hovedårsagerne bag denne forfærdelige situation, har jeg fundet ud af, er “frygt”.
Organisationer, især virksomheder, frygter for det meste forandring.
Softwareudvikling er en disciplin, der ændrer sig utroligt hurtigt med hensyn til værktøj, rammer og teknik, og som kræver løbende ændringer for at komme det rigtige sted hen.
Forandring er skræmmende, men det er ikke så farligt, som det lyder, især ikke i softwareindustrien (med de rigtige sæt af værktøjer og mennesker). Men hvis det ikke bliver gjort som forventet, skal der ikke meget tid til, før projektet en dag bliver helt opgivet.