Suggerimenti per gli sviluppatori full-stack dal creatore della libreria di moduli Redux

A febbraio 2019, il team della community di Toptal ha lanciato una nuovissima iniziativa: un'opportunità mensile per interagire con gli esperti della rete di Toptal in tempo reale. Le sessioni Ask Me Anything (AMA) sono aperte a tutti i membri del core team e della rete di talenti di Toptal: chiunque può porre una domanda. In questo pezzo, abbiamo selezionato domande e risposte selezionate da un AMA con l'esperto di JavaScript e Redux Erik Rasmussen. Erik discute le sfide dello sviluppo di software open source, i suggerimenti per gli sviluppatori e il mondo fluttuante di JavaScript, come affronta la sindrome dell'impostore e il burnout come sviluppatore richiesto e i suoi migliori consigli sui podcast.

Erik è un esperto JavaScript completo con oltre 25 anni di esperienza di sviluppo, specializzato in React, Redux, moduli in React e GraphQL. Su GitHub, un servizio di hosting basato sul Web per il controllo della versione con oltre 28 milioni di utenti, ha ottenuto un posto nella top 100 con oltre 20.000 stelle. È anche l'autore della prima e della terza libreria di moduli più popolari in React: Redux-Form e React-Final-Form.

Redux Form e lo stato del software open source

Perché hai deciso di creare un'altra libreria di moduli dopo l'enorme successo dietro Redux Form?

Ho imparato molte lezioni lungo il percorso con Redux Form e ho acquisito informazioni sulle esigenze degli sviluppatori di React Form in tutto il mondo. Alcuni dei problemi con React Form semplicemente non potevano essere risolti senza dare una nuova occhiata al problema. (Maggiori dettagli qui.)

Molti sviluppatori sognano di creare un progetto open source estremamente popolare. Quali sono alcune delle conseguenze inaspettate (buone e cattive) di avere un progetto di successo come Redux Form?

È estremamente gratificante quando puoi correggere un bug che ha impedito a uno sviluppatore o a un intero team di completare un progetto. È anche davvero fantastico quando le persone trovano e correggono i bug da soli. Finora, le persone sono state molto gentili e cortesi quando hanno chiesto aiuto; Non ho ancora avuto un'interazione con un utente retto che pensa di dovergli una correzione.

Sul lato impegnativo, il burnout è una cosa reale e non abbiamo ancora scoperto un modo per compensare gli sviluppatori OSS per aver dedicato tempo ed energie ai progetti OSS. Redux Form è utilizzato da società da miliardi di dollari in tutto il mondo per effettuare transazioni commerciali e la sua esistenza ha risparmiato migliaia di ore di sviluppo per i team che l'hanno installato, ma non esiste una buona soluzione per dare anche solo un frammento di quei soldi agli autori .

Ci sono soluzioni promettenti in lavorazione per compensare gli sviluppatori open source come te?

Un mio amico ha fondato questa società chiamata CodeFund. Aveva questa idea di "E se potessimo inserire annunci nella documentazione della libreria di codici?" Come sviluppatori, passiamo tutto il giorno a guardare la documentazione ea capire come implementare qualunque cosa stiamo facendo. Inoltre, gli sviluppatori guadagnano molto di più rispetto al tuo navigatore web medio, quindi siamo un potenziale prodotto di lusso.

CodeFund ha avuto l'idea che la documentazione sia davvero un ottimo posto per fare pubblicità. Ero uno dei piloti originali. Ha funzionato abbastanza bene ma hanno riscontrato un problema con GitHub. In origine, stavamo inserendo annunci sul repository GitHub stesso, ma GitHub e gli avvocati sono intervenuti e hanno detto di no. Il che è un peccato. CodeFund ha negoziato con loro per un po', ma alla fine hanno detto di no.

Con una documentazione della biblioteca ben trafficata, puoi ottenere forse $ 150 dollari al mese, il che non sta pagando per quello che vale. Ci sono alcune librerie rare, come Babble o Webpack, in cui vengono dati abbastanza soldi da poter effettivamente supportare due o tre sviluppatori a tempo pieno che lavorano per migliorare quella cosa. Babble e Webpack: miliardi e miliardi di dollari di aziende sono seduti sulla loro infrastruttura e, di sicuro, Redux Form li supporta.

In quasi tutti i siti Web che visiti, puoi guardare nel codice sorgente e puoi vedere del codice che è stato scritto da una persona in particolare che non viene adeguatamente compensata. È necessario aumentare la consapevolezza per far sì che le persone apprezzino maggiormente cosa sia l'open source e le ore che alcuni di noi dedicano.

Perché creare qualcosa che sia open source e gratuito? Qual è l'incentivo per gli sviluppatori come te?

Il motivo per cui lo crei è perché ne hai bisogno per qualunque cosa su cui stai lavorando in questo momento. Quando lo rilasci, gli altri vengono e lo migliorano. Il sogno open source è che dici: "Ho costruito una piccola carriola che mi aiuta a portare le mie pietre da qui a là", e poi arriva qualcuno e lo migliorano. Nel tuo prossimo progetto, torni indietro e usi la stessa libreria e pensi: "Whoa, questa cosa si muove molto più velocemente. Ora va meglio."

È anche molto gratificante. Mi viene un colpo di dopamina quando la gente dice: "Questo ci ha tenuto in piedi per tre settimane e questa piccola soluzione che ti ha richiesto tre ore per fare ci ha risparmiato tre settimane di tempo". C'è un po' di un ciclo di dipendenza con quello, in cui ottieni un rinforzo positivo e ti senti semplicemente bene.

Con la mia seconda libreria di moduli, non era tanto che la gente dicesse: "Ehi, vogliamo un'altra libreria di moduli", ma solo che ho pensato a un modo per migliorarla.

È una specie di sogno sul perché lo fai. Ma non è certo per i soldi.

In un mondo ideale, quanto compenso riceveresti per la creazione di software open source? Solo qualche ciliegina sulla torta?

Non mi dispiacerebbe se qualcuno mi pagasse sei cifre solo per lavorare sull'open source tutto il giorno. Se guardi il valore generato rispetto al costo, il rapporto per l'open source è così alto. Si arriva a piccole librerie che fanno una cosa, e una cosa davvero, davvero bene.

Se ogni azienda nel mondo dovesse assegnare il proprio team di sviluppatori per farlo, i risultati varierebbero ampiamente. Il fatto che abbiamo l'open source e possiamo avere una soluzione a questo - una bolla di algoritmo in cima che è la migliore - significa che tutti nel mondo hanno quell'efficienza incorporata.

Un altro valore dell'open source è che se stai usando qualcosa che hai scritto e solo la tua azienda lo sta usando. . . confrontalo con qualcosa che stanno utilizzando 1.000 aziende. Hanno trovato ogni singolo piccolo angolo e fessura dello spazio dei bug che potrebbe potenzialmente essere un problema, e lo prendi e lo colleghi alla tua cosa: sei d'oro. Avrai molta più fiducia in questo.

Il mondo dinamico di JavaScript

Essendo stato nello spazio JavaScript per così tanto tempo, devi aver visto così tanti nuovi framework [per la creazione di applicazioni JavaScript] andare e venire. Come si fa a tenere sotto controllo il settore in modo da poter decidere su quali framework impegnarsi?

Devi farti un'idea dei venti della comunità di sviluppatori. L'attuale battaglia tra TypeScript e Flow è un ottimo esempio. Inizialmente ho scelto il cavallo sbagliato in quella gara, supponendo che Facebook sarebbe stato un miglior amministratore di un framework di digitazione. Ma penso che TS abbia praticamente vinto quella battaglia, e ora sto lentamente migrando le cose in quella direzione.

C'è un angolo di Twitter che è il "Twitter degli sviluppatori". Se segui abbastanza persone, forse hai bisogno di un campione di un centinaio di persone, puoi avere un'idea di dove soffiano i venti e cosa sta diventando popolare. Riceverai molti post come "Uso la libreria A, ma ho appena imparato a conoscere la libreria B e tutto è molto più semplice". Ne hai abbastanza e dici: "Beh, forse dovrei dare un'occhiata a quest'altra libreria".

Le tendenze vanno e vengono nello spazio JavaScript. Sarà sempre in movimento?

Penso (e spero) che continuerà ad evolversi. La stagnazione è la morte nella tecnologia. Anche Java sta innovando in modo significativo in questo momento: le cose che puoi fare in Java 10 non sono per niente come Java 6 di tua nonna.

Può essere estenuante creare finalmente la tua app con Tech X solo per vedere che tutti i ragazzi fantastici ora usano Tech Y. Ma questo è il settore in cui ci troviamo.

Secondo te, quali concetti JavaScript sono particolarmente importanti da comprendere per acquisire padronanza del linguaggio?

Direi che la programmazione funzionale e l'idea di passare le funzioni in giro è piuttosto importante. Soprattutto se provieni da un linguaggio come Java o C++.

Pensi che React debba essere utilizzato per la creazione di SPA [applicazioni a pagina singola] o solo per i componenti in una pagina normale?

Questa è la bellezza di React: è così versatile. Ho introdotto lentamente React per tutte le nuove funzionalità in una vecchia app Java/jQuery durante il mio lavoro quotidiano. React funziona bene dato un nodo DOM su cui agire. Non è necessario che abbia il controllo dell'intera app.

Quando avvii una nuova app React, quali sono gli strumenti e le librerie che usi regolarmente da zero?

Penso che create-react-app sia il chiaro vincitore in questo momento. Quattro anni fa, quando non c'era niente del genere, era molto più difficile.

Come gestisci lo stato delle app nelle tue app di reazione?

Quando è uscito Redux, è stata chiaramente la risposta. Tuttavia, ho scoperto che gran parte del mio "stato" Redux era roba come loading e listOfObjects , e più recentemente ho utilizzato Apollo GraphQL per quella roba. Altre cose come isSideNavOpen possono essere gestite abbastanza facilmente con componenti basati sul contesto. Detto questo, ci sono ancora alcuni casi d'uso legittimi per Redux, ma nessuno in cui mi sono imbattuto nelle mie semplici app React.

Qual è il tuo editor/IDE preferito?

Ah, che domanda!

Vengo da Java e sono stato molto contento di JetBrains IntelliJ per molti anni, ma è un po' lento per JS. Per prima cosa sono andato su Atom, ma alla fine ho optato per VS Code. Le sue integrazioni per Jest e Flow e TypeScript sono imbattibili.

Qual è la tua opinione sullo sviluppo isomorfo come l' opal che traduce ruby ​​in JS e quindi apre la strada a Rubysts per scrivere app strutturate React/Flux in Pure Ruby (senza scrivere JS)?

Il fatto che JavaScript sia passato al server, penso, sia un grosso problema. Essere in grado di eseguire il rendering con lo stesso codice sia sul client che sul server è enorme e molto probabilmente la via del futuro.

Quale pensi sia il problema più grande dei nostri attuali framework JS più popolari?

Non sono del tutto sicuro, ma mi piace molto la direzione di css-in-js, serverless e SSR che aziende come Zeit stanno perseguendo con Next.js.

È davvero divertente per me, come qualcuno che costruiva siti Web alla fine degli anni '90, che torniamo ai siti Web statici. Torneremo a generare tutto in fase di compilazione, quindi hai le tue cose statiche sul server e quindi puoi aggiungere cose dinamiche con ciò che chiamano reidratazione. Dopo aver eseguito il rendering dell'intera pagina, puoi ottenere il JavaScript aggiuntivo per animare effettivamente le cose e spostare i componenti.

Zeit, con il loro framework Now, supporta anche la creazione statica sul tuo sito Web, perché niente è più veloce del download di un file HTML statico. È solo un file di testo e poi boom, hai capito. Mentre se stai colpendo un server, deve colpire un database forse quattro o cento volte solo per costruire qualunque sia la pagina che devi visualizzare. È super lento.

L'idea statica sta guadagnando popolarità.

Ritieni che JavaScript possa assumere linguaggi "maturi" (come Java e C++) e diventare il linguaggio preferito dalle aziende?

Decisamente. Le cose che le persone stanno facendo ora con il nodo "serverless" sono estremamente scalabili e penso che le API aziendali [interfacce di programmazione delle applicazioni] possano e saranno riscritte in JavaScript, almeno dalle aziende più agili e lungimiranti.

Cosa dovrebbe cercare uno sviluppatore in un client?

Vuoi che ti venga dato un livello di fiducia e autonomia, supponendo che tu sia abbastanza anziano da meritarlo. Non vorrei accettare un lavoro in cui qualcuno mi guardava continuamente alle spalle. Molto tempo, con il lavoro di sviluppo, puoi avere qualcosa che richiede cinque minuti per essere risolto, ma trascorri quattro ore a lavorare su qualche piccolo problema con la build che lo rende in modo da non poterlo effettivamente testare. Ci sono molte volte in cui trascorro otto o dieci ore su un problema - dove sto davvero lavorando, davvero concentrato per tutto il tempo - e la soluzione effettiva è come due righe di codice. Vuoi un datore di lavoro che abbia quel livello di comprensione di come è il tuo lavoro.

Sulla sindrome dell'impostore, il burnout e lo stress

La sindrome dell'impostore sembra essere un fenomeno non raro tra gli sviluppatori. Lo sperimenti e, se sì, come lo affronti?

Assolutamente. Soprattutto quando si parla a una conferenza. (O fare un AMA?)

Quando si tratta di insegnamento/mentoring, devi renderti conto che sai di più su ciò che fai rispetto al mese scorso. Ergo, ci sono sempre persone che sono tornate dove eri e che potrebbero trarre vantaggio dalle tue conoscenze.

È anche importante poter dire: "Non lo so, indaghiamo insieme" (anche un buon consiglio per genitori).

Com'è un giorno della tua vita? Come si pianifica tutto in modo da non lavorare 100 ore a settimana e bruciare?

Quando sono stato davvero in profondità nell'open source, ci vuole molto più tempo; a volte, devo ritirarmi per un mese o giù di lì alla volta. Porto i miei figli a scuola e poi passo il tempo a guardare che tipo di problemi stanno avendo le persone. Se sono davvero seri, allora dedico un po' di impegno cercando di rimediare o di rispondere in modo utile.

Ho un lavoro quotidiano che non è affatto correlato all'open source, il che richiede molto del mio tempo. Per tutto il giorno, ho impostato le notifiche in modo da poter vedere se c'è un problema serio con qualcosa. Se è stata rilasciata una nuova funzionalità o qualcosa del genere, è più probabile che ci siano bug in quel periodo.

Ho imparato che chiunque stia scrivendo i requisiti per un progetto è certo che: "Questo avrebbe dovuto essere fatto ieri, quindi perché non è stato ancora fatto?" Ho avuto così tante volte in cui il team che riceve il mio lavoro impiega tre settimane per metterlo effettivamente in produzione. E tu dici: "Beh, a cosa serviva tutto quello stress?"

Se un'attività deve essere eseguita entro venerdì e ciò finisce per essere eseguita entro il venerdì successivo, l'attività non si chiude quasi mai perché hai fallito. Quando sei giovane e non sai niente di meglio, ti senti come "Oh mio dio, dobbiamo tirarlo fuori dalla porta". Ma dopo che l'hai fatto abbastanza volte, e vedi: "Aspetta un minuto, quello che ci dicevano non era proprio vero", puoi dire: "Va bene, sì. Qualunque. Verrà fatto quando sarà finito".

Ero un po' esausto lo scorso ottobre quando React ha annunciato questa cosa chiamata React Hooks. Se fossi stato lì, pronto ad affrontare qualsiasi cosa nuova e a correre con essa, avrei potuto ottenere molti chilometri dall'essere una delle prime persone a entrare in React Hooks. Sto tenendo d'occhio quella che potrebbe essere la prossima grande cosa.

Cosa fai nel tempo libero per ridurre lo stress?

Faccio passeggiate e ascolto podcast che non riguardano lo sviluppo.

Qualcuno che potresti consigliare?

Gli unici veri podcast tecnologici che ascolto sono The Undefined Podcast, che tratta solo tangenzialmente di suggerimenti tecnici e per sviluppatori. Ascolto anche React Podcast, sul quale apparirò presto (si spera che abbia un senso, a seconda della qualità del loro editor).

Guardando il mio pod-catcher preferito, Overcast, i miei podcast con la priorità assoluta includono:

• Roderick sulla linea
• Avere un significato
• Podcast di tecnologia accidentale
• Lavori stradali
• Esponente
• Ciao Internet
• Radiolab
• Rispondi a tutti

Di recente, in realtà ho avviato io stesso due podcast:

Il primo si chiama Seek Justice, in cui io, una persona moderatamente intelligente che non sa quasi nulla del sistema di giustizia penale, intervista un mio amico che ha trascorso tutta la sua carriera esaminandolo e lavorando per riformarlo. Sta lavorando direttamente con i governatori di diversi stati degli Stati Uniti per ridurre la popolazione carceraria e la recidiva dopo il rilascio. Non è un argomento a cui sono mai stato veramente interessato, ma il mio co-conduttore mi affascina in ogni episodio.

Il secondo è uno spettacolo di pura stupidità, chiamato Happy Hour con Dennis ed Erik, in cui io e lo stesso amico prendiamo qualche drink serale, parliamo delle nostre vite e ci facciamo ridere a vicenda. Seek Justice è per il tuo viaggio al lavoro con gli occhi brillanti e Happy Hour è per il tuo rilassante viaggio verso casa.

Per riportarlo allo sviluppatore, i miei sforzi nei podcast mi hanno aiutato a risolvere un problema per il quale non riuscivo a trovare una soluzione nel settore: un semplice lettore MP3, con copertine degli album, che funzionava anche come una scheda Twitter. Così ho scritto AudioCard.