Between the Wires: Un interviu cu dezvoltatorul open source Sindre Sorhus

Iată interviul meu Sindre Sorhus, un prolific dezvoltator open source care trăiește în Thailanda.

Povestește-ne puțin despre copilăria ta și unde ai crescut.

Am crescut într-o zonă suburbană din afara Oslo, Norvegia. Când eram mic, eram foarte interesat de Legos. În fiecare an primeam Legos de ziua de naștere și de Crăciun. Legosul mi-a stârnit cu adevărat interesul de a construi lucrurile de la început. La un moment dat, am avut un imens oraș Lego încorporat în camera mea și aproape că a ocupat întreaga cameră.

Cum ai intrat în programare?

Când aveam șapte ani, familia mea a primit primul computer Windows 95. Obișnuiam să joc un joc numit Map Blaster în care personajul sărea să rezolve probleme de matematică. Câțiva ani mai târziu am obținut în sfârșit acces la internet și mi-a schimbat totul. Am petrecut mult timp scriind în cărți de oaspeți pe paginile web ale altor persoane și strângând gif-uri. Într-o zi, am devenit curios despre modul în care a funcționat site-ul web și am descoperit butonul „vizualizează sursa” din browser.

Aceasta a fost o descoperire minunată pentru mine. Aș putea face clic dreapta, vizualiza sursa și apoi am putut vedea cum s-a făcut totul. Nu am înțeles mare lucru la început, dar în timp ce mă uitam la același lucru mereu, am început să înțeleg cum funcționează. Așa mi-am început călătoria de programare.

Am făcut primul meu site web când aveam zece ani. A fost după ce a privit sursa de câțiva ani. Avea tot felul de culori, un fundal cu model de stea, animat cu muzică de fundal media - era una dintre acele atingeri pe care toată lumea le avea pe site-urile lor de atunci. Am folosit Microsoft FrontPage.

Odată, m-am plictisit, așa că am creat mii de directoare imbricate pe computerul tatălui meu și a ajuns să se prăbușească computerul. Tatăl meu a trebuit să reformateze computerul; era impresionat și enervat în același timp. Așa am pierdut și primul meu site web.

Mai târziu, în timpul anului școlar, am intrat în jocuri Flash și am urmărit o mulțime de filme Flash în timpul pauzelor școlare. Am fost curios cum au fost făcute, dar nu a existat niciodată un buton sursă. Așa că am decompilat fișierele swiff, ceea ce a fost ușor, deoarece nu au fost confundate. Asta, din nou, mi-a oferit ocazia să învăț din munca altora. Am început să modific jocurile altor oameni și am refăcut toate personajele, am făcut noi dușmani, am adăugat scoruri mari. A fost un moment mândru când mi-am dat seama că alții puteau juca de fapt un joc pe care îl lipisem.

Ați petrecut cinci ani în armată ca dezvoltator și fotograf. Cum era dezvoltarea web pe vremea aceea?

După absolvirea liceului, am fost înrolat direct în armata din Norvegia. Am intrat în unitatea media unde mi-am petrecut cea mai mare parte a timpului în birou lucrând la intranet. Nu era mare lucru de făcut seara pentru că locuiam în cazarmă, așa că am decis să construiesc lucruri. Dar cea mai mare parte a experienței mele a fost copierea și lipirea PHP și JavaScript a altor persoane și nu prea am înțeles cum funcționau. Într-o zi, am dat peste Python și Django, avea o documentație excelentă și tutoriale pe care PHP nu le-a avut niciodată. Aș citi tutoriale în fiecare zi și am început să construiesc lucruri la locul de muncă.

Așa a început codarea mea efectivă. După recrutare, am plănuit să călătoresc înainte de facultate. Dar am primit o ofertă de muncă de la o unitate din armată numită Unitatea de Apărare Cibernetică. A fost interesant, așa că am luat oferta și am ajuns să petrec 5 ani acolo.

Cum v-ați implicat în TodoMVC și Yeoman?

Am început să folosesc GitHub în jurul anului 2011, dar mai ales ca consumator. M-aș întoarce, uitându-mă la diferite repere și jucându-i în rolurile principale pentru că păreau distractive. Am remediat câteva greșeli de tipar în fișierele README.md, dar cam atât a fost.

Într-o zi am dat peste TodoMVC, care vă ajută să selectați un cadru JavaScript. A fost o idee cu adevărat minunată, deși, în retrospectivă, avem nevoie de aplicații mult mai avansate pentru a rezolva de fapt problemele testării performanței și a capabilităților cadrului. Primul lucru pe care mi l-am amintit despre TodoMVC a fost că avea un logo frumos. Pare foarte superficial, dar asta m-a determinat să încep.

Mi-a plăcut atât de mult sigla, încât am decis să mă uit mai mult în jur. Am observat că nu prea au o aplicație jQuery, așa că am decis să creez una. Am trimis o cerere de extragere în weekend și am primit un răspuns de la Addy Osmani, care este întreținătorul proiectului. Mi-a fuzionat rapid PR-ul, ceea ce a fost o experiență super drăguță pentru un începător ca mine. M-am simțit bine că aplicația mea a fost acum inclusă în acest proiect foarte popular. Am făcut asta câteva săptămâni, iar Addy m-a adăugat la proiect, care a fost foarte interesant.

Acest lucru m-a interesat cu adevărat de open source. Înainte de asta, eram doar un consumator pasiv, dar cu TodoMVC am avut gustul de a menține un proiect mare, care era mult de lucru. Dar am învățat multe din această experiență.

Câteva luni mai târziu, Addy a plecat la serviciu pentru Google. Primul său proiect la Google a fost Yeoman, un instrument de schele pentru aplicații web moderne. Deoarece am lucrat atât de bine împreună la TodoMVC, așa că a decis să mă invite ca colaborator extern.

Scopul nostru inițial cu Yeoman a fost să creăm un set de instrumente pe care toată lumea le poate folosi pentru a crea aplicații web excelente. Ceea ce nu ne-am dat seama atunci este că este imposibil să rezolvăm problema tuturor într-un singur instrument, deoarece pe web există doar prea multe cazuri de utilizare. Yeoman a devenit o configurație populară pe care mulți dezvoltatori au creat generatoare pentru a extinde Yeoman care se potrivesc propriilor lor cazuri de utilizare.

Istoria se repetă la fel de bine dacă te uiți la aplicația Create React sau Webpack. Cineva începe să facă acest produs care ar trebui să rezolve o problemă, dar pentru că toată lumea are nevoi diferite, apar probleme. Când vă dați seama că acest instrument nu poate acoperi totul, adăugați configurația. Cheia este să ai o abordare echilibrată. Trebuie să spui „Nu” și trebuie să știi când să spui „Nu”. Puteți dezamăgi unii utilizatori deoarece au cazuri de utilizare obscure. Aceasta este partea dificilă a realizării instrumentelor și este și mai dificilă în proiectele open source, deoarece există atât de multe feedback-uri.

De ce ești pasionat de open source?

Îmi place open source și cred că revine la butonul „View Source” din browser. În opinia mea, open source este cel mai eficient mod de a construi software, deoarece ne permite să ne bazăm pe munca celuilalt. Toată lumea beneficiază dacă o persoană rezolvă o problemă grea. Open source îmi permite să lucrez cu oameni incredibili din întreaga lume cu care nu aș fi fost în stare să lucrez altfel. Începem să lucrăm la ceea ce contează pentru noi și să ne concentrăm asupra a ceea ce are nevoie comunitatea în loc să ne concentrăm pe generarea de venituri.

Paul Irish are un videoclip extraordinar pe YouTube, intitulat „Zece lucruri pe care le-am învățat de la sursa jQuery”. Asta m-a interesat să citesc codul sursă jQuery. Paul Irish avea dreptate, înveți multe făcând de fapt tot ce vrei să înveți cum să faci.

Ce zici de sustenabilitatea open source?

Acesta este cu siguranță un punct de conflict la care m-am gândit foarte mult recent. Am făcut open source cu normă întreagă de aproximativ trei ani. Nu câștig bani, dar ar fi frumos să fac acest lucru cu normă întreagă ca pe o slujbă plătită. Vue.js de Evan You este un exemplu excelent al modului în care durabilitatea open source poate funcționa. El a creat un cadru dorit de toată lumea și a fost folosit de destul de multe companii. Alte companii și persoane fizice au stimulente pentru a investi în proiectul său, deoarece este util în producție. Cheia este de a face proiectul dvs. de încredere. Personal, nu cred că contribuțiile indivizilor sunt suficiente pentru a susține un proiect.

M-am gândit să folosesc Open Collective, astfel încât să putem colecta bani pentru a recompensa contribuitorii și promoțiile la evenimente. Webpack a făcut o treabă grozavă acolo. De fapt, m-am împotrivit mult timp, pentru că eram îngrijorat că vor exista așteptări ca noi să facem schimbări nedorite ori de câte ori cineva pune bani pentru proiect. De obicei, dacă o companie investește într-un proiect, își doresc ca lucrările să fie prioritare și problemele să fie rezolvate rapid.

În prezent locuiesc în Thailanda și cred că aș fi bine cu mai puțin de 1500 de dolari.

Aveți peste 1000 de pachete npm. Cum rămâi atât de productiv?

Aceasta este o concepție greșită. Oamenii văd numărul 1000 de pachete și cred că sunt extrem de productiv, dar ceea ce nu realizează este că majoritatea acestor pachete sunt mici și modulare. S-au terminat cam când sunt publicate. Îmi place să compar programarea cu construcția cu Lego: creez o mulțime de cărămizi Lego care pot fi asamblate pentru a construi construcții mai mari. Le folosesc cu alte pachete înainte de a publica pentru a mă asigura că îmi rezolvă problemele. De aceea, utilizatorii nu ar trimite o mulțime de cereri de caracteristici, deoarece sunt atât de mici. Dacă au nevoie de ceva mai mult, pot construi un alt modul. 90% din timpul meu îl petrec pe cele mai mari 10 proiecte ale mele.

Care este un sfat pe care îl puteți oferi noilor colaboratori OSS atunci când aveți de-a face cu persoane exigente și toxice?

De șase ani fac open source, așa că am dezvoltat o piele groasă. Nu cred că mă mai deranjează nimic pentru că îmi place să cred că am trăit totul. Vorbesc cu o mulțime de începători care au o anumită toxicitate și apoi renunță. Open source-ul ar trebui să fie un lucru distractiv pe care îl faci, nu o cauză de stres în viața ta.

Sfatul meu pentru noii dezvoltatori este că nu trebuie să lăsați străinii de pe internet să vă afecteze negativ starea de spirit sau unitatea. Nu merită. Dacă aveți opțiunea de a vă îndepărta, luați-o - utilizați butonul de dezabonare. Întreținătorii open source trebuie să rețină că utilizatorii nu plătesc clienți. Le oferim ceva gratuit, în timpul nostru liber.

Cu oamenii toxici, trebuie să fii întotdeauna persoana mai mare. Sună greșit, dar ceea ce încerc să fac este să-i ucid cu bunătate. Cumva a funcționat pentru mine de mulți ani. De exemplu, dacă cineva este enervant, voi încerca să fiu la fel de deschis și amabil în legătură cu situația. Mă asigur să nu fiu niciodată sarcastic sau să vorbesc cu ei. Trolii se hrănesc cu supărarea și discursul tău, așa că, atunci când nu este acolo, te vor lăsa în pace.

Folosesc opțiunea de mutare oriunde este furnizată, în special pe Twitter. Este bine să ne dăm seama exact când cineva se învecinează cu toxicitatea și este mult mai bine să închidem pur și simplu vocea și intrarea în loc să provocăm conflicte inutile.

Ați proiectat câteva sigle pentru propriile module, sunt minunate. Cum ai învățat designul?

Am început urmând tutoriale online pentru a face efecte interesante. Obișnuiam să folosesc Adobe Illustrator, dar acum folosesc Sketch.

Este foarte distractiv pentru mine să proiectez și cred că ar trebui să încerce mai mulți programatori. După programarea de ore întregi, este bine să faci o pauză pentru a face o muncă creativă într-un alt mod.

De asemenea, beneficiază proiectele mele prin crearea de sigle, deoarece conferă proiectului mai multă personalitate. De obicei, când introduceți o repo pe GitHub, primiți aceleași lucruri bazate pe text: un antet, o introducere și README.md. Este frumos să-l condimentezi cu niște grafice. Se pare că este mai probabil ca oamenii să folosească proiectul dacă există un logo. De exemplu, Vadim Demedes, un dezvoltator din Ucraina, a depus această cerere de extragere imediat după lansarea AVA. Vadim a devenit ulterior membru al echipei AVA. Mi-a spus că s-a interesat de AVA datorită logo-ului său frumos.

Ce v-a determinat să vă mutați în Thailanda? Spuneți-ne cum arată o zi tipică pentru dvs.

Nu prea știam prea multe despre Thailanda. Când am lucrat în serviciul militar obligatoriu, am planificat să călătoresc. Am primit o ofertă și am ajuns să rămân încă patru ani. Tocmai am mers cu fluxul, pentru că viața se întâmplă.

Într-o zi, când pregăteam un interviu telefonic cu Google, am decis doar că, dacă voi călători vreodată, va fi acum, altfel, nu se va întâmpla niciodată. Așa că am anulat interviul și mi-am prezentat demisia la locul de muncă a doua zi. Am cumpărat un bilet dus pentru Thailanda și asta a fost.

Am făcut rucsacuri timp de o jumătate de an în Asia de Sud-Est și acolo am întâlnit-o pe prietena mea. M-am stabilit în cele din urmă în Thailanda pentru că era preferatul meu. Îmi place cultura bogată, localnicii prietenoși și mâncarea. Locuiesc în Thailanda de doi ani acum.

Lucrez în cafenelele locale trei zile pe săptămână pentru că sunt mai productiv când am oameni în jurul meu. În caz contrar, de la nouă la șase fac o mulțime de codificare și întreținere open source, uneori proiectele mele secundare. În majoritatea zilelor, primesc mai mult de 20 de cereri de extragere și multe probleme de rezolvat. Seara, petrec timpul cu prietena mea Im; amândoi ne place mâncarea picantă de stradă pe piețele de noapte. Uneori, apelurile de serviciu și mă regăsesc în fața computerului noaptea târziu.

Nu am învățat limba thailandeză pentru că, deși mă pricep la limbaje de programare, limbajul vorbit este mult mai greu decât orice limbaj de programare, iar thailandezul este deosebit de greu. Iubita mea, pe de altă parte, vorbește fluent thailandeză, rusă, engleză și destul de bună la suedeză. La un moment dat, vreau să învăț thailandezul și alte limbi, dar nu sunt presat de timp.

Ce v-a motivat să începeți proiectul AVA?

Foloseam Mocha mult pentru că am făcut o mulțime de module care trebuiau testate. Nu am fost foarte mulțumit de modul în care a funcționat. Mocha injectează unele obiecte globale, dar acestea nu sunt definite nicăieri. Deoarece o făceam în Node.js, aveam o mulțime de API-uri asincronizate și nu era foarte convenabil să fac cu Mocha.

Am vrut ceva mai simplu și mai optimizat pentru cazul meu de utilizare. Așadar, într-un weekend, am decis să lucrez la el și până duminică seara am publicat versiunea 0.0.1 pentru AVA pe npm. Chiar dacă JavaScript are un singur fir, IO în Node.js se poate întâmpla în paralel datorită naturii sale asincronizate. AVA profită de acest lucru și rulează testele simultan, ceea ce este deosebit de benefic pentru testele grele IO. În plus, fișierele de testare sunt rulate în paralel ca procese separate, ceea ce permite o performanță potențial mai bună și un mediu izolat pentru fiecare fișier de testare.

Deoarece nu am avut timp să remediez bug-urile și am vrut să îl folosesc doar în propriile proiecte, a fost privat. După un an și jumătate, am făcut în cele din urmă o siglă pentru AVA, am curățat repo, am scris o mulțime de documentație. Apoi, am publicat proiectul.

Majoritatea utilizatorilor par foarte mulțumiți de AVA deoarece primim tot timpul tweet-uri pozitive la proiect. Le place foarte mult cât de simplă este sintaxa și cât de ușor este să începeți. Tocmai am reușit să-mi zgârie pruritul, dar se pare că alți oameni au avut aceeași problemă și le-a plăcut soluția mea.

În zilele noastre, îmi petrec mai mult timp în gestionarea proiectului, deoarece sunt atât de multe probleme noi și cereri de extragere în fiecare săptămână, ceea ce îmi lasă foarte puțin timp pentru codificare.

De ce ați decis să intrați în dezvoltarea macOS?

Am făcut puțin programarea Objective-C, dar nu am avut o experiență grozavă. În ianuarie anul acesta, mi-a venit o idee pentru o aplicație Mac și am avut ceva timp liber, așa că am sărit direct în Swift. Așa învăț de obicei lucruri noi. Este foarte spontan. Încep cu dorința de a crea un produs, apoi îmi dau seama ce abilități am nevoie pentru a face acel produs, apoi le învăț. Ideea vine înainte de planificare.

Swift este mult mai greu de învățat inițial decât JavaScript, dar Swift strălucește deoarece este puternic tastat. Când compilați, este mult mai puțin probabil să se blocheze dacă utilizați opțional corect. Singurul lucru care nu mi-a plăcut la Swift este că uneori trebuie încă să interacționați cu vechile API-uri din C.

Am scris câteva aplicații de productivitate și utilitate. Lungo este o aplicație pentru bara de meniu pe care am scris-o și o găsiți în App Store. Celălalt pe care l-am scris este Indicatorul bateriei.

Care este planul tău pentru anul viitor? Aveți de gând să mergeți cu normă întreagă sau să luați în considerare alte modalități de a deveni sustenabil financiar?

Trăiesc din economii în ultimii trei ani și fac software open source. Acest lucru este mult mai ușor în Asia, dar nu durează pentru totdeauna. În mod ideal, aș dori să fac open source într-un mod durabil din punct de vedere financiar, dar este dificil, așa că probabil voi face niște contracte anul viitor.

Am încercat câteva lucruri diferite. Un lucru pe care l-am făcut este să cer asistență în fișierul GitHub README.md. Nu l-aș numi un anunț, ci mai degrabă un banner mic. Am câștigat un pic de bani, dar este departe de a mă putea susține.

S-ar putea să-l încerc pe Patreon.

Care sunt unele dintre lucrurile pe care doriți să le îmbunătățiți în ecosistemul JavaScript?

În opinia mea, ecosistemul JavaScript este deja grozav, dar avem încă o mulțime de ciudățenii de rezolvat din partea browserului. Există atât de multe proiecte cu acest script de construcție gigant doar pentru a obține o aplicație simplă acolo, de aceea îmi place Node.js.

Problema browserelor este că acestea sunt foarte complexe. Aveți rețeaua la care să vă gândiți, trebuie să vă optimizați atât pentru dimensiune, cât și pentru performanță, aveți o mulțime de cazuri de utilizare diferite, cadre pentru a alege. Toată lumea încearcă să o simplifice, dar apoi ajungi să fii prea opinionat, apoi adaugi configurație, dar există prea mult boilerplate. Nu văd o cale ușoară înainte decât dacă remediați platforma reală în loc să creați o mulțime de soluții deasupra. Un lucru care cred că va îmbunătăți situația este când vom primi în sfârșit module în browser. Este posibil să nu aveți nevoie de un pas de construcție pentru toate atunci.

De ce dezvoltatorii JavaScript sunt obsedați de unicorni?

Întreaga mișcare a poneilor a început cu comunitatea Django. Când ați început să întrebați funcțiile pe care le doriți, dezvoltatorii vor spune „Vreau un parser HTTP mai rapid” sau „Vreau ORM care funcționează doar”. Într-o zi, unul dintre principalii dezvoltatori de pe lista de discuții Django a răspuns la una dintre cererile de caracteristici cu „nu, nu poți avea ponei!” Întreaga mișcare a unicornului a început cu refuzul solicitării acestei caracteristici.

Există chiar și un site web dedicat poneiului drăguț.

Nu-mi amintesc exact cum s-a răspândit în comunitatea JavaScript. A fost unul dintre acele lucruri care tocmai s-au întâmplat de la sine. A avea ceva la fel de distractiv și prostesc ca unicornii mă ajută să lucrez prin programare și OSS și îmi crește moralul. Același lucru este valabil și pentru gifurile prostești.

Am postat inițial acest interviu pe Between the Wires, o serie de interviuri cu cei care construiesc produse pentru dezvoltatori și designeri.

Acest proiect este posibil cu sponsorizări de la frontendmasters.com, egghead.io, Microsoft Edge și Google Developers.