Bijna elke softwareontwikkelaar of programmeur is wel eens code tegengekomen die door iemand anders is geschreven en die het cliché “iedereen kan coderen” bewijst. Maar bent u ooit de zogenaamde mythische “10x ontwikkelaar” tegengekomen? Een 10x ontwikkelaar zijn heeft minder te maken met uitblinken in het schrijven van code, maar meer met precies weten welke code je moet schrijven.
Velen van ons begonnen met programmeren voor een specifiek doel. Ik begon bijvoorbeeld code te schrijven om tekstgebaseerde MUD-spelletjes automatisch te laten afspelen terwijl ik sliep en op school zat. Ik was een scriptkiddie toen ik 13 was en ik wist het niet eens. Ik kon met een idee komen, de code schrijven, en het testen – helemaal zelf.
Software-ontwikkeling is moeilijk wanneer we het voor iemand anders doen, omdat we vaak niet dezelfde soort motivatie en opwinding hebben die ons drijft wanneer we onze eigen visie nastreven. We komen niet met de ideeën, we spenderen uren in vergaderingen om ze te begrijpen, en dan spenderen we het grootste deel van de tijd aan het aanpassen van de code van iemand anders – of op zijn minst eraan bij te dragen. Dat kan leiden tot een niveau van onthechting dat de productiviteit vermindert.
Om een 10x ontwikkelaar te zijn, moet je leren uit te blinken in deze omgeving of zelfs je eigen bedrijf beginnen om de leiding te nemen.
Iedereen kan een 10x ontwikkelaar zijn, ten minste een deel van de dag, elke dag. Ik geloof dat er drie dingen zijn waar alle ontwikkelaars zich op moeten richten om productiever te worden en een beter teamlid.
- De 3 dingen
- Kennis van het Wat
- Het waarom begrijpen
- Weten wanneer je wat moet doen
- Beheersing van het Wat, Waarom & Wanneer u een 10x ontwikkelaar wordt
- Begin met Waarom
- Ben een goede ontwikkelaar &Uitstekende probleemoplosser, niet de beste programmeur
- Het wanneer zit in je buik, of niet
- Weten wat je moet doen en wat je moet vragen
- Conclusie
De 3 dingen
Om een 10x ontwikkelaar te zijn, moet je een aantal jaren ervaring hebben met het werken met welke programmeertaal en toolset je ook gebruikt. Je moet goed zijn in het oplossen van problemen en het schrijven van code; dit is een gegeven.
Het is belangrijk om te begrijpen dat hoe je code schrijft niet is wat je een 10x ontwikkelaar, 10x ingenieur, 10x programmeur, of hoe je het ook wilt noemen, maakt.
Je kent de 5 W’s: “Wie, wat, waar, waarom, wanneer.” Hoewel deze allemaal van toepassing zijn op softwareontwikkeling, wil ik me richten op de drie kenmerken die 10x ontwikkelaars definiëren.Deze drie dingen onderscheiden de gemiddelde ontwikkelaar van de 10x ontwikkelaar:
- Wat
- Waarom
- Wanneer
Kennis van het Wat
In de bedrijfswereld hebben ontwikkelaars de neiging om aan projecten te werken waar ze niet veel passie voor hebben en die ze niet begrijpen. Voor de meeste ontwikkelaars is dit geen groot probleem, zolang ze maar zeer goede aanwijzingen krijgen en de verwachtingen duidelijk zijn omschreven.
Het probleem is dat ontwikkelaars meestal geen adequate instructies krijgen. In plaats daarvan gebruiken we iets dat “agile development” heet. We krijgen een Post-it briefje met een paar woorden erop en er wordt van ons verwacht dat we precies weten wat er gedaan moet worden.
Softwareontwikkeling draait allemaal om communicatie. Ontwikkelaars moeten weten waar we aan werken, welke problemen we proberen op te lossen, en precies hoe het resultaat eruit moet zien. Hoe meer we van tevoren weten, hoe sneller we kunnen gaan. Het belangrijkste is dat we weten wat de bedoeling van het werk is en wat het werk tot een succes zal maken.
Slechte ontwikkelaars zullen urenlang de verkeerde kant op gaan met een project zonder vragen te stellen. Ze zijn wat ik noem -10x ontwikkelaars, omdat ze niets bereikt krijgen en de tijd van al hun collega’s verspillen. Bijna iedereen heeft wel eens met zo’n ontwikkelaar te maken gehad, en het kan frustrerend zijn om met hen samen te werken. En je moet oppassen dat je hun gewoonten niet overneemt!
Sommige ontwikkelaars werken zelfs goed zonder veel details. Ze gebruiken een grote hoeveelheid creativiteit en stellen de juiste vragen. Deze eenhoorns zijn waarschijnlijk 10x ontwikkelaars. Zij weten hoe ze dingen moeten uitzoeken en tillen vaak het niveau op van het hele team dat om hen heen werkt.
Het komt erop neer dat 10x ontwikkelaars echt goed zijn in het snel bepalen wat er moet worden bereikt en welke vragen ze moeten stellen.
Het waarom begrijpen
Het grootste obstakel van softwareontwikkeling is misschien wel het waarom begrijpen. Als je het probleem dat je probeert op te lossen niet begrijpt, is het heel moeilijk om het op te lossen.
Waarom hackte ik terminalscripts in elkaar om mijn MUD-spel te spelen terwijl ik sliep en op school zat? Ik wilde het hoogste level in het spel bereiken, natuurlijk. Ik wist precies waarom, en ik deed alles wat ik kon om het te laten gebeuren.
Dezelfde aanpak geldt voor elk software ontwikkelingsproject. Ontwikkelaars die begrijpen in welke bedrijfstak ze zitten en welke problemen ze proberen op te lossen, zullen veel productiever zijn. Weten waarom en de vertical begrijpen helpt ook onnodig werk te voorkomen, waardoor tijd vrijkomt om je te richten op de dingen die een product of functie waardevoller maken voor gebruikers.
Het probleem is dat weten waarom niet goed genoeg is. Je moet een passie hebben voor het probleem en het van binnen en buiten begrijpen om echt een 10x-ontwikkelaar te zijn. Ik denk dat de meeste 10x ontwikkelaars ook productmensen in hart en nieren zijn, begiftigd met een goede productvisie.
Weten wanneer je wat moet doen
Timing is belangrijk voor softwareontwikkelingsprojecten. Picking welke volgorde om te werken aan items in uw back log is een schijnbaar eenvoudige taak die is echt van cruciaal belang. Werk je aan iets dat je bedrijf kan helpen een nieuwe account binnen te halen of ga je oude technische schuld opruimen?
Als ontwikkelteams moeten we voortdurend jongleren met waar we aan werken en wanneer we eraan werken.
Al het werk van software-ontwikkeling valt in deze drie categorieën:
- Dingen die we moeten doen
- Dingen die we moeten doen
- Dingen die we willen doen
We moeten deze nieuwe functie voor een klant afkrijgen. We moeten bugs in onze software oplossen. We willen werken aan een technische schuld of een coole nieuwe productfunctie. Het is altijd een evenwichtsoefening.
We zouden werkitems uit alle drie deze emmers tegelijkertijd moeten doen. We kunnen niet al onze tijd besteden aan technische schuld, maar misschien moeten we er een klein percentage van onze tijd aan besteden.
Ontwikkelaars moeten ook weten wanneer ze complexe architecturen in hun code moeten bouwen. Ik geef er de voorkeur aan om de code zo eenvoudig mogelijk te houden, totdat ik gedwongen wordt om architectuur toe te voegen waar ik anders niet zonder kan.
Ontwikkelaars moeten ook weten wanneer ze moeten vermijden om glimmende objecten na te jagen. Ze hebben de neiging om te willen spelen met nieuwe tools en technologieën, maar deze oplossingen kunnen een project alleen maar vertragen in plaats van helpen om het sneller gedaan te krijgen.
10x ontwikkelaars zijn goed in het jongleren met prioriteiten en begrijpen wanneer ze tijd moeten investeren in architecturen versus het slingeren van spaghetti code om iets te laten werken. Vergeet niet dat het uw gebruikers niet kan schelen hoe uw software werkt of hoe mooi de architectuur is. Ze willen gewoon dat het werkt. 10x ontwikkelaars begrijpen dit.
Beheersing van het Wat, Waarom & Wanneer u een 10x ontwikkelaar wordt
Nu gaan we het hebben over hoe u de belangrijke vaardigheden Wat, Waarom en Wanneer kunt beheersen om een 10x ontwikkelaar te worden.
Begin met Waarom
De eerste stap om een 10x ontwikkelaar te worden, is gepassioneerd raken over de software en de problemen die u probeert op te lossen. Je moet het probleem van binnen en van buiten begrijpen. Dat begint met enthousiast te zijn over het bedrijf waarvoor je werkt en hun missie als bedrijf.
Maak niet alleen een knop om iets te doen omdat dat is wat iemand zei om te doen. Streef ernaar om op een hoger niveau te begrijpen waarom. Je zult veel waardevoller zijn voor je team en bedrijf als je gefocust blijft op het waarom.
Ben een goede ontwikkelaar &Uitstekende probleemoplosser, niet de beste programmeur
Ik zou mezelf omschrijven als meer een hacker-ontwikkelaar. Ik ben het type dat lelijke code in elkaar kan flansen om bijna elk probleem snel op te lossen. Mijn code is zelden mooi, maar hij werkt. En daar gaat het om.
Je hoeft geen perfect ontworpen code met unit tests te schrijven om een 10x ontwikkelaar te zijn. Je moet weten wanneer je die dingen wel en wanneer je ze niet moet doen om een 10x ontwikkelaar te zijn.
Een 10x ontwikkelaar is goed in het oplossen van specifieke problemen en het bevredigen van de businessbehoeften met code. Het slimste wat je kunt doen, is weten hoe ver je met een project moet gaan voordat je het overdraagt aan iemand anders die misschien beter is in het afronden van sommige van de architectuur en andere kleine details.
Het wanneer zit in je buik, of niet
Weten wanneer je een complexe architectuur moet uitbouwen in plaats van iets in elkaar te hacken, komt met ervaring en de ontwikkeling van je spionnenzintuigen. Je hebt dat onderbuikgevoel of je hebt het niet.
Sommige van de slimste ontwikkelaars met wie ik ooit heb gewerkt, waren het slechtst in het prioriteren van patronen en architecturen boven functionaliteit en schema’s. Ze wilden over-engineeren en dingen steeds weer herschrijven, strevend naar “perfecte code” in plaats van “shippable code.”
10x-ontwikkelaars moeten hun ervaring en buikgevoel gebruiken om te weten wanneer ze zich moeten richten op architectuur en perfectie in plaats van shit gedaan te krijgen.
Weten wat je moet doen en wat je moet vragen
Zoveel van software-ontwikkeling komt neer op communicatieve vaardigheden. Helaas zijn veel van de notities en eisen die we krijgen voor werk items niet erg gedetailleerd. Een 10x ontwikkelaar weet hoe hij deze moet lezen, het “waarom” dat hij van de business weet toe te passen en relevante vragen te stellen.
De beste ontwikkelaars weten hoeveel tijd ze ergens aan moeten besteden voordat ze om hulp vragen. Ze weten ook welke vragen ze moeten stellen om te verduidelijken wat er moet worden gedaan om het project vooruit te helpen.
Conclusie
Ik schrijf al meer dan 15 jaar code. Ik zou zeggen dat ik een 10x ontwikkelaar ben, of in ieder geval kan zijn. Ik weet waar ik goed in ben. Als ik de dingen doe waar ik goed in ben, kan ik snel een serieuze hoeveelheid werk gedaan krijgen.
Als je een prototype van een nieuw product wilt maken, ben ik je man. Als je hulp nodig hebt met Angular, React of een andere front-end ontwikkeling, ben ik zeer zeker niet je man. Ik zou een -10x ontwikkelaar zijn bij die taken.
10x ontwikkelaars zijn geen mythe. Ze bestaan echt. Ze zijn waarschijnlijk dev managers, architecten, hoofdontwikkelaars of oprichters van het bedrijf. Als ze dat niet zijn, zouden ze dat waarschijnlijk wel moeten zijn. Ik ben uiteindelijk twee keer oprichter van een bedrijf geworden.
Ook zal niemand elke dag een 10x ontwikkelaar zijn, de hele dag door. We hebben niet de energie of de focus om elke dag in dat tempo te werken. We zijn geen robots.
Als je het “wat, waarom en wanneer” van softwareontwikkeling begrijpt, kun je productiever zijn en een beter teamlid – misschien zelfs een paar uur per dag een 10x ontwikkelaar. En dat kan een groot verschil maken.
Terwijl je hier toch bent en onderzoekt hoe je kunt verbeteren, bekijk dan onze dynamische code analyse tool, Stackify Prefix. Het is gratis en zal je helpen betere code te schrijven.