De 10 punkter, der kendetegner virkelige “10x ingeniører”

Du har måske set en tråd, der cirkulerer rundt på Twitter for nylig om “10x ingeniører”. Hvis du ikke har, kan du læse den i al sin pragt:

Shekhar Kirani @Accel

@skirani

10x ingeniører
Grundere, hvis du nogensinde støder på denne sjældne race af ingeniører, så tag fat i dem. Hvis du har en 10x ingeniør som en del af dine første få ingeniører, øger du oddsene for din startup-succes betydeligt.
OK, her er et svært spørgsmål.
Hvordan spotter du en 10x ingeniør?

13:02 PM – 11 Jul 2019

Sammenfattende er det sådan, at medmindre du passer til et eller andet super snævert og stereotypt syn på at være udvikler, så er du ikke en “10x engineer”.

Mange vil sige, at en “10x ingeniør” ikke eksisterer, da det at være 10x bedre til noget end nogen/den største del af befolkningen ville være pokkers svært. Selv om personen ikke mener “10x” bogstaveligt talt, er det stadig et forsøg på at sige, at der er nogen, der er betydeligt bedre til alting.

Personligt hader jeg udtrykket “10x ingeniør”. Ligesom “rockstar-udvikler” er de dårlige beskrivelser og definitioner af, hvad gode udviklere er.

Det ville være uoprigtigt at sige, at alle udviklere er lige gode. Bare et par minutters kig på forskellige udviklere på Twitter, kan jeg allerede se mange udviklere, der ved en helvedes masse mere end jeg gør. Når det er sagt, er det temmelig latterligt at tale om denne “10x ingeniør”, som om de kan øge chancerne for, at din virksomhed bliver en succes, betydeligt.

Godt nok om at slå ned på den forfærdelige stereotype af “10x ingeniør”, lad os tale om de ting, der virkelig gør store udviklere (aka den virkelige “10x ingeniør”).

1. De er kloge, men kender deres grænser

Medmindre der er tale om en eller anden trivielt lille kodebase, kender de ikke hver eneste linje kode, der er gået i produktion. Selvfølgelig kan de løse mange problemer selv, men de ved, hvornår de er gået i stå og ved, hvornår de skal bede om hjælp.

Det er ikke forkert at bede om hjælp, uanset dit færdighedsniveau!

2. Stærk selvstændigt, men stadigvæk et supergodt team

Der er tidspunkter til at programmere selvstændigt, og der er tidspunkter til at programmere i et team. Disse udviklere tager ikke bare en opgave og løber ind i et hjørne for at arbejde på den i silo i forhold til alle andre. Udvikling ud over den mindste skala kræver konstant samarbejde med et team – uanset om det er parvis programmering, kodegennemgange, afprøvning af idéer, hjælp til fejlfinding osv.

Det betyder ikke, at en god udvikler ikke har det bedre med at arbejde alene med visse opgaver, men udvikling i stor skala er praktisk talt umulig uden et stærkt samarbejde.

3. De hjælper andre med problemer

Har du nogensinde bedt en kollega om hjælp, og de gjorde det? Tillykke, de er måske en fantastisk udvikler. Vi kan kigge på dokumentation eller endda Stack Overflow for at få hjælp, men nogle gange har vi faktisk brug for hjælp fra en person, der kender vores kodebase. Hvis du er en udvikler, der ved noget, som kan hjælpe en kollega, så hjælp dem!

4. De er venlige og forstående

At være en god udvikler handler ikke om at være en smart ass, vise sit intellekt frem, se bort fra møder, fordi man er bedre end de mennesker. At være en god udvikler handler også om at være god til de ikke-tekniske ting. Hvis du “hjælper” en kollega ved at råbe af ham og kritisere hans kode, skal du bare stoppe.

5. De udfordrer dig (på den rigtige måde)

Dette lyder måske kontroversielt, men en god udvikler vil ikke give dig svarene hele tiden. Det lyder måske i modstrid med #2 og #3, men det er ikke meningen, at dette skal holde noget over dig. En god udvikler er en, der kan give dig lige akkurat nok, så du selv kan løse det. Disse små udfordringer er med til at gøre dig til en bedre udvikler og giver dig mulighed for at forstå, hvilke ting du måske har brug for at lære mere om.

6. De forstår, at “new shiny” ikke er løsningen på alt

Det betyder ikke, at disse udviklere ikke tjekker nye værktøjer og sprog (de kan gøre, hvad de vil i den henseende), men de forstår, at nye værktøjer ikke på magisk vis vil løse alle problemer.

James Hickey 🇨🇦👨💻

@jamesmh_dev

Vi er besat af at lære om flere værktøjer og sprog!
Hvis din arkitektur er dårlig, du løser de forkerte problemer, din kunde forstår ikke, når du prøver at forklare tingene… så hjælper skinnende værktøjer ikke.
Og disse er grundlæggende for din virksomheds succes!

18:54 PM – 27 Jun 2019

7. De ved, at det er ligegyldigt, hvornår du programmerer, og hvilket editor-tema du bruger

Sterotyper om programmører til side, hvorfor skulle tidspunktet, hvor du programmerer, egentlig gøre en forskel? Programmer midt om natten, hvis du vil/har fået lov af firmaet, og lad være med at gøre det, hvis du ikke har lyst til det. Den eneste grund til at tidspunktet skulle komme i spil er, når du har programmeret for længe og ikke har sovet! Det faktiske tidspunkt på dagen er ligegyldigt, medmindre det påvirker dit team (f.eks. arbejder du ved midnat med at programmere for bevidst at undgå alle).

Samme med editor temaer, hvorfor skulle et mørkt tema egentlig gøre dig bedre? Jeg vil give dig et hint, det gør det ikke. Mørke temaer har deres formål, men det er helt sikkert ikke det.

8. De går ikke ud af deres vej for at gøre noget mere komplekst

Dette er måske indlysende, men der var en anden Twitter-tråd i forrige uge, der talte om, at det er en god ting at programmere noget komplekst, som om det er en god ting at gøre. Hvornår var det en god ting at gøre vores job og vores kollegers job sværere?

Der er helt sikkert tidspunkter, hvor vi kan ende med at programmere en kompleks løsning, som om vi måske ikke (endnu) forstår problemet fuldt ud. Dette kan ske i vores første forsøg på at programmere løsningen, det er der, hvor man normalt hører folk tale om at refaktorisere kode eller ikke være “stolte” af den kode, de skrev den foregående uge/måned/år.

9. De tænker ikke på “mig” i “team”

Medmindre de virkelig har skrevet hver eneste linje kildekode selv fra compileren og op gennem hele forretningslogikken, ved de, at det var en holdindsats. De forsøger ikke at tage opmærksomheden fra andre på holdet – de fremhæver alle de bidrag, der har gjort et projekt til en succes.

Når et projekt går dårligt, giver de ikke alle andre skylden. Teamprojekter fejler som et team, ikke som en enkeltperson (medmindre der er tale om ond vilje). De hjælper hele holdet med at lære af fejlene og hjælper med at forhindre, at de sker igen.

10. Du har faktisk lyst til at arbejde sammen med dem

I sidste ende er disse fantastiske udviklere mennesker, som du faktisk nyder at arbejde sammen med. Du dukker op på arbejde (eller fjernbetjener dig) og er glad for at arbejde sammen med et så fantastisk team.

Hvis du kender nogen udviklere, der lyder sådan, så fortæl dem, hvor fantastiske de er, og hvor glad du er for at arbejde sammen med dem. 🙂