10x-programmeurs zijn tegenwoordig een veelbesproken onderwerp in de software-industrie, dus het leek me een goed idee om mijn visie hierop te geven.
Eerlijk gezegd ken ik de exacte definitie van een 10x-programmeur niet, maar ik ga ervan uit dat het gaat om hyperproductieve programmeurs (die misschien niet exact 10 keer zo productief zijn, maar wel significant in de buurt van of meer dan 10 keer).
Gebaseerd op enkele successen die ik heb behaald bij het leveren van ultra-grote stukken software voor startups en bedrijven, en werkervaring met een paar top-notch ontwikkelaars, kan ik wat inzichten delen over dit onderwerp.
De 10x Programmeur Toen
Software die 20-30 jaar geleden werd ontwikkeld, was veel eenvoudiger in vergelijking met moderne software, met betrekking tot functionaliteit, beveiliging, prestaties en schaalbaarheid. Aan de andere kant waren er in die tijd slechts een handvol bibliotheken of frameworks beschikbaar om welke functionaliteit dan ook te implementeren.
Daarom vergde software die 20-30 jaar geleden werd geschreven een aanzienlijke hoeveelheid programmeerinspanning.
Het definiëren van een 10x programmeur in die context is betrekkelijk eenvoudig. Het verschil tussen de hoeveelheid programmeerinspanning die 10x-programmeurs en gewone programmeurs leveren om dezelfde set functionaliteiten te implementeren.
The 10x Engineer Now
Voordat we verder in detail treden, willen we één ding duidelijk maken: softwareontwikkeling is een complex proces, en programmeren is slechts een van de gebieden waarop je kunt bijdragen aan moderne software.
Door het toegenomen gebruik van software, vooral via Internet, door zowel consumenten als organisaties, is software zeer complex, en het kan een krankzinnige beslissing zijn om iets van de grond af op te bouwen. Eerlijk gezegd, tenzij het een compleet nieuw platform of besturingssysteem is, is de kern van het programmeren dat nodig is om moderne software te ontwikkelen minder intensief vergeleken met oudere inspanningen.
Terwijl programmeerkennis en inspanning nog steeds erg belangrijk is, is de hoeveelheid inspanning die nodig is om geweldige software te bouwen (bug free, veilig, en verkoopbaar) in engineering.
Dus in de huidige context levert een 10x programmeur misschien niet veel waarde op in de industrie, maar een 10x ingenieur creëert een zeer grote impact in het ontwikkelproces.
Ik wil hier graag mijn 3 cent aan toevoegen.
1. Ze maken optimaal gebruik van tooling
Software-ontwikkeling is een complex proces, waarbij veel verschillende soorten inspanning komen kijken. Naast het coderen, gaat het om inspanningen van het documenteren van processen, tot het formatteren van gegevens, van het lezen van loggegevens, tot het verzenden van rapporten, van automatisch testen, tot handmatig testen, van complexe debugging, tot het handmatig onderzoeken van problemen, enzovoort, enzovoort.
Een enorme inspanning kan uiterst efficiënt worden gemaakt door gebruik te maken van de juiste set hulpmiddelen en platforms (die passen bij het budget en andere beperkingen van een klant).
Editors
Bij het schrijven van software zijn een of meer editors betrokken, waarvan sommige ook wel IDE (Integrated Development Environment) worden genoemd. Moderne IDE’s, zoals Visual Studio of Eclipse, bieden een grote hoeveelheid functionaliteit om ontwikkelaars productief te maken, maar een aanzienlijk deel van deze functies is bij de meeste ontwikkelaars niet bekend.
Populaire IDE’s hebben ook commerciële en gratis plug-ins (zoals Resharper), die nog meer ontwikkelaarsproductiviteit mogelijk maken.
Naast IDE’s zijn ook andere editors zoals NotePad++, MarkdownPad, enz. zeer nuttig in een relevante context.
Hulpprogramma’s en onlinediensten
Hulpmiddelen en onlinediensten zoals het lezen of doorzoeken van grote logbestanden, http debuggers zoals Fiddler, build- en deployment-tools, enz.
Eigen Tools
10x-engineers maken ook hun eigen sets van tools om repeterende acties uit te voeren waarvoor de juiste software niet extern beschikbaar is.
In veel gevallen lijken bedrijfseigenaren in een software-ontwikkelhuis niet geïnteresseerd in het investeren in veel tooling voor ontwikkelaars, maar het gebruik van de juiste set van tooling zal een verrassende hoeveelheid productiviteit mogelijk maken.
Voor softwareontwikkelaars, die tot de duurste mensen behoren om in te huren, is het de moeite waard om geld uit te geven aan de juiste tooling voor hen.
Als teamleider van .net-ontwikkelaars hielp het ontwikkelen van een ASP.NET Core & Visual Studio-startersjabloon volgens de nieuwste .net-coderingspraktijken mijn team om de algehele productiviteit driemaal op te voeren.
2. Ze vinden het wiel niet opnieuw uit
De software-industrie is in de afgelopen drie decennia zeer volwassen geworden. Bijna elk probleem dat ontwikkelaars proberen op te lossen door te coderen, is opgelost en beschikbaar als API’s (hetzij als binaire of web services), waarvan sommige commercieel zijn, terwijl anderen gratis zijn.
Buiten dat bieden open source frameworks ook een grote flexibiliteit om het onderliggende API-gedrag te begrijpen of aan te passen als dat nodig is voor de gebruikers.
Voordat ze in het programmeren springen, zorgen 10x engineers er eigenlijk voor dat dit probleem niet eerder volledig (of gedeeltelijk) is opgelost of, als dat zo is, ze niet beschikbaar zijn om te worden gebruikt.
3. Ze schrijven (voortdurend) mooi ontworpen code
Het schrijven van geweldige software vereist het definiëren van een goede architectuur die niet alleen goede ontwerppatronen en principes volgt, maar ook gebruikmaakt van moderne infrastructuren. Het produceren van goed ontworpen code maakt het niet alleen mogelijk om sneller nieuwe functionaliteiten te schrijven, maar vermindert ook bugs aanzienlijk.
Maar, mooie engineering vereist voortdurende verbetering.
Ik heb een verrassende hoeveelheid code van lage kwaliteit gezien in verschillende softwareprojecten in mijn professionele carrière, die voortdurend technische schuld toevoegt. Een eenvoudig project dat 5 jaar geleden begon, zit vol met niet-engineered lelijke code en vereist 20+ mensen om de ontwikkelingscyclus af te handelen (waarbij ze 80% van hun tijd daadwerkelijk besteden aan het repareren van bugs).
Een van de belangrijkste redenen achter deze vreselijke situatie, vond ik, is “angst”.
Organisaties, vooral enterprise-entiteiten, zijn meestal bang voor verandering.
Software-ontwikkeling is een ongelooflijk snel veranderende discipline in termen van tooling, frameworks en engineering, en vereist voortdurende verandering om op de juiste plaats te komen.
Verandering is beangstigend, maar het is niet zo gevaarlijk als het klinkt, vooral in de software-industrie (met de juiste sets van tooling en mensen). Maar als het niet wordt gedaan zoals verwacht, zal het niet veel tijd kosten voordat het project op een dag helemaal wordt verlaten.