Between the Wires: Et interview med open source-udvikler Sindre Sorhus

Her er mit interview Sindre Sorhus, en produktiv open source-udvikler, der bor i Thailand.

Fortæl os lidt om din barndom, og hvor du voksede op.

Jeg voksede op i et forstæderområde uden for Oslo, Norge. Da jeg var lille, var jeg virkelig interesseret i Legos. Hvert år ville jeg få Legos til fødselsdag og jul. Legos skabte virkelig mine interesser i at opbygge ting tidligt. På et tidspunkt fik jeg en enorm Lego-by indbygget i mit værelse, og det besatte næsten hele rummet.

Hvordan kom du ind i programmering?

Da jeg var syv, fik min familie vores første Windows 95-computer. Jeg plejede at spille et spil kaldet Map Blaster, hvor karakteren hoppede rundt for at løse matematiske problemer. Et par år senere fik vi endelig internetadgang, og det ændrede alt for mig. Jeg brugte meget tid på at skrive i gæstebøger på andres websider og indsamle gifs. En dag blev jeg nysgerrig efter, hvordan hjemmesiden fungerede, og opdagede knappen "Vis kilde" i browseren.

Det var en mind blowing opdagelse for mig. Jeg kunne bare højreklikke, se kilden og så kunne jeg se, hvordan alt blev lavet. Jeg forstod ikke meget i starten, men da jeg kiggede på det samme igen og igen, begyndte jeg at forstå, hvordan det fungerede. Sådan startede jeg min programmeringsrejse.

Jeg lavede mit første websted, da jeg var ti. Det var efter at have set på kilden i et par år. Det havde alle mulige farver, en stjernemønstret baggrund, animeret med mediebaggrundsmusik - det var en af ​​de detaljer, som alle havde på deres hjemmesider dengang. Jeg brugte Microsoft FrontPage.

En gang kede jeg mig, så jeg oprettede tusindvis af indlejrede mapper på min fars computer, og det endte med at gå ned på computeren. Min far var nødt til at omformatere computeren; han blev imponeret og irriteret på samme tid. Det var også sådan, jeg mistede mit første websted.

Senere i løbet af mit skoleår kom jeg ind i Flash-spil, og vi ville se en masse Flash-film i skolepauserne. Jeg var nysgerrig, hvordan de blev lavet, men der var aldrig nogen kilde-knap. Så jeg dekompilerede swiff-filerne, det var let, fordi de ikke var tilslørede. Det gav mig igen muligheden for at lære af andres arbejde. Jeg begyndte at ændre andres spil og redid alle tegn, skabte nye fjender, tilføjede høj score. Det var et stolt øjeblik, da jeg indså, at andre faktisk kunne spille et spil, som jeg havde limet sammen.

Du tilbragte fem år i militæret som frontudvikler og fotograf. Hvordan var webudviklingen dengang?

Efter eksamen fra gymnasiet blev jeg ansat direkte til militæret i Norge. Jeg kom ind i medieenheden, hvor jeg tilbragte det meste af min tid på kontoret og arbejdede på intranettet. Der var ikke meget at lave om aftenen, fordi vi boede i kasernen, så jeg besluttede at bygge ting. Men det meste af min erfaring havde været at kopiere og indsætte andres PHP og JavaScript, og jeg forstod ikke helt, hvordan de fungerede. En dag snublede jeg over Python og Django, det havde god dokumentation og tutorials, som PHP aldrig havde. Jeg læste selvstudier hver dag og begyndte at bygge ting på arbejdspladsen.

Sådan startede min faktiske kodning. Efter værnepligt planlagde jeg at rejse inden college. Men jeg fik et jobtilbud fra en enhed i militæret ved navn Cyber ​​Defense Unit. Det var spændende, så jeg tog tilbudet, og jeg tilbragte 5 år der.

Hvordan blev du involveret med TodoMVC og Yeoman?

Jeg begyndte at bruge GitHub omkring 2011, men hovedsagelig som forbruger. Jeg ville gå rundt og se på forskellige repoer og medvirkede i dem, fordi de så sjove ud. Jeg fik nogle skrivefejl i README.md-filer, men det handlede om det.

En dag snublede jeg over TodoMVC, som hjælper dig med at vælge en JavaScript-ramme. Det var en rigtig fantastisk idé, selvom vi i bakspejlet har brug for meget mere avancerede applikationer til faktisk at løse problemerne med præstationstest og rammefunktioner. Den første ting jeg huskede ved TodoMVC var, at den havde et dejligt logo. Det virker meget overfladisk, men det var det, der fik mig i gang.

Jeg kunne godt lide logoet så meget, at jeg besluttede at kigge mig lidt mere rundt. Jeg bemærkede, at de ikke rigtig havde en jQuery-applikation, så jeg besluttede at oprette en. Jeg indsendte en pull-anmodning i løbet af weekenden og fik et svar tilbage fra Addy Osmani, som er projektholderen. Han flettede hurtigt min PR, hvilket var en super dejlig oplevelse for en nybegynder som mig. Jeg følte godt, at min app nu var inkluderet i dette virkelig populære projekt. Jeg gjorde dette i et par uger, og Addy tilføjede mig til projektet, som var virkelig sejt.

Dette fik mig virkelig interesseret i open source. Før dette var jeg bare en passiv forbruger, men med TodoMVC fik jeg en smag af at opretholde et stort projekt, der var meget arbejde. Men jeg lærte meget af den erfaring.

Et par måneder senere gik Addy på arbejde for Google. Hans første projekt hos Google var Yeoman, et stilladsværktøj til moderne webapps. Fordi vi arbejdede så godt sammen på TodoMVC, besluttede han at invitere mig som ekstern bidragyder.

Vores oprindelige mål med Yeoman var at skabe et sæt værktøjer, som alle kan bruge til at oprette gode webapps. Hvad vi ikke vidste dengang, er, at det er umuligt at løse alles problem i et værktøj, fordi der på nettet er bare for mange brugssager. Yeoman blev en populær konfiguration, som mange udviklere skabte generatorer for at udvide Yeoman, der passer til deres eget brugssager.

Historien gentager sig også, hvis du ser på Create React App eller Webpack. Nogen starter med at fremstille dette produkt, der skal løse et problem, men fordi alle har forskellige behov, opstår der problemer. Når du er klar over, at dette værktøj ikke kan dække alt, tilføjer du konfigurationen. Nøglen er at have en afbalanceret tilgang. Du skal sige "Nej", og du skal vide, hvornår du skal sige "nej". Du kan skuffe nogle brugere, fordi de har uklare brugssager. Det er den svære del af at fremstille værktøjer, og det er endnu sværere i open source-projekter, fordi der er så meget feedback.

Hvorfor brænder du for open source?

Jeg elsker open source, og jeg tror, ​​det går tilbage til knappen "Vis kilde" i browseren. Efter min mening er open source den mest effektive måde at opbygge software på, fordi det gør det muligt for os at bygge oven på hinandens arbejde. Alle har gavn af det, hvis en person løser et hårdt problem. Open source lader mig arbejde med utrolige mennesker fra hele verden, som jeg ellers aldrig ville have været i stand til at arbejde med. Vi kommer i gang med det, der betyder noget for os, og fokuserer på, hvad samfundet har brug for i stedet for at fokusere på at generere indtægter.

Paul Irish har en fantastisk video på YouTube med titlen "Ti ting, jeg lærte af jQuery Source." Det var det, der fik mig til at læse jQuery-kildekoden. Paul Irish havde ret, du lærer meget ved faktisk at gøre hvad det er, du vil lære at gøre.

Hvad med open source bæredygtighed?

Det er bestemt et konfliktpunkt, som jeg har tænkt meget på for nylig. Jeg har gjort open source på fuld tid i omkring tre år nu. Jeg tjener ingen penge, men det ville være rart at gøre dette på fuld tid som et betalt job. Vue.js af Evan You er dog et godt eksempel på, hvordan open source bæredygtighed kan fungere. Han skabte en ramme, som alle ønskede, og den er blevet brugt af en hel del virksomheder. Andre virksomheder og enkeltpersoner har incitamenter til at investere i hans projekt, fordi det er nyttigt i produktionen. Nøglen er at gøre dit projekt pålideligt. Jeg synes personligt ikke, at bidrag fra enkeltpersoner er nok til at opretholde et projekt.

Jeg har tænkt på at bruge Open Collective, så vi kan indsamle penge til at belønne bidragydere og kampagner. Webpack har gjort et godt stykke arbejde der. Jeg var faktisk imod dette i lang tid, fordi jeg var bekymret for, at der ville være forventninger til os om at foretage uønskede ændringer, når nogen satte penge i projektet. Normalt, hvis en virksomhed investerer i et projekt, ønsker de, at arbejdet prioriteres, og problemerne løses hurtigt.

Jeg bor i øjeblikket i Thailand, og jeg tror, ​​jeg ville have det godt med mindre end 1500 dollars.

Du har over 1000 npm-pakker. Hvordan forbliver du så produktiv?

Det er en misforståelse. Folk ser antallet af 1000 pakker, og de synes, jeg er sindssygt produktiv, men hvad de ikke er klar over, er at de fleste af disse pakker er små og modulære. De er stort set færdige, når de offentliggøres. Jeg kan godt lide at sammenligne programmering med bygning med Lego: Jeg opretter masser af Lego-klodser, som kan samles til at bygge større konstruktioner. Jeg bruger dem sammen med andre pakker inden udgivelse for at sikre, at de løser mine problemer. Det er også derfor, at brugerne ikke ville indsende mange funktionsanmodninger, fordi de er så små. Hvis de har brug for noget mere, kan de bare bygge et andet modul. 90% af min tid bruges på mine 10 største projekter.

Hvad er et råd, du kan give til nye OSS-bidragydere, når du beskæftiger dig med krævende og giftige mennesker?

Jeg har lavet open source i seks år nu, så jeg har udviklet en tyk hud. Jeg tror ikke noget generer mig mere, fordi jeg kan lide at tro, at jeg har oplevet det hele. Jeg taler med mange begyndere, der oplever toksicitet og derefter holder op. Open source skal være en sjov ting, du gør, ikke en årsag til stress i dit liv.

Mit råd til nye udviklere er, at du ikke skal lade fremmede på internettet påvirke dit humør eller dit drev negativt. Det er det ikke værd. Hvis du har mulighed for at gå væk, skal du tage den - brug knappen til afmelding. Open source-vedligeholdere skal huske, at brugerne ikke betaler kunder. Vi leverer noget til dem gratis på vores egen fritid.

Med giftige mennesker skal du altid være den større person. Det lyder forkert, men hvad jeg prøver at gøre er at dræbe dem med venlighed. På en eller anden måde har det fungeret for mig i mange år. For eksempel, hvis nogen er irriterende, vil jeg prøve at være så åben og venlig om situationen. Jeg sørger for aldrig at være sarkastisk eller tale ned til dem. Troldene lever af din irritation og diskurs, så når de ikke er der, vil de lade dig være i fred.

Jeg bruger muting-indstillingen, uanset hvor den leveres, især på Twitter. Det er godt at indse, når nogen grænser op til giftige, og det er meget bedre bare at lukke den stemme og input ud i stedet for at forårsage unødvendig konflikt.

Du designede nogle logoer til dine egne moduler, de er fantastiske. Hvordan lærte du design?

Jeg startede med at følge online tutorials for at få seje effekter. Jeg brugte Adobe Illustrator, men nu bruger jeg Sketch.

Det er virkelig sjovt for mig at designe, og jeg synes, at flere programmører burde prøve det. Efter programmering i timevis er det rart at tage en pause for at udføre noget kreativt arbejde på en anden måde.

Det gavner også mine projekter ved at oprette logoer, fordi det giver projektet mere personlighed. Normalt, når du indtaster en repo på GitHub, får du de samme tekstbaserede ting: et header, en introduktion og README.md. Det er rart at krydre det med noget grafik. Det viser sig, at folk er mere tilbøjelige til at bruge projektet, hvis der er et logo. For eksempel indsendte Vadim Demedes, en udvikler fra Ukraine, denne pull-anmodning lige efter AVA's frigivelse. Vadim blev senere AVA-teammedlem. Han fortalte mig, at han blev interesseret i AVA på grund af det dejlige logo.

Hvad fik dig til at flytte til Thailand? Fortæl os, hvordan en typisk dag ser ud for dig.

Jeg vidste slet ikke meget om Thailand. Da jeg arbejdede i den militære obligatoriske tjeneste, planlagde jeg at rejse. Jeg fik et tilbud og endte med at blive i yderligere fire år. Jeg gik bare med strømmen, fordi livet sker.

En dag, da jeg forberedte et telefoninterview med Google, besluttede jeg bare, at hvis jeg nogensinde skal rejse, ville det være nu, ellers ville det aldrig ske. Så jeg aflyste interviewet og sendte min fratræden på arbejde dagen efter. Jeg købte en enkeltbillet til Thailand, og det var det.

Jeg lavede backpacking i et halvt år i Sydøstasien, og det var her, jeg mødte min kæreste. Til sidst bosatte jeg mig i Thailand, fordi det var min favorit. Jeg elsker dens rige kultur, venlige lokale og mad. Jeg har boet i Thailand i to år nu.

Jeg arbejder ud af lokale kaffebarer tre dage om ugen, fordi jeg er mere produktiv, når jeg har folk omkring mig. Ellers laver jeg meget open source-kodning og vedligeholdelse fra ni til seks, nogle gange mine sideprojekter. De fleste dage får jeg mere end 20 pull-anmodninger og masser af problemer at rette. Om aftenen tilbringer jeg tid med min kæreste Im; vi begge elsker den krydrede gademad på nattemarkederne. Nogle gange ringer pligt, og jeg befinder mig tilbage foran computeren sent om aftenen.

Jeg lærte ikke det thailandske sprog, for mens jeg er god til programmeringssprog, er det talte sprog meget sværere end noget programmeringssprog, og thailandsk er især svært. Min kæreste er derimod flydende i thailandsk, russisk, engelsk og temmelig god til svensk. På et eller andet tidspunkt vil jeg lære thai og andre sprog, men jeg er ikke presset til tiden.

Hvad motiverede dig til at starte AVA-projekt?

Jeg brugte Mocha meget, fordi jeg lavede mange moduler, der skulle testes. Jeg var ikke rigtig tilfreds med, hvordan det fungerede. Mocha injicerer nogle globale objekter, men de er ikke defineret nogen steder. Fordi jeg gjorde det i Node.js, havde jeg mange async-API'er, og det var ikke særlig praktisk at gøre med Mocha.

Jeg ville have noget enklere og mere optimeret til min brugssag. Så en weekend besluttede jeg at arbejde på det, og søndag aften offentliggjorde jeg 0.0.1-versionen til AVA på npm. Selvom JavaScript er single-threaded, kan IO i Node.js ske parallelt på grund af dets asynkroniske natur. AVA drager fordel af dette og kører dine test samtidigt, hvilket er især gavnligt for IO tunge tests. Derudover køres testfiler parallelt som separate processer, hvilket muliggør endnu bedre ydelse og et isoleret miljø for hver testfil.

Fordi jeg ikke havde tid til at rette fejl, og jeg kun ville bruge det til mine egne projekter, var det privat. Efter halvandet år lavede jeg endelig et logo til AVA, ryddede repoen, skrev en masse dokumentation. Derefter offentliggjorde jeg projektet.

De fleste af brugerne virker meget glade for AVA, fordi vi hele tiden får positive tweets på projektet. De kan virkelig godt lide, hvor enkel syntaksen er, og hvor let det er at komme i gang. Jeg fik det lige til at ridse min egen kløe, men det viser sig, at andre mennesker havde det samme problem og kunne lide min løsning.

I dag bruger jeg mere tid på at styre projektet, fordi der er så mange nye problemer og trækker anmodninger hver uge, hvilket giver mig meget lidt tid til at kode.

Hvorfor besluttede du at komme ind i MacOS-udvikling?

Jeg lavede en smule Objective-C programmering, men jeg havde ikke en god oplevelse. I januar fik jeg en idé til en Mac-applikation, og jeg havde lidt fritid, så jeg sprang lige ind i Swift. Sådan lærer jeg normalt nye ting. Det er meget spontant. Jeg begynder med et ønske om at fremstille et produkt, så finder jeg ud af, hvilke færdigheder jeg har brug for for at fremstille det produkt, så lærer jeg dem. Ideen kommer inden planlægningen.

Swift er meget sværere at lære oprindeligt end JavaScript, men Swift skinner, fordi det er stærkt skrevet. Når du kompilerer, er det meget mere usandsynligt, at det går ned, hvis du bruger optioner korrekt. Det eneste, jeg ikke kunne lide ved Swift, er, at du stadig nogle gange er nødt til at interagere med de gamle API'er i C.

Jeg skrev et par apps til produktivitet og hjælpeprogrammer. Lungo er en menubjælke-app, som jeg skrev, og du finder den i App Store. Den anden, jeg skrev, er batteriindikator.

Hvad er din plan for næste år? Planlægger du at gå på fuld tid eller overveje andre måder at blive økonomisk bæredygtig på?

Jeg har levet af besparelser i de sidste tre år og lavet open source software. Det er meget lettere i Asien, men det varer ikke evigt. Ideelt set vil jeg gerne have open source på en økonomisk bæredygtig måde, men det er svært, så jeg vil sandsynligvis lave nogle kontrakter næste år.

Jeg har prøvet et par forskellige ting. En ting, jeg gjorde, er at bede om support i GitHub README.md-filen. Jeg ville ikke kalde det en annonce, men mere et lille banner. Jeg tjente en smule penge, men det er langt fra at kunne opretholde mig.

Jeg kan prøve Patreon.

Hvad er nogle af de ting, du ønsker at forbedre i JavaScript-økosystemet?

Efter min mening er JavaScript-økosystemet allerede godt, men vi har stadig mange quirks at arbejde rundt på browsersiden af ​​tingene. Der er så mange projekter med dette gigantiske build-script bare for at få en simpel app derude, det er derfor, jeg elsker Node.js.

Problemet med browsere er, at de er meget komplekse. Du har netværket at tænke på, du skal optimere til både størrelse og ydeevne, du har mange forskellige brugssager, rammer at vælge imellem. Alle forsøger at forenkle det, men så ender du med at blive for meningsfuld, så tilføjer du konfiguration, men der er for meget kedelplade. Jeg kan ikke se en let vej frem, medmindre du løser den aktuelle platform i stedet for at skabe masser af løsninger oven på den. En ting, jeg tror, ​​vil forbedre situationen, er når vi endelig får moduler i browseren. Du har muligvis ikke brug for et byggetrin for alt det.

Hvorfor er JavaScript-udviklere besat af enhjørninger?

Hele ponybevægelsen startede faktisk med Django-samfundet. Når du begyndte at spørge de funktioner, du ønsker, vil udviklere sige "Jeg vil have en hurtigere HTTP-parser" eller "Jeg vil have ORM, der bare fungerer." En dag besvarede en af ​​de centrale devs på Django-postlisten en af ​​funktionsanmodningerne med "nej, du kan ikke have en pony!" Hele enhjørningsbevægelsen startede med den fornægtelse af denne anmodning om funktion.

Der er endda et websted dedikeret til den elskede pony.

Jeg kan ikke huske nøjagtigt, hvordan det spredte sig til JavaScript-fællesskabet. Det var en af ​​de ting, der bare skete alene. At have noget så sjovt og fjollet som enhjørninger hjælper mig med at arbejde igennem programmering og OSS og øger min moral. Det samme gælder dumme gifs.

Jeg udsendte oprindeligt dette interview på Between the Wires, en interviewserie med dem, der bygger udvikler- og designerprodukter.

Dette projekt er muliggjort med sponsorater fra frontendmasters.com, egghead.io, Microsoft Edge og Google Developers.