De laatste tijd werd er op twitter veel gesproken over de 10x ingenieur en ontstond er een grote discussie over wat een goede ingenieur maakt. Er werden een aantal echt domme dingen genoemd zoals “10x ingenieurs haten vergaderingen” en “10x ingenieurs komen te laat op kantoor” en “10x ingenieurs laptop achtergrond is meestal zwart”. In het algemeen lijkt het erop dat sommige mensen denken dat als je slim genoeg bent, het oké is om een klootzak te zijn.
Bij Wix proberen we de klootzakken buiten de deur te laten. Wij geloven dat 10x ingenieurs niet alleen mensen zijn die 10x sneller kunnen produceren dan de meeste mensen, sterker nog, dat zijn mensen die een heel team 10x beter kunnen maken door een positieve invloed te hebben op iedereen met wie ze werken.
Veel mensen besteden een groot deel van hun carrière aan het worden van wat wij zien als een fatsoenlijke ingenieur. Het betekent dat je een goede coder bent, die problemen kan oplossen en vloeiend in het gebruik van de tools die tot je beschikking staan zoals IDE, debugger, services en frameworks. In dit artikel beschrijven we wat volgens Wix Engineering van een goede ingenieur een 10x ingenieur maakt.
Een van de belangrijkste eigenschappen van een ingenieur is dat hij of zij zelfstandig kan werken. In een notendop betekent dit dat je altijd weet wat je moet doen en zelden in een situatie verkeert waarin je wacht op iemand die je vertelt wat je moet doen. Het betekent niet dat je in staat bent om alles in je eentje te doen, het betekent alleen dat je weet hoe je jezelf en anderen in je team kunt deblokkeren op een nette manier die minimale technische schuld creëert. Als je bijvoorbeeld geblokkeerd wordt door een probleem, zal je daar een oplossing voor vinden, of dat nu is door hulp te vragen aan je collega’s of door het zelf op te lossen. Onafhankelijke ingenieurs hebben het vermogen om een project van idee tot productie te brengen door alle fasen heen. Ze zijn in staat om te bepalen wat ze nodig hebben om een taak te kunnen volbrengen en ze weten wanneer ze een vlag moeten uitsteken als ze hulp nodig hebben.
Planning
Het moeilijkste waar je minder ervaren ingenieurs mee ziet worstelen is om een grote taak te kunnen opdelen in kleinere stappen. Dit is niet alleen belangrijk om in te kunnen schatten hoe lang iets duurt, het is ook een essentieel onderdeel van het bouwen van software van hoge kwaliteit. Correct plannen betekent dat de ontwikkelaar de eerste versie van het product zo vroeg mogelijk kan uitbrengen en sneller feedback kan krijgen. Correct plannen betekent dat je al vroeg een ontwerp van het systeem hebt en dat je een goed beeld hebt van wat je gaat doen voordat je in het water springt. Correct plannen betekent dat er geen grote verrassingen zijn die je ontwerp breken terwijl je aan het ontwikkelen bent. Een goede ingenieur zou in staat moeten zijn om een taak op te splitsen, het ontwerp en de fasen van de release te definiëren, en ontwerpdocumenten en schattingen te leveren om zijn plan te laten zien.
Humility
Dit is een moeilijke. Zelfs de sterkste ingenieurs hebben vaak plaats om te groeien als het gaat om nederigheid. Het betekent niet verliefd te zijn op je eigen oplossingen. In staat zijn om te luisteren en andermans oplossingen te accepteren. Het beste van je collega’s aannemen en als je iets ziet dat een fout lijkt, proberen de redenering erachter te begrijpen. Dingen bespreekbaar maken. Laat mensen hun eigen oplossingen voorstellen. Deel je ideeën en maak je nooit zorgen over het krijgen van krediet voor hen. Het is belangrijker dat iedereen zich goed voelt bij een idee en het gevoel heeft dat het een teamprestatie was, dan dat iedereen weet dat het jouw idee was. Wees eerlijk. Geef mensen krediet. Wees nooit bang om te zeggen dat je fout zat of om te erkennen dat iemand anders gelijk heeft. Mensen respecteren mensen die hun mening kunnen veranderen.
Hergebruik
Het klinkt misschien triviaal, maar de meeste mensen begrijpen niet dat de beste manier om vooruitgang te boeken is om voort te bouwen op eerder werk. Minder ervaren ingenieurs hebben altijd de slechte gewoonte om te denken dat de beste manier om snel vooruit te komen is om alles wat al bestaat te negeren en opnieuw te beginnen. Goede ingenieurs zullen altijd alle bestaande oplossingen die al beschikbaar zijn grondig opzoeken, leren, vragen stellen en begrijpen. Zelfs als een bestaande oplossing tekortschiet, zullen zij proberen te zien hoe deze kan worden verbeterd voordat zij besluiten deze te vervangen. Ze zullen nooit een bestaande oplossing verwerpen zonder zich erin te verdiepen en zonder te spreken met de eigenaar van de bestaande oplossing.
Infrastructuur mindset
Zoals hierboven beschreven, kan het hergebruik van eerder werk een enorme impact hebben op mensen. Dit betekent dat ingenieurs altijd op de uitkijk moeten staan om te zien of ze een kans hebben om iets herbruikbaars te maken. Het gemakkelijkste om te doen wanneer je zo’n kans hebt is ze te negeren. Herbruikbare dingen maken kost de “maker” altijd meer dan het niet herbruikbaar maken, dus veel kortzichtige mensen negeren de voordelen die zij en andere teams er later van zullen plukken. Een goede ontwikkelaar identificeert de mogelijkheden om herbruikbare dingen te maken, weet hoe hij ze op de beste manier herbruikbaar kan maken, en investeert de moeite om dat te doen.
Maak je domein meester
De enige manier om met goede oplossingen te komen is door het product waar je aan werkt grondig te begrijpen. Goede ingenieurs hebben niet alleen een diep begrip van het product dat ze ontwikkelen. Ze begrijpen ook alle use cases, begrijpen de motivatie voor het product en kunnen gemakkelijk zinvolle gesprekken voeren met de product manager, beslissingen aanvechten en alternatieven bieden. Ze weten wat de belangrijke features zijn en wat de minder belangrijke dingen zijn en weten op basis daarvan prioriteiten te stellen en workarounds aan te bieden als dat nodig is. Dit is niet alleen belangrijk voor het product waar je aan werkt, maar ook voor elk product waarmee je integreert.
Curiosity
Goede ontwikkelaars moeten een gezonde nieuwsgierigheid hebben die veel verder reikt dan de grenzen van hun domein. Dit geldt vooral voor het leren hoe de onderliggende technologieën eigenlijk werken, maar het is net zo belangrijk om de producten te begrijpen waar andere teams aan werken, hun architectuur en hoe ze aansluiten als een compleet systeem. Het hebben van deze bredere context kan van onschatbare waarde zijn bij het oplossen van complexe problemen en een bron van inspiratie.
Geen grenzen
We zien vaak dat de bron van slechte oplossingen en slechte architectuur is geworteld in mensen die bang zijn om dingen te veranderen die buiten de grenzen van hun box vallen. Client ontwikkelaars zullen geneigd zijn om dingen op de client op te lossen, zelfs als het beter is om het op de server op te lossen. Applicatie ontwikkelaars zullen geneigd zijn om het probleem lokaal op te lossen, zelfs als de oplossing thuishoort in het platform of in de infrastructuur. De reden hiervoor is eenvoudig. Het is gemakkelijker om geen discussie te creëren met een ander team, het is gemakkelijker om de wereld buiten je bereik te behandelen als een zwarte doos, het is gemakkelijker om om te gaan met de duivel die je kent. Maar goede ingenieurs moeten weten dat ze deel uitmaken van één groot systeem en dat geen enkel deel van het systeem echt buiten hun bereik ligt. Het bespreken van architectuur verandering met een ander team is gezond en behulpzaam en kan je perspectief vergroten. Aanbieden om bij te dragen aan de verandering die je nodig hebt is geweldig voor het opbouwen van vertrouwen tussen teams. Het aanraken van een nieuw domein is een ervaring waar je alleen maar voordeel uit kunt halen. Het belangrijkste is dat wanneer uw grenzen flexibeler worden, dit betekent dat uw impact groeit. Als je niet buiten je grenzen wilt reiken, realiseer je je dan dat je jezelf eigenlijk tegenhoudt om een grotere impact te hebben.
Responsibility / ownership
Hoewel het niet direct duidelijk is, zul je heel vaak als je graaft naar de hoofdoorzaak van waarom een bepaald project is vertraagd of mislukt, merken dat het neerkomt op ownership en verantwoordelijkheid. Mensen zullen altijd geneigd zijn hun omgeving de schuld te geven: “Ik moest wachten op een ander team om iets af te ronden”, “Ik had een systeemprobleem en niemand had tijd om me te helpen”, “Ik kreeg de definities te laat”. Een goede ingenieur weet dat dit bijna altijd smoesjes zijn. Wanneer je de eigenaar bent van de taak en de verantwoordelijkheid om het te laten gebeuren bij jou ligt, zou je mindset moeten zijn dat elk probleem dat je tegenkomt iets is dat je moet oplossen. Als je geblokkeerd wordt door een ander team, ga dan met hen praten. Bied aan om het probleem samen aan te pakken en “gooi” de verantwoordelijkheid niet op iemand anders. Als je nog geen definities hebt gekregen, maak dan enkele veronderstellingen over wat de definities zullen zijn. Het is beter om enige vooruitgang te boeken en later aanpassingen te maken, dan te blijven zitten en wachten. Als iets groots je vertraagt, weet dan wanneer je de vlag moet hijsen en weet hoe je het probleem kunt omzeilen zodat je tenminste op een ander front vooruitgang kunt boeken. Nooit in een situatie waar iemand anders verantwoordelijk is om uw probleem op te lossen, het is andersom – u bent verantwoordelijk voor het krijgen van naar de finish en je moet omgaan met obstakels op de weg.
Communicatie
Dit is een echte game changer en vaak de meest kritische ding om te hebben voor een ingenieur in staat zijn om een enorme impact op het hele team te hebben. Kunnen communiceren is het belangrijkste dat de mensheid in staat heeft gesteld om te worden wat ze is, uiteraard is dit net zo belangrijk voor elk aspect van het leven, inclusief software engineering. Goede ingenieurs moeten in staat zijn om hun ideeën en meningen welsprekend uit te leggen. Zij moeten op intelligente en respectvolle wijze kunnen debatteren met hun collega’s. Communicatie gaat niet alleen over spreken, het is nog belangrijker om te kunnen luisteren. Niet iedereen in het team zal zijn ideeën even goed kunnen verwoorden en een goede ingenieur moet geduldig zijn en de juiste vragen stellen om te begrijpen wat anderen denken en hen te helpen gehoord te worden. Dit alles is even belangrijk voor zowel mondelinge als schriftelijke communicatie, en nog belangrijker het is niet alleen converseren – het leven van ontwikkelaars zit vol met tonnen vormen van communicatie: documenten, presentaties, documentatie, code commentaar, commit berichten. Zelfs het schrijven van leesbare code en het kiezen van goede variabele namen is een vorm van communicatie.
Teamwork
Dit is een van de plaatsen waar zelfs ervaren ingenieurs heel vaak falen en niet eens weten dat het gebeurt. Denk aan al die keren dat je zei “het is te ingewikkeld, laat het maar aan mij over”. Denk aan de keren dat je zei “deze taak is een eenmansklus, meer mensen toevoegen zal het niet makkelijker maken”. Denk aan al die keren dat je geen tijd had om iemand anders te helpen en er nooit gevolg aan hebt gegeven, of dat je iemands code hebt gerepareerd/gerefactored zonder hem om een review te vragen, of dat je een grote verandering hebt doorgevoerd zonder te overleggen met je team. Er zijn tal van voorbeelden. En het ding is dat zelfs voor ervaren ingenieurs het lijkt op het moment als het juiste ding om te doen. Maar dit is tactisch denken dat alleen op korte termijn vruchten afwerpt. Als we grote dingen willen bereiken, moeten we ervoor zorgen dat we als team kunnen samenwerken. Het is geen toeval dat teamwork direct na communicatie kwam. Dat zijn de dingen die ons het meest effectief maken, het is basisbiologie. Geweldige ingenieurs werken niet alleen samen, overleggen met, leren van, helpen, koppelen en respecteren hun collega’s, ze zijn ook mentor, wijzen op problemen, vinden interesse en leren van alles wat er in het team gebeurt en proberen proactief behulpzaam te zijn, zelfs voor dingen die hen niet direct aangaan. Geweldige ingenieurs weten wanneer en hoe ze met ontwerpen moeten komen die het voor veel mensen gemakkelijker maken om samen te werken aan dingen waar veel werk wordt verwacht.
Keep it simple
De complexiteit van een oplossing kan een van de stille moordenaars zijn van het vermogen van het team om vooruit te komen en zich aan te passen. Het is als een hoge bloeddruk. Voor het ongetrainde oog lijkt het alsof alles in orde is en alles werkt zoals verwacht, maar eigenlijk, diep van binnen, is iets dat niet direct van invloed is op een hoofdfunctionaliteit je langzaam aan het doden. Goede ingenieurs maken pragmatische oplossingen en leesbare code, zelfs als je meer regels code schrijft. Laat niet zien hoe “slim” je bent door alle mogelijkheden van de taal te gebruiken, overbodige abstractieniveaus te creëren, of een functie in één regel te schrijven die niemand anders kan begrijpen of debuggen. Wees geen purist, over-engineer geen oplossingen waar dat niet absoluut noodzakelijk is en wees nooit bang om iets te nemen dat al complex is en probeer het te vereenvoudigen.
Prioriteren
We kunnen niet alles doen. We kunnen niet alle problemen oplossen. We kunnen niet alle debatten winnen. We kunnen niet alles perfect maken. We hebben beperkte tijd en beperkte middelen en we moeten ze verstandig gebruiken. Dat betekent dat we onderscheid moeten kunnen maken tussen wat we per se moeten doen, wat we kunnen uitstellen, en wat we beter kunnen negeren. Ontwikkelaars nemen deze beslissingen tientallen keren per dag. Wanneer we overwegen om een bug te onderzoeken, wanneer we overwegen om een refactor te doen, wanneer we overwegen om een use case of edge case te behandelen, wanneer we overwegen om een omweg te nemen van onze geplande taak en zelfs wanneer we tijd investeren in het overtuigen van iemand in onze mening. Goede ingenieurs weten dat ze meedogenloos moeten zijn in het herstellen, onderzoeken, onderzoeken of aandringen om hun punt te maken voor de dingen die echt belangrijk zijn. Ze weten dat ze een notitie moeten maken en later op iets moeten terugkomen als het belangrijk maar niet dringend is. En ze weten iets te laten rusten of de mening van een ander te accepteren, zelfs als ze er niet gelukkig mee zijn, als het niet echt zo belangrijk is.
Time management
Zoals gezegd, is de trieste waarheid van ons bestaan dat we aan tijd gebonden zijn. De producten die we ontwikkelen moeten uiteindelijk live gaan, we hebben deadlines en schattingen en targets te halen. Goede ontwikkelaars moeten niet alleen een intuïtie ontwikkelen om in te schatten hoe lang hun taken duren, maar ze moeten ook slim zijn in het opsplitsen en ordenen van hun taken in nog kleinere delen. Zij moeten hun interrupts en context switching verstandig beheren. Deze intuïtie van tijdsinschatting is een onlosmakelijk onderdeel van het kunnen stellen van prioriteiten zoals hierboven beschreven. Bijvoorbeeld, als iets kort genoeg is, is het misschien de moeite waard om te doen, ook al is het niet superbelangrijk. En als het te lang is, is het misschien beter om wat uit te stellen of te overleggen met je peers of manager.
Conclusie
Zoals eerder gezegd, geloven wij dat ingenieurs die expert zijn in al het bovenstaande, het team 10x beter kunnen maken door hun peers te beïnvloeden en te inspireren. Goede ingenieurs moeten altijd onthouden dat dit deel uitmaakt van hun dagdagelijkse job: beïnvloeden en inspireren. Het betekent dat je de tijd moet vinden om niet alleen je werk te doen, maar ook om anderen te helpen hun werk te doen. Dit komt in vele vormen: mentor zijn van mensen in je team, middelen creëren om mensen op te leiden, ervoor zorgen dat alles goed gedocumenteerd is, altijd open staan om mensen uitleg te geven en met hen te pairen en nog veel meer. Een goede mentor en opvoeder zijn betekent dat je niet alleen je teamleden helpt groeien, het verdiept ook je inzicht in alles wat je doet en het geeft je een nieuw perspectief over de helderheid van dingen, de complexiteit van het systeem en de plekken waar dingen kunnen verbeteren.
Dit zijn de makings of the 10x engineers, niet alleen in hun individuele impact, maar ook in hun impact op alle anderen. Vraag jezelf altijd af wat je kunt doen om je impact groter te maken, er is altijd meer ruimte om te groeien.