Conseils de développeur full-stack du créateur de la bibliothèque de formulaires Redux

En février 2019, l'équipe communautaire de Toptal a lancé une toute nouvelle initiative : une opportunité mensuelle d'interagir avec les experts du réseau de Toptal en temps réel. Les sessions Ask Me Anything (AMA) sont ouvertes à tous les membres de l'équipe principale et du réseau de talents de Toptal - tout le monde peut poser une question. Dans cet article, nous avons sélectionné des questions et réponses d'un AMA avec l'expert JavaScript et Redux Erik Rasmussen. Erik discute des défis du développement de logiciels open source, des conseils aux développeurs et du monde fluctuant de JavaScript, de la façon dont il traite le syndrome de l'imposteur et l'épuisement professionnel en tant que développeur en demande, et de ses principales recommandations de podcast.

Erik est un expert JavaScript full-stack avec plus de 25 ans d'expérience en développement, spécialisé dans React, Redux, les formulaires dans React et GraphQL. Sur GitHub, un service d'hébergement Web pour le contrôle de version avec plus de 28 millions d'utilisateurs, il a obtenu une place dans le top 100 avec plus de 20 000 étoiles. Il est également l'auteur des première et troisième bibliothèques de formulaires les plus populaires dans React : Redux-Form et React-Final-Form.

Formulaire Redux et état des logiciels open source

Pourquoi avez-vous décidé de créer une autre bibliothèque de formulaires après l'énorme succès de Redux Form ?

J'ai appris de nombreuses leçons en cours de route avec Redux Form et j'ai eu un aperçu des besoins des développeurs React Form à travers le monde. Certains des problèmes avec React Form ne pouvaient tout simplement pas être résolus sans jeter un nouveau regard sur le problème. (Plus de détails ici.)

De nombreux développeurs rêvent de créer un projet open source massivement populaire. Quelles sont certaines des conséquences inattendues (bonnes et mauvaises) d'avoir un projet aussi réussi que Redux Form ?

C'est extrêmement gratifiant de pouvoir corriger un bogue qui a empêché un développeur ou toute une équipe de terminer un projet. C'est aussi vraiment génial quand les gens trouvent et corrigent les bogues eux-mêmes. Jusqu'à présent, les gens ont été très gentils et courtois lorsqu'ils ont demandé de l'aide ; Je n'ai pas encore eu d'interaction avec un utilisateur vertueux qui pense que je lui dois une solution.

Du côté des défis, l'épuisement professionnel est une réalité et nous n'avons pas encore découvert de moyen de récompenser les développeurs OSS pour avoir consacré leur temps et leur énergie aux projets OSS. Redux Form est utilisé par des sociétés d'un milliard de dollars dans le monde entier pour effectuer des transactions, et son existence a permis d'économiser des milliers d'heures de développement pour les équipes qui l'ont installé, mais il n'y a pas de bonne solution pour donner ne serait-ce qu'un peu de cet argent aux auteurs. .

Existe-t-il des solutions prometteuses en cours pour rémunérer les développeurs open source comme vous ?

Un de mes amis a lancé cette société appelée CodeFund. Il a eu cette idée de "Et si nous pouvions mettre des publicités sur la documentation de la bibliothèque de code ?" En tant que développeurs, nous passons toute la journée à consulter la documentation et à trouver comment implémenter tout ce que nous faisons. De plus, les développeurs gagnent beaucoup plus d'argent que votre internaute moyen, nous sommes donc un potentiel de produit de luxe.

CodeFund a eu l'idée que la documentation est un très bon endroit pour faire de la publicité. J'étais l'un des premiers pilotes. Cela a plutôt bien fonctionné mais ils ont rencontré un problème avec GitHub. À l'origine, nous mettions des publicités sur le référentiel GitHub lui-même, mais GitHub et les avocats se sont précipités et ont dit non. Ce qui est dommage. CodeFund a négocié avec eux pendant un certain temps, mais à la fin ils ont dit non.

Avec une documentation de bibliothèque bien achalandée, vous pouvez gagner peut-être 150 dollars par mois, ce qui ne paie pas pour ce que ça vaut. Il y a quelques rares bibliothèques, comme Babble ou Webpack, où il y a suffisamment d'argent qui leur est accordé pour qu'elles puissent réellement prendre en charge deux ou trois développeurs à plein temps travaillant pour améliorer cette chose. Babble et Webpack - des milliards et des milliards de dollars d'entreprises sont assises sur leur infrastructure et, bien sûr, Redux Form les prend en charge.

Dans presque tous les sites Web que vous visitez, vous pouvez regarder dans la source et vous pouvez voir du code qui a été écrit par une personne en particulier qui n'est pas correctement rémunérée. La sensibilisation doit être accrue pour que les gens apprécient davantage ce qu'est l'open source et les heures que certains d'entre nous y consacrent.

Pourquoi créer quelque chose qui est open-source et gratuit ? Qu'est-ce qui motive les développeurs comme vous ?

La raison pour laquelle vous le créez est que vous en avez besoin pour tout ce sur quoi vous travaillez en ce moment. Lorsque vous le libérez, d'autres viennent l'améliorer. Le rêve de l'open source est que vous dites : « J'ai construit une petite brouette qui m'aide à transporter mes cailloux d'ici à là », puis quelqu'un arrive et l'améliore. Sur votre prochain projet, vous revenez en arrière et vous utilisez la même bibliothèque et vous vous dites : « Whoa, ce truc bouge beaucoup plus vite. Ça va mieux maintenant."

C'est aussi très enrichissant. Je reçois un coup de dopamine quand les gens disent: "Cela nous a retenus pendant trois semaines et ce petit correctif qui vous a pris trois heures à faire nous a fait gagner trois semaines de temps." Il y a un petit cycle de dépendance avec ça, où vous obtenez un renforcement positif et ça fait du bien.

Avec ma deuxième bibliothèque de formulaires, ce n'était pas tellement que les gens disaient : « Hé, nous voulons une autre bibliothèque de formulaires », c'est juste que j'ai pensé à un moyen de l'améliorer.

C'est en quelque sorte le rêve de pourquoi vous le faites. Mais ce n'est certainement pas pour l'argent.

Dans un monde idéal, quelle serait la rémunération que vous recevriez pour la création de logiciels open source ? Juste une cerise sur le gâteau ?

Cela ne me dérangerait pas si quelqu'un me payait six chiffres pour travailler sur l'open source toute la journée. Si vous regardez la valeur générée par rapport au coût, le ratio pour l'open source est si élevé. Vous arrivez à de petites bibliothèques minuscules qui font une chose, et une chose vraiment, vraiment bien.

Si chaque entreprise dans le monde devait affecter sa propre équipe de développeurs à cette tâche, les résultats varieraient considérablement. Le fait que nous ayons l'open source et que nous puissions avoir une solution à cela - une bulle d'algorithme au sommet qui est la meilleure - signifie que tout le monde dans le monde a cette efficacité intégrée.

Une autre valeur de l'open source est que si vous utilisez quelque chose que vous avez écrit et que seule votre entreprise l'utilise. . . comparez cela à quelque chose que 1 000 entreprises utilisent. Ils ont trouvé tous les petits coins et recoins de l'espace des bogues qui pourraient potentiellement être un problème, et vous prenez cela et vous le branchez dans votre truc - vous êtes en or. Vous aurez tellement plus confiance en cela.

Le monde dynamique de JavaScript

Ayant été dans l'espace JavaScript pendant si longtemps, vous avez dû voir tant de nouveaux frameworks chauds [pour créer des applications JavaScript] apparaître et disparaître. Comment gardez-vous le pouls de l'industrie afin de pouvoir décider dans quels cadres vous engager ?

Vous devez avoir une idée des vents de la communauté des développeurs. La bataille actuelle entre TypeScript et Flow en est un excellent exemple. J'ai choisi le mauvais cheval dans cette course au départ, en supposant que Facebook serait un meilleur intendant d'un cadre de frappe. Mais je pense que TS a pratiquement gagné cette bataille, et maintenant je migre lentement les choses dans cette direction.

Il y a un coin de Twitter qui est le "développeur Twitter". Si vous suivez suffisamment de personnes - peut-être avez-vous besoin d'un échantillon d'une centaine environ - vous pouvez avoir une idée de l'endroit où les vents soufflent et de ce qui devient populaire. Vous obtiendrez beaucoup de messages comme "J'utilisais la bibliothèque A, mais je viens d'apprendre la bibliothèque B et tout est tellement plus facile." Vous en avez assez et vous vous dites: "Eh bien, je devrais peut-être jeter un coup d'œil à cette autre bibliothèque."

Les tendances vont et viennent dans l'espace JavaScript. Sera-t-il toujours en mouvement ?

Je pense (et j'espère) qu'il continuera d'évoluer. La stagnation est la mort dans la technologie. Même Java innove de manière significative en ce moment : ce que vous pouvez faire dans Java 10 n'a rien à voir avec Java 6 de votre grand-mère.

Il peut être épuisant de finalement créer votre application avec Tech X pour voir que tous les enfants cool utilisent maintenant Tech Y. Mais c'est l'industrie dans laquelle nous sommes.

Selon vous, quels concepts JavaScript sont particulièrement importants à comprendre pour vraiment maîtriser le langage ?

Je dirais que la programmation fonctionnelle et l'idée de transmettre des fonctions sont assez importantes. Surtout si vous venez d'un langage comme Java ou C++.

Pensez-vous que React devrait être utilisé pour créer des SPA [applications monopage] ou uniquement pour les composants d'une page normale ?

C'est la beauté de React : il est si polyvalent. J'ai lentement introduit React pour toutes les nouvelles fonctionnalités d'une ancienne application Java/jQuery dans mon travail quotidien. React fonctionne très bien avec un nœud DOM sur lequel agir. Il n'a pas besoin de contrôler l'ensemble de l'application.

Lorsque vous démarrez une nouvelle application React, quels sont les outils et les bibliothèques que vous utilisez régulièrement à partir de zéro ?

Je pense que create-react-app est clairement le gagnant dans ce domaine maintenant. Il y a quatre ans, quand il n'y avait rien de tel, c'était beaucoup plus difficile.

Comment gérez-vous l'état de l'application dans vos applications de réaction ?

Lorsque Redux est sorti, c'était clairement la réponse. Cependant, j'ai trouvé qu'une grande partie de mon "état" Redux était des choses comme loading et listOfObjects , et j'ai récemment utilisé Apollo GraphQL pour ces choses. D'autres choses comme isSideNavOpen peuvent être gérées assez facilement avec des composants contextuels. Cela dit, il existe encore des cas d'utilisation légitimes pour Redux, mais aucun que j'ai rencontré dans mes applications React simples.

Quel est votre éditeur/IDE préféré ?

Ah, cette question !

Je viens de Java et je suis très satisfait de JetBrains IntelliJ depuis de nombreuses années, mais c'est un peu lent pour JS. Je suis d'abord allé à Atom, mais j'ai finalement opté pour VS Code. Ses intégrations pour Jest and Flow et TypeScript sont imbattables.

Quelle est votre opinion sur le développement isomorphe comme opal qui traduit ruby ​​en JS et ouvre ensuite la voie à Rubysts pour écrire des applications structurées React/Flux dans Pure Ruby (sans écrire de JS) ?

Le fait que JavaScript ait fait le saut vers le serveur, je pense, est un gros problème. Être capable de rendre avec le même code à la fois sur le client et sur le serveur est énorme , et plus probablement la voie de l'avenir.

Selon vous, quel est le plus gros problème de nos frameworks JS les plus populaires actuellement ?

Je ne suis pas tout à fait sûr, mais j'aime vraiment la direction de css-in-js, sans serveur et SSR que des entreprises comme Zeit poursuivent avec Next.js.

C'est vraiment drôle pour moi, en tant que personne qui construisait des sites Web à la fin des années 90, que nous revenions à des sites Web statiques. Nous revenons à tout générer au moment de la construction, puis vous avez vos éléments statiques sur le serveur, puis vous pouvez ajouter des éléments dynamiques par ce qu'ils appellent la réhydratation. Une fois que vous avez rendu la page entière, vous pouvez obtenir le JavaScript supplémentaire pour réellement animer les choses et déplacer les composants.

Zeit, avec son framework Now, prend également en charge la construction statique de votre site Web, car rien n'est plus rapide que de télécharger un fichier HTML statique. C'est juste un fichier texte et puis boum, vous l'avez compris. Alors que si vous touchez un serveur, il doit toucher une base de données peut-être quatre ou cent fois juste pour créer la page que vous devez afficher. C'est super lent.

L'idée statique gagne en popularité.

Pensez-vous que JavaScript peut s'attaquer aux langages « matures » (tels que Java et C++) et devenir le langage de prédilection des entreprises ?

Absolument. Les choses que les gens font maintenant avec le nœud "sans serveur" sont extrêmement évolutives et je pense que les API d'entreprise [interfaces de programmation d'applications] peuvent et seront réécrites en JavaScript, du moins par les entreprises les plus agiles et les plus avant-gardistes.

Que doit rechercher un développeur chez un client ?

Vous voulez qu'un niveau de confiance et d'autonomie vous soit accordé, en supposant que vous êtes suffisamment senior pour le mériter. Je ne voudrais pas accepter un travail où quelqu'un regarde par-dessus mon épaule tout le temps. Beaucoup de temps, avec le travail de développement, vous pouvez avoir quelque chose qui prend cinq minutes à réparer, mais vous passez quatre heures à travailler sur un petit problème avec la construction qui fait que vous ne pouvez pas vraiment le tester. Il y a beaucoup de fois où je passe huit ou dix heures sur un problème - où je travaille vraiment, vraiment concentré tout le temps - et la solution réelle est comme deux lignes de code. Vous voulez un employeur qui a ce niveau de compréhension de ce à quoi ressemble votre travail.

Sur le syndrome de l'imposteur, l'épuisement professionnel et le déstressant

Le syndrome de l'imposteur semble être un phénomène courant chez les développeurs. Le vivez-vous, et si oui, comment le gérez-vous ?

Absolument. Surtout quand on parle à une conférence. (Ou faire une AMA?)

En ce qui concerne l'enseignement/le mentorat, vous devez réaliser que vous en savez plus sur ce que vous faites que le mois dernier. Par conséquent, il y a toujours des gens qui sont de retour là où vous étiez et qui pourraient bénéficier de vos connaissances.

Il est également important de pouvoir dire : « Je ne sais pas, examinons cela ensemble » (également un bon conseil parental).

À quoi ressemble une journée dans votre vie ? Comment tout planifier pour ne pas travailler 100 heures par semaine et s'épuiser ?

Quand j'ai été vraiment profondément dans l'open source, cela prend beaucoup plus de mon temps ; parfois, je dois me retirer pendant environ un mois à la fois. J'emmène mes enfants à l'école, puis je passe du temps à regarder quel genre de problèmes les gens ont. S'ils sont vraiment sérieux, alors je fais des efforts pour essayer d'y remédier ou de répondre d'une manière utile.

J'ai un travail quotidien qui n'est pas du tout lié à l'open source, ce qui me prend beaucoup de temps. Tout au long de la journée, j'ai configuré des notifications pour que je puisse voir s'il y a un problème sérieux avec quoi que ce soit. Si une nouvelle fonctionnalité a été publiée ou quelque chose du genre, il est plus probable qu'il y ait des bogues à ce moment-là.

J'ai appris que celui qui rédige les exigences d'un projet est certain que "cela aurait dû être fait hier, alors pourquoi n'est-ce pas encore fait?" J'ai eu tellement de fois où, quelle que soit l'équipe qui reçoit mon travail, il faut environ trois semaines pour le mettre en production. Et vous vous dites : "Eh bien, c'était quoi tout ce stress ?"

Si une tâche doit être effectuée d'ici le vendredi, et que cela finit par être fait le vendredi suivant, l'entreprise ne ferme presque jamais parce que vous avez échoué. Quand vous êtes jeune et que vous ne savez rien de mieux, c'est comme "Oh mon dieu, nous devons sortir ça par la porte." Mais après avoir fait cela suffisamment de fois, et que vous voyez : « Attendez une minute, ce qu'ils nous disaient n'était pas vraiment vrai », vous pouvez vous dire : « D'accord, ouais. Peu importe. Ce sera fait quand ce sera fait. »

J'étais un peu épuisé en octobre dernier lorsque React a annoncé cette chose appelée React Hooks. Si j'avais été là, prêt à prendre n'importe quelle nouvelle chose et à courir avec, j'aurais pu gagner beaucoup de temps en étant l'une des premières personnes à entrer dans React Hooks. Je suis en quelque sorte en train de garder un œil sur ce qui pourrait être la prochaine grande chose.

Que faites-vous pendant votre temps libre pour réduire le stress ?

Je me promène et j'écoute des podcasts qui ne concernent pas le développement.

Tout ce que vous pourriez recommander?

Les seuls vrais podcasts technologiques que j'écoute sont The Undefined Podcast, qui ne concerne que de manière tangentielle les conseils techniques et de développement. J'écoute aussi React Podcast, sur lequel j'apparaîtrai bientôt (j'espère avoir du sens, en fonction de la qualité de leur éditeur).

En regardant mon pod-catcher de choix, Overcast, mes podcasts prioritaires incluent :

• Roderick sur la ligne
• Donner du sens
• Podcast technique accidentel
• Travaux routiers
• Exposant
• Bonjour Internet
• Radiolab
• Répondre à tous

Récemment, j'ai en fait lancé deux podcasts moi-même :

Le premier s'appelle Seek Justice, dans lequel moi, une personne moyennement intelligente qui ne connaît presque rien au système de justice pénale, j'interviewe un de mes amis qui a passé toute sa carrière à l'examiner et à travailler pour le réformer. Il travaille directement avec les gouverneurs de plusieurs États américains pour réduire la population carcérale et la récidive après la libération. Ce n'est pas un sujet qui m'intéresse vraiment, mais mon co-animateur me captive à chaque épisode.

Le second est un spectacle de pure bêtise, appelé Happy Hour avec Dennis et Erik, dans lequel le même ami et moi prenons quelques verres en soirée, parlons de nos vies et nous faisons rire. Seek Justice est pour votre trajet au travail, et Happy Hour est pour votre retour à la maison.

Pour le ramener au développement, mes efforts de podcast m'ont aidé à résoudre un problème auquel je ne pouvais pas trouver de solution dans l'industrie : un lecteur MP3 simple, avec une pochette d'album, qui fonctionnait également comme une carte Twitter. J'ai donc écrit AudioCard.