Hvad kendetegner en 10x Developer?

10x-udviklere er vor tids mytiske væsener.

Hvad er de? Hvad gør de for at være så specielle?
Hvad betyder 10x overhovedet? En 10x-udvikler er en person, der er (menes at være) lige så produktiv som 10 andre. Han/hun vil derfor være i stand til at producere 10 gange så mange resultater som sine kolleger.

Hvad taler vi egentlig om?
Naturligvis kan en senioringeniør være 10 gange mere produktiv end en praktikant, men ville det virkelig være muligt blandt kolleger med samme års erfaring og i det mindste på papiret samme niveau af færdigheder?

Ofte når man læser om præstationer og produktivitet i teams, finder man ting som Pareto-loven og den Gaussiske kurve. (også omtalt som Power Law og Bell Curve).
Pareto-loven er den berømte 80-20-regel, der gælder for næsten alt: fra velstandsfordeling og global ulighed til tidsstyring og produktivitet.
Når man taler om Team Performance, resulterer det i :
80% af udviklerne gør kun 20% af arbejdet. Det betyder, at de resterende 20 %, de bedste udviklere, er i stand til at udføre 80 % af alle opgaverne.
Bell-kurven bruges ofte til at beskrive fordelingen af medarbejdernes evne til at præstere, idet den angiver, at omkring 80 % af medarbejderne placerer sig omkring gennemsnittet, mens resten enten er top performere eller dårlige performere.

Hvordan vi end måtte se på disse grafer og tal, kan forskellen mellem den bedste og den dårligste præstationsmand i et team være enorm. Måske refererer vi bare til det, når vi taler om en 10x dev? Eller vi skal bare se på forskellen i forhold til gennemsnittet af de andre dev. Uanset om sådan noget ville være statistisk muligt eller ej, kan vi ikke benægte, at nogle udviklere faktisk er langt mere performante end andre.
Så hvor kommer denne fantastiske evne fra?

Er det på grund af mange års erfaring? Ikke rigtig.

10 års erfaring kunne blot betyde en 1-årig erfaring gentaget 10 gange.

Hvis du sidder fast i det samme job og laver den samme opgave hver dag, hvert år, og hvis du ikke føler trang til at stige op og lære nye ting, kan du blive overrasket, når en almindelig udvikler med kun 3 år på sit CV er lynhurtig og ved mere end dig (ikke kun om den nyeste cooleste tech stack).

Er det fordi de arbejder til sent og ikke har et liv? Ikke rigtig.

En 10x dev er ikke grinding lange timer. Det betyder ikke at arbejde længere. Det betyder helt klart, at man arbejder hårdere, men mest på en smartere måde.

Jeg er langt fra at være en 10x dev, men i min karriere har jeg været så heldig at møde og arbejde sammen med mindst et par af disse fantastiske personer, og jeg kan fortælle, at dette er nogle af de træk/egenskaber, de havde til fælles:

Arbejde på de rigtige ting på den rigtige måde

Effektivitet og effektivitet:

At være effektiv handler om at gøre de rigtige ting, mens at være effektiv handler om at gøre tingene rigtigt.

Nå, men 10x udviklere gør normalt begge dele. De spilder ikke tid på at gøre unødvendige ting på den mest perfekte måde. De får gjort de rigtige ting på den (nok) rigtige måde.
Dette kan opnås ved:

Stil spørgsmål

hvorfor

Sommetider kan dårlige krav, uklare specifikationer og forkerte antagelser få dig til at spilde timevis af udviklingstid. Ikke alene bliver du nødt til at justere dine estimater eller klemme omarbejde ind, men det kan også være meget frustrerende at skulle smide al den fantastiske kode væk, du lige har lavet.

hvordan

Hvis du er gået i stå, hvis du har brug for hjælp, så spørg om hjælp. Du skal ikke bede om en løsning, men om et hint, om vejledning, om et tip, der kan føre dig til at finde løsningen på egen hånd. du skal ikke være bange. det er ikke meningen, at du skal vide alt, og det er godt, at du viser, at du er ivrig efter at lære.

Vær fokuseret, undgå distraktioner

Hvor meget tid bruger vi egentlig på at se youtube, tjekke vores telefon, svare på venner på WhatsApp eller Snapchat eller blot scrolle på Facebooks væg?
Hvad hvis jeg fortæller dig, at du bruger 1-2 timer om dagen på dem? tjek brugen af disse apps på din telefon. du vil blive bange. (du kan bruge apps som denne til at bevise det).
Vi behøver ikke nødvendigvis at holde op med alt det. Bare at erkende, hvor meget tid vi spilder på disse ting, når vi burde være produktive, er det første skridt, og så kan vi bruge værktøjer som Pomodoro teknikken til at hjælpe os med at holde os væk fra sociale netværk og smartphone og holde FLOWet i mindst hele varigheden af en Pomodoro timer.

Jeg siger ikke engang, at vi ikke skal tage en pause, det er mere at være virkelig bevidst om, hvor vores dyrebare tid bliver drænet. (selv om det helt sikkert er bedre at rejse sig op, gå en tur, tage en snak med en kollega, gå ud og spille kicker eller bordtennis i 10 minutter, i stedet for at tjekke Facebook. Giv dine øjne og din hjerne lidt hvile fra enhver skærm!).

Hvis du holder en pause, slapper af i et lille stykke tid, kan du faktisk øge din produktivitet

Brug værktøjer, der gør dig hurtigere, lær genveje

Det vi gør mest er at skrive og klikke, det virker skørt, men du kan virkelig blive superhurtig, hvis du begynder at bruge genveje i dit IDE og hvis du bruger Terminal / CommandLine i stor stil. At køre grep version package.json er meget hurtigere end at gå til Finderen, klikke på package.json open og derefter læse versionsparameteren.
Typning

git stash git pull git checkout -b my_new_feature git stash pop

er waaaay faster than doing the same thing with any visual tool.

Du tror måske, at det bare er at barbere sekunder af, men for at blive en 10X dev betyder hvert sekund noget (og alligevel er det godt at holde sig væk fra musen for at forhindre karpaltunnelsyndrom)
Her kan du læse om nogle værktøjer og tips, der hjælper mig med at skrive og debugge kode bedre og hurtigere.

Vær ivrig efter at lære

Mængden af information derude er enorm. Nogle gange skal du betale for det, det meste af tiden er det gratis. Der er ingen undskyldninger for ikke at bruge noget tid på personlig udvikling. Læs artikler, lyt til podcasts, se tutorials og følg onlinekurser. Det behøver ikke engang altid at handle om kodning – ellers kunne man argumentere for, at en 10x dev faktisk bruger hele sin dag på at “arbejde” – ( jeg synes f.eks. at Getting Smarter Every Day og You are not so smart er meget tankevækkende).
Det er mere en holdning, en sindstilstand. Nysgerrigheden, tørsten efter viden sætter forskellen fra gennemsnittet.

Omgiv dig selv af Top Performers / Find en Mentor

At være den hurtigste, smarteste, mest dygtige udvikler i dit team er måske godt for dit ego, men det er ikke for din vækst. Uanset hvor behageligt og tilfredsstillende det kan være, så prøv aldrig at være den klogeste person i lokalet, og hold altid øje med folk, der er meget dygtige til det, de laver, som er bedre end dig, og hold dig til dem.

Giv noget tilbage. Del din viden

Så snart du lærer noget, så prøv at hjælpe andre, undervis andre kolleger, del din viden.
Det kan være at give nogle råd efter din daglige standup, lave en kort præsentation for dit team, skrive et blogindlæg eller blive mentor på en online kodningsplatform.
Vær aldrig arrogant eller irriteret over for nogen, der ved mindre end dig.

Hvis vi tager alt dette i betragtning, har en rigtig god udvikler naturligvis solide stærke programmeringsfærdigheder, men det, der virkelig kan gøre forskellen, er passion, holdning og nogle bløde færdigheder.
De kolleger, som jeg så med ærefrygt og inspirerede mig mest til at forbedre mig selv, var meget motiverede og dygtige og naturligvis super hurtige i deres opgaver: intet syntes at stoppe eller skræmme dem, hvis de ikke vidste noget, undersøgte de det i et par timer og følte sig derefter selvsikre nok til at tage ejerskab for fejlrettelsen eller funktionen. Og oven i købet skrev de dokumentation, organiserede workshops eller minipræsentationer, så snart de fandt eller lærte noget, som kunne være til gavn for andre teammedlemmer. De elskede at dele.

Og i sidste ende tror jeg, at dette kunne være den virkelige multiplikatorfaktor. At dele viden, fremme vækst, være et eksempel på passion og hårdt arbejde, er det, der virkelig kan have en utrolig positiv indvirkning på andre mennesker og hæve barren i et teams præstationer ( selv om det kun består af “gennemsnitlige” udviklere).