Der blev for nylig talt meget på twitter om den 10x ingeniør, hvilket gav anledning til en stor debat om, hvad der kendetegner en god ingeniør. Der blev nævnt nogle virkelig dumme ting som f.eks. “10x-ingeniører hader møder” og “10x-ingeniører kommer for sent på kontoret” og “10x-ingeniørers bærbare baggrund er normalt sort”. Generelt ser det ud til, at nogle mennesker mener, at hvis man er klog nok, er det i orden at være et røvhul.
I Wix forsøger vi at lade røvhullerne stå uden for døren. Vi mener, at 10x-ingeniører ikke bare er folk, der kan producere 10x hurtigere end de fleste mennesker, endnu mere, det er folk, der kan gøre et helt team 10x bedre ved at have en positiv indflydelse på alle, de arbejder sammen med.
Mange mennesker bruger en stor del af deres karriere på at blive det, som vi opfatter som en anstændig ingeniør. Det betyder, at du er en god koder, der kan løse problemer og flydende i, hvordan du bruger de værktøjer, der er til din rådighed såsom IDE, debugger, tjenester og frameworks. Denne artikel forsøger at beskrive, hvad vi i Wix Engineering mener, der gør en anstændig ingeniør til en 10x ingeniør.
En af de vigtigste egenskaber hos en ingeniør er at kunne arbejde selvstændigt. Kort sagt betyder det, at man altid ved, hvad man skal gøre, og sjældent befinder sig i en situation, hvor man venter på, at nogen skal fortælle en, hvad man skal gøre. Det betyder ikke, at du er i stand til at gøre alting selv, det betyder bare, at du ved, hvordan du kan frigøre dig selv og andre på dit team på en ren måde, der skaber minimal teknisk gæld. Hvis du f.eks. bliver blokeret af et problem, finder du en løsning på det, hvad enten det er ved at få hjælp fra dine kolleger eller ved at løse det på egen hånd. Selvstændige ingeniører har evnen til at tage et projekt fra idé til produktion gennem alle dets faser. De er i stand til at definere, hvilke ting de har brug for for at kunne udføre en opgave, og de ved, hvornår de skal hejse flaget, hvis de har brug for hjælp.
Planlægning
Den sværeste ting, man ser mindre erfarne ingeniører kæmpe med, er at kunne tage en stor opgave og bryde den ned til mindre trin. Dette er vigtigt, ikke kun for at vi kan vurdere, hvor lang tid noget tager, men det er også en afgørende del af at bygge software af høj kvalitet. Hvis man planlægger korrekt, betyder det, at udvikleren kan frigive den første version af produktet så tidligt som muligt og begynde at få feedback tidligere. At planlægge korrekt betyder, at man har et design af systemet tidligt, og at man har et godt billede af, hvad man vil gøre, før man kaster sig ud i vandet. At planlægge korrekt betyder, at der ikke kommer store overraskelser, der ødelægger dit design, mens du udvikler. En god ingeniør bør være i stand til at opdele en opgave, definere designet og faserne for frigivelse og fremlægge designdokumenter og estimater for at vise sin plan.
Humlighed
Dette er en svær opgave. Selv de stærkeste ingeniører har mange gange plads til at vokse, når det kommer til ydmyghed. Det betyder, at man ikke skal være forelsket i sine egne løsninger. At være i stand til at lytte til og acceptere andre menneskers løsninger. At antage det bedste fra sine kolleger og, når man ser noget, der ligner en fejl, forsøge at forstå ræsonnementet bag det. At åbne ting for diskussion. Lad folk komme med forslag til deres egne løsninger. Del dine idéer, og bekymr dig aldrig om at få æren for dem. Det er vigtigere, at alle vil føle sig trygge ved en idé og føle, at det var en holdindsats, end at alle ved, at det var din idé. Vær ærlig. Giv folk kredit. Vær aldrig bange for at sige, at du tog fejl, eller for at anerkende, at en anden har ret. Folk respekterer folk, der kan ændre deres mening.
Genbrug
Det lyder måske banalt, men de fleste mennesker forstår ikke, at den bedste måde at gøre fremskridt på er at bygge videre på tidligere arbejde. Mindre erfarne ingeniører har altid den dårlige vane at tro, at den bedste måde for dem at komme hurtigt fremad på er at ignorere alt, hvad der allerede findes, og starte forfra. Gode ingeniører vil altid grundigt undersøge, lære, spørge ind til og forstå alle de eksisterende løsninger, der allerede findes. Selv hvis en eksisterende løsning er mangelfuld, vil de forsøge at se, hvordan den kan forbedres, før de beslutter sig for at erstatte den. De vil aldrig afvise en eksisterende løsning uden at undersøge den grundigt og uden at tale med ejeren af den eksisterende løsning.
Infrastrukturtankegang
Som beskrevet ovenfor kan genbrug af tidligere arbejde have en stor betydning for mennesker. Det betyder, at ingeniører altid bør være på udkig efter, om de har en mulighed for at skabe noget, der kan genbruges. Det letteste at gøre, når man har en sådan mulighed, er at ignorere den. At lave genanvendelige ting koster altid “producenten” mere end at lave noget, der ikke kan genanvendes, så mange kortsynede mennesker ignorerer de fordele, som de og andre teams vil høste senere hen. En god udvikler vil identificere mulighederne for at skabe genanvendelige ting, vide hvordan man gør dem genanvendelige på den bedste måde og investere indsatsen i at gøre det.
Mestrer dit domæne
Den eneste måde at komme med gode løsninger på er ved at forstå det produkt, du arbejder på, grundigt. Gode ingeniører har ikke kun en dyb forståelse af det produkt, de udvikler. De forstår også alle use cases, forstår motivationen for produktet og kan nemt føre en meningsfuld samtale med produktchefen, udfordre beslutninger og tilbyde alternativer. De ved, hvad der er de vigtige funktioner, og hvad der er de mindre vigtige ting, og de ved, hvordan de skal prioritere i henhold til det og tilbyde workarounds, når det er nødvendigt. Dette er vigtigt ikke kun for det produkt, du arbejder på, men også for ethvert produkt, du integrerer med.
Nysgerrighed
Gode udviklere skal have en sund nysgerrighed, der rækker langt ud over grænserne for deres domæne. Dette gælder især for at lære, hvordan de underliggende teknologier rent faktisk fungerer, men det er lige så vigtigt at forstå de produkter, som andre teams arbejder på, deres arkitektur, og hvordan de hænger sammen som et komplet system. At have denne bredere kontekst kan være uvurderlig, når man løser komplekse problemer, og en kilde til inspiration.
Ingen grænser
Vi ser ofte, at kilden til dårlige løsninger og dårlig arkitektur har rod i, at folk er bange for at ændre ting, der ligger uden for deres kasse. Klientudvikler vil have en tendens til at løse ting på klienten, selv om det er bedre at løse det på serveren. Applikationsudvikleren vil have en tendens til at løse problemet lokalt, selv om løsningen hører hjemme på platformen eller i infrastrukturen. Grunden til dette er enkel. Det er nemmere ikke at skabe diskussion med et andet team, det er nemmere at behandle verden uden for ens rækkevidde som en sort boks, det er nemmere at beskæftige sig med den djævel, man kender. Men gode ingeniører skal vide, at de er en del af et stort system, og at ingen del af systemet virkelig er uden for deres rækkevidde. Det er sundt og nyttigt at diskutere arkitekturændringer med et andet team, og det kan måske give dig et nyt perspektiv. At tilbyde at bidrage til den ændring, som du har brug for, er fantastisk til at opbygge tillid mellem teams. At røre ved et nyt domæne er en oplevelse, som du kun kan få gavn af. Vigtigst af alt er, at når dine grænser bliver mere fleksible, betyder det, at din indflydelse vokser. Når du undgår at række ud over dine grænser, skal du indse, at det, du faktisk gør, er at holde dig selv tilbage fra at have en større indflydelse.
Ansvar / ejerskab
Og selv om det ikke umiddelbart er tydeligt, vil du meget ofte, hvis du graver i den grundlæggende årsag til, hvorfor et projekt blev forsinket eller mislykkedes, opdage, at det koger ned til ejerskab og ansvar. Folk vil altid have en tendens til at give deres omgivelser skylden: “Jeg var nødt til at vente på, at et andet team skulle færdiggøre noget”, “Jeg havde et systemproblem, og ingen havde tid til at hjælpe mig”, “Jeg fik definitionerne for sent”. En god ingeniør ved, at disse ting næsten altid er undskyldninger. Når du er ejeren af opgaven, og ansvaret for at få den løst ligger hos dig, bør din tankegang være, at ethvert problem, du støder på, er noget, du skal løse. Hvis du bliver blokeret af et andet team, skal du gå hen og tale med dem. Tilbyd at danne par om problemet, og lad være med at “smide” ansvaret over på en anden. Hvis I ikke har fået definitioner endnu, så lav nogle antagelser om, hvad definitionerne vil være. Det er bedre at gøre nogle fremskridt og senere foretage justeringer end bare at sidde og vente. Hvis der er noget stort, der forsinker dig, skal du vide, hvornår du skal hejse flaget og vide, hvordan du kan omgå problemet, så du i det mindste kan gøre fremskridt på en anden front. Vær aldrig i en situation, hvor en anden er ansvarlig for at løse dit problem, det er omvendt – du er ansvarlig for at nå i mål, og du skal håndtere forhindringer på vejen.
Kommunikation
Dette er en rigtig game changer og ofte den mest kritiske ting at have for en ingeniør for at kunne have en stor indflydelse på hele teamet. At kunne kommunikere er den største enkeltstående ting, der har gjort det muligt for menneskeheden at blive, hvad den er, og det samme er naturligvis lige så afgørende for ethvert aspekt af livet, herunder softwareudvikling. Gode ingeniører skal være i stand til at forklare deres idéer og holdninger på en veltalende måde. De skal være i stand til at debattere intelligent og respektfuldt med deres kolleger. Kommunikation handler ikke kun om at tale, det er endnu vigtigere at være i stand til at lytte. Ikke alle i teamet vil være i stand til at udtrykke deres idéer lige så godt, og en god ingeniør skal være tålmodig og stille de rigtige spørgsmål for at forstå, hvad andre tænker, og hjælpe dem til at blive hørt. Alt dette er lige så vigtigt både for mundtlig og skriftlig kommunikation, og endnu vigtigere er det, at det ikke kun er samtaler – udviklernes liv er fyldt med tonsvis af kommunikationsformer: dokumenter, præsentationer, dokumentation, kodekommentarer, commit-meddelelser. Selv at skrive læsbar kode og vælge gode variabelnavne er en form for kommunikation.
Teamarbejde
Det er et af de steder, hvor selv erfarne ingeniører fejler meget ofte og ikke engang ved, at det sker. Tænk på alle de gange, hvor du har sagt “det er for kompliceret, overlad det til mig”. Tænk på de gange, hvor du har sagt “denne opgave er et enmandsarbejde, det bliver ikke lettere at tilføje flere folk”. Tænk på alle de gange, hvor du ikke har haft tid til at hjælpe en anden og aldrig har fulgt op, eller hvor du har rettet/refactoret nogens kode uden at bede om deres gennemgang, eller hvor du har foretaget en stor ændring uden at rådføre dig med dit team. Der er masser af eksempler. Og sagen er, at selv for erfarne ingeniører virker det i øjeblikket som det rigtige at gøre. Men det er taktisk tænkning, som kun betaler sig på kort sigt. Hvis vi ønsker at opnå store ting, skal vi sørge for, at vi kan samarbejde som et team. Det er ikke tilfældigt, at teamwork kom lige efter kommunikation. Det er de ting, der gør os mest effektive, det er grundlæggende biologi. Store ingeniører samarbejder ikke kun med, rådfører sig med, lærer af, hjælper, danner par og respekterer deres kolleger, de er også mentorer, påpeger problemer, finder interesse og lærer af alt, hvad der sker i teamet, og forsøger proaktivt at være behjælpelige, selv med hensyn til ting, der ikke direkte vedrører dem selv. Fantastiske ingeniører ved, hvornår og hvordan de skal komme med designs, der gør det lettere for mange mennesker at samarbejde om ting, hvor der forventes meget arbejde.
Hold det simpelt
Kompleksiteten af en løsning kan være en af de tavse dræbere af teamets evne til at komme videre og tilpasse sig. Det er ligesom højt blodtryk. For det utrænede øje ser det ud til, at alt er fint, og at alt fungerer som forventet, men faktisk er der dybt inde i dig noget, som ikke direkte påvirker nogen hovedfunktionalitet, der langsomt slår dig ihjel. Gode ingeniører skaber pragmatiske løsninger og læsbar kode, selv om man skriver flere linjer kode. Du skal ikke vise, hvor “smart” du er ved at bruge alle sprogets muligheder, skabe overflødige abstraktionsniveauer eller skrive en funktion i én linje, som ingen andre kan forstå eller fejlfinde. Vær ikke purist, lad være med at over-engineere løsninger, hvor det ikke er absolut nødvendigt, og vær aldrig bange for at tage noget, der allerede er komplekst, og prøv at forenkle det.
Prioritering
Vi kan ikke gøre alt. Vi kan ikke løse alle problemerne. Vi kan ikke vinde alle debatterne. Vi kan ikke gøre alting perfekt. Vi har begrænset tid og begrænsede ressourcer, og vi skal bruge dem klogt. Det betyder, at vi skal være i stand til at skelne mellem det, vi skal insistere på at gøre, det, vi kan udsætte, og det, vi bør ignorere. Udviklere træffer disse beslutninger snesevis af gange hver dag. Når vi overvejer, om vi skal undersøge en fejl, når vi overvejer at foretage en refaktorering, når vi overvejer at håndtere en eller anden use case eller edge case, når vi overvejer at tage en omvej fra vores planlagte opgave, og selv når vi investerer tid i at overbevise nogen om vores mening. Gode ingeniører ved, at de skal være ubarmhjertige med at rette, undersøge, forske eller insistere på at gøre deres pointe gældende for de ting, der virkelig er vigtige. De ved, at de kan tage et notat og vende tilbage til noget senere, hvis det er vigtigt, men ikke presserende. Og de ved, at de kan lade noget ligge eller acceptere en andens mening, selv om de er utilfredse med den, når det ikke er så vigtigt.
Tidsstyring
Som nævnt ovenfor er den triste sandhed i vores tilværelse, at vi er bundet af tid. De produkter, som vi udvikler, skal i sidste ende gå live, vi har deadlines og estimater og mål, som vi skal nå. Gode udviklere skal ikke blot udvikle en intuition for at vurdere, hvor lang tid deres opgaver tager, men de skal også være kloge på, hvordan de nedbryder og ordner deres opgaver til endnu mindre dele. De er nødt til at håndtere deres afbrydelser og kontekstskift klogt. Denne intuition for tidsvurdering er en uadskillelig del af evnen til at prioritere som beskrevet ovenfor. Hvis noget f.eks. er kort nok, kan det være værd at gøre, selv om det ikke er supervigtigt. Og hvis det er for langt, er det måske bedre at udskyde det lidt eller rådføre sig med dine kolleger eller din leder.
Konklusion
Som tidligere nævnt mener vi, at ingeniører, der er eksperter i alt det ovenstående, kan gøre teamet 10x bedre ved at påvirke og inspirere deres kolleger. Gode ingeniører skal altid huske, at dette er en del af deres daglige arbejde: at påvirke og inspirere. Det betyder, at du skal finde tid til ikke kun at gøre dit arbejde, men også til at hjælpe andre med at gøre deres arbejde. Dette kommer i mange former: mentorering af folk på dit team, oprettelse af ressourcer til at uddanne folk, sørg for, at alt er godt dokumenteret, vær altid åben for at forklare og parre med folk og meget meget mere. At være en god mentor og underviser betyder, at du ikke kun hjælper dine teammedlemmer med at vokse, men at du også uddyber din egen forståelse af alt det, du laver, og at du får et nyt perspektiv på tingenes klarhed, systemets kompleksitet og de steder, hvor tingene kan forbedres.
Det er det, der kendetegner 10x-ingeniører, ikke kun i deres individuelle indflydelse, men også i deres indflydelse på alle andre. Spørg altid dig selv, hvad du kan gøre for at gøre din indflydelse større, der er altid mere plads til at vokse.