Dicas de desenvolvedor full-stack do criador da biblioteca de formulários Redux

Em fevereiro de 2019, a equipe da comunidade da Toptal lançou uma iniciativa totalmente nova: uma oportunidade mensal de interagir com os especialistas de rede da Toptal em tempo real. As sessões Ask Me Anything (AMA) são abertas a todos os membros da equipe principal e da rede de talentos da Toptal – qualquer um pode fazer uma pergunta. Neste artigo, selecionamos perguntas e respostas selecionadas de um especialista em JavaScript e Redux, Erik Rasmussen. Erik discute os desafios do desenvolvimento de software de código aberto, dicas para desenvolvedores e o mundo flutuante do JavaScript, como ele lida com a síndrome do impostor e o esgotamento como desenvolvedor sob demanda e suas principais recomendações de podcast.

Erik é um especialista em JavaScript full-stack com mais de 25 anos de experiência em desenvolvimento, especializado em React, Redux, formulários em React e GraphQL. No GitHub – um serviço de hospedagem baseado na web para controle de versão com mais de 28 milhões de usuários – ele conseguiu um lugar no top 100 com mais de 20.000 estrelas. Ele também é o autor da primeira e terceira bibliotecas de formulários mais populares em React: Redux-Form e React-Final-Form.

Redux Form e o estado do software de código aberto

Por que você decidiu criar outra biblioteca de formulários após o tremendo sucesso por trás do Redux Form?

Aprendi muitas lições ao longo do caminho com o Redux Form e ganhei insights sobre as necessidades dos desenvolvedores do React Form em todo o mundo. Alguns dos problemas com o React Form simplesmente não poderiam ser resolvidos sem dar uma nova olhada no problema. (Mais detalhes aqui.)

Muitos desenvolvedores sonham em criar um projeto de código aberto muito popular. Quais são algumas das consequências inesperadas (boas e ruins) de ter um projeto tão bem-sucedido quanto o Redux Form?

É extremamente gratificante quando você pode corrigir um bug que impedia um desenvolvedor ou uma equipe inteira de concluir um projeto. Também é realmente incrível quando as pessoas encontram e corrigem os próprios bugs. Até agora, as pessoas têm sido muito gentis e gentis quando pedem ajuda; Eu ainda não tive uma interação com um usuário justo que acha que devo uma correção a eles.

No lado desafiador, o esgotamento é uma coisa real, e ainda não descobrimos uma maneira de compensar os desenvolvedores de OSS por dedicarem seu tempo e energia a projetos de OSS. O Redux Form é usado por corporações bilionárias em todo o mundo para fazer negócios, e sua existência economizou milhares de horas de desenvolvimento para as equipes que o instalaram, mas não há uma boa solução para dar nem mesmo uma parcela desse dinheiro aos autores .

Existem soluções promissoras em andamento para compensar desenvolvedores de código aberto como você?

Um amigo meu fundou esta empresa chamada CodeFund. Ele teve essa ideia de: “E se pudéssemos colocar anúncios na documentação da biblioteca de códigos?” Como desenvolvedores, passamos o dia todo analisando a documentação e descobrindo como implementar qualquer coisa que estejamos fazendo. Além disso, os desenvolvedores ganham muito mais dinheiro do que um internauta comum, então somos um produto de luxo em potencial.

O CodeFund teve a ideia de que a documentação é um ótimo lugar para anunciar. Eu era um dos pilotos originais. Funcionou muito bem, mas eles tiveram um problema com o GitHub. Originalmente, estávamos colocando anúncios no próprio repositório do GitHub, mas o GitHub e os advogados entraram e disseram não. O que é uma pena. A CodeFund negociou com eles por um tempo, mas no final eles disseram que não.

Com a documentação da biblioteca bem movimentada, você pode obter talvez US$ 150 por mês, o que não está pagando o que vale. Existem algumas bibliotecas raras - como Babble ou Webpack - onde há dinheiro suficiente para que eles possam realmente dar suporte a dois ou três desenvolvedores em tempo integral trabalhando para melhorar isso. Babble e Webpack — empresas que valem bilhões e bilhões de dólares estão sentadas em sua infraestrutura e, com certeza, o Redux Form as suporta.

Em quase todos os sites que você visita, você pode olhar na fonte e ver algum código que foi escrito por uma pessoa em particular que não está sendo devidamente compensada. A conscientização precisa ser aumentada para que as pessoas apreciem mais o que é código aberto e as horas que alguns de nós dedicamos.

Por que criar algo de código aberto e gratuito? Qual é o incentivo para desenvolvedores como você?

A razão pela qual você o cria é porque você precisa dele para o que quer que esteja trabalhando no momento. Quando você o libera, outros vêm e o tornam melhor. O sonho de código aberto é você dizer: “Eu construí um carrinho de mão que me ajuda a levar minhas pedras daqui para lá”, e então alguém aparece e melhora. Em seu próximo projeto, você volta e usa a mesma biblioteca e pensa: “Uau, essa coisa se move muito mais rápido. É melhor agora."

Também é muito gratificante. Eu recebo uma dose de dopamina quando as pessoas dizem: “Isso está nos segurando por três semanas e essa pequena correção que você levou três horas para fazer nos economizou três semanas de tempo”. Há um pequeno ciclo de vício com isso, onde você recebe reforço positivo e isso é bom.

Com minha segunda biblioteca de formulários, não era tanto que as pessoas estivessem dizendo: “Ei, queremos outra biblioteca de formulários”, foi apenas que pensei em uma maneira de torná-la melhor.

Esse é o tipo de sonho de por que você faz isso. Mas certamente não é pelo dinheiro.

Em um mundo ideal, quanta remuneração você receberia por criar software de código aberto? Apenas uma cereja no topo do bolo?

Eu não me importaria se alguém me pagasse seis dígitos apenas para trabalhar em código aberto o dia todo. Se você observar o valor gerado versus o custo, a proporção de código aberto é muito alta. Você chega a pequenas bibliotecas que fazem uma coisa, e uma coisa muito, muito bem.

Se todas as empresas do mundo tivessem que designar sua própria equipe de desenvolvedores para fazer isso, os resultados variariam muito. O fato de termos código aberto e podermos ter uma solução para isso - uma bolha de algoritmo no topo que é melhor - significa que todos no mundo têm essa eficiência incorporada.

Outro valor do código aberto é que, se você estiver usando algo que escreveu e apenas sua empresa estiver usando . . . compare isso com algo que 1.000 empresas estão usando. Eles encontraram todos os cantos e recantos do espaço dos bugs que poderiam ser um problema, e você pega isso e conecta isso à sua coisa - você é de ouro. Você terá muito mais confiança nisso.

O mundo dinâmico do JavaScript

Tendo estado no espaço JavaScript por tanto tempo, você deve ter visto tantos novos frameworks quentes [para construir aplicativos JavaScript] irem e virem. Como você mantém o pulso no setor para poder decidir com quais estruturas se comprometer?

Você tem que sentir os ventos da comunidade dev. A batalha atual entre TypeScript e Flow é um ótimo exemplo. Eu escolhi o cavalo errado naquela corrida inicialmente, assumindo que o Facebook seria um melhor administrador de uma estrutura de digitação. Mas acho que a TS praticamente venceu essa batalha, e agora estou migrando lentamente as coisas nessa direção.

Há um canto do Twitter que é o “Twitter do desenvolvedor”. Se você seguir um número suficiente de pessoas — talvez precise de uma amostra de cem ou mais — você pode ter uma ideia de onde os ventos estão soprando e o que está se tornando popular. Você receberá muitas postagens como: “Eu costumava usar a biblioteca A, mas acabei de aprender sobre a biblioteca B e tudo é muito mais fácil”. Você se cansa disso e pensa: “Bem, talvez eu devesse dar uma olhada nessa outra biblioteca”.

As tendências vêm e vão no espaço JavaScript. Estará sempre em movimento?

Eu acho (e espero) que continue a evoluir. A estagnação é a morte na tecnologia. Até o Java está inovando significativamente agora: as coisas que você pode fazer no Java 10 não são nada parecidas com o Java 6 da sua avó.

Pode ser exaustivo finalmente criar seu aplicativo com o Tech X apenas para ver que todos os garotos legais agora estão usando o Tech Y. Mas esse é o setor em que estamos.

Na sua opinião, quais conceitos JavaScript são especialmente importantes para realmente entender para obter o domínio da linguagem?

Eu diria que programação funcional e a ideia de passar funções é muito importante. Especialmente se você estiver vindo de uma linguagem como Java ou C++.

Você acha que o React deve ser usado para construir SPAs [aplicativos de página única] ou apenas para componentes em uma página normal?

Essa é a beleza do React: é tão versátil. Eu tenho introduzido lentamente o React para todos os novos recursos em um aplicativo Java/jQuery antigo no meu trabalho diário. O React funciona muito bem, dado um nó DOM para agir. Ele não precisa estar no controle de todo o aplicativo.

Ao iniciar um novo aplicativo React, quais são as ferramentas e bibliotecas que você usa regularmente do zero?

Eu acho que create-react-app é o vencedor claro disso agora. Há quatro anos, quando não havia nada disso, era muito mais difícil.

Como você lida com o estado do aplicativo em seus aplicativos de reação?

Quando o Redux foi lançado, era claramente a resposta. No entanto, descobri que muito do meu "estado" do Redux era coisas como loading e listOfObjects , e mais recentemente tenho usado o Apollo GraphQL para essas coisas. Outras coisas como isSideNavOpen podem ser gerenciadas facilmente com componentes baseados em contexto. Dito isso, ainda existem alguns casos de uso legítimos para o Redux, mas nenhum que encontrei em meus aplicativos React simples.

Qual é o seu editor/IDE favorito?

Ah, essa pergunta!

Eu venho de Java e estou muito feliz com JetBrains IntelliJ há muitos anos, mas é um pouco lento para JS. Primeiro eu fui para o Atom, mas finalmente decidi pelo VS Code. Suas integrações para Jest e Flow e TypeScript são imbatíveis.

Qual é a sua opinião sobre desenvolvimento isomórfico como o opal que traduz ruby ​​para JS e então abre o caminho para Rubysts escreverem aplicativos estruturados em React/Flux em Pure Ruby (sem escrever nenhum JS)?

O fato de JavaScript ter feito o salto para o servidor, eu acho, é um grande negócio. Ser capaz de renderizar com o mesmo código tanto no cliente quanto no servidor é enorme , e provavelmente o caminho do futuro.

Qual você acha que é o maior problema de nossos atuais frameworks JS mais populares?

Não tenho certeza, mas gosto muito da direção de css-in-js, serverless e SSR que empresas como a Zeit estão buscando com o Next.js.

É muito engraçado para mim, como alguém que estava construindo sites no final dos anos 90, que estamos voltando para sites estáticos. Vamos voltar a gerar tudo em tempo de construção, e então você tem suas coisas estáticas no servidor e então você pode adicionar coisas dinâmicas pelo que eles chamam de reidratação. Depois de renderizar a página inteira, você pode obter o JavaScript extra para realmente tornar as coisas animadas e mover os componentes.

Zeit, com sua estrutura Now, também suporta a construção estática do seu site, porque nada é mais rápido do que baixar um arquivo HTML estático. É apenas um arquivo de texto e, em seguida, boom, você entendeu. Considerando que, se você estiver acessando um servidor, ele terá que acessar um banco de dados talvez quatro ou cem vezes apenas para criar a página que você precisa exibir. Isso é super lento.

A ideia estática está ganhando popularidade.

Você acha que o JavaScript pode assumir linguagens “maduras” (como Java e C++) e se tornar a linguagem de escolha para empresas?

Definitivamente. As coisas que as pessoas estão fazendo agora com o nó “sem servidor” são extremamente escaláveis ​​e acho que as APIs corporativas [interfaces de programação de aplicativos] podem e serão reescritas em JavaScript, pelo menos pelas corporações mais ágeis e com visão de futuro.

O que um desenvolvedor deve procurar em um cliente?

Você quer um nível de confiança e autonomia dado a você, supondo que você seja sênior o suficiente para merecê-lo. Eu não gostaria de aceitar um emprego onde alguém estivesse olhando por cima do meu ombro o tempo todo. Muito tempo, com o trabalho de desenvolvimento, você pode ter algo que leva cinco minutos para consertar, mas você gasta quatro horas trabalhando em algum pequeno problema com a construção que faz com que você não possa realmente testá-lo. Há muitas vezes em que passo oito ou dez horas em um problema - onde estou realmente trabalhando, realmente focado o tempo todo - e a solução real é como duas linhas de código. Você quer um empregador que tenha esse nível de compreensão de como é o seu trabalho.

Sobre a Síndrome do Impostor, Burnout e Desestressar

A síndrome do impostor parece ser um fenômeno não incomum entre os desenvolvedores. Você vive isso e, em caso afirmativo, como você lida com isso?

Absolutamente. Especialmente ao falar em uma conferência. (Ou fazer uma AMA?)

Quando se trata de ensino/orientação, você precisa perceber que sabe mais sobre o que faz do que no mês passado. Portanto, sempre há pessoas que estão de volta onde você costumava estar e que podem se beneficiar do seu conhecimento.

Também é importante poder dizer “não sei, vamos investigar juntos” (também uma boa dica para pais).

Como é um dia na sua vida? Como você agenda tudo para que você não trabalhe 100 horas por semana e se esgote?

Quando eu me aprofundo muito no código aberto, isso toma muito mais do meu tempo; às vezes, eu tenho que recuar por um mês ou mais de cada vez. Levo meus filhos para a escola e depois passo o tempo olhando que tipo de problemas as pessoas estão tendo. Se eles são realmente sérios, então eu gasto algum esforço tentando remediá-los ou responder de uma maneira útil.

Eu tenho um trabalho diário que não está relacionado a código aberto, o que toma muito do meu tempo. Ao longo do dia, tenho notificações configuradas para que eu possa ver se há algum problema sério com alguma coisa. Se um novo recurso foi lançado ou algo assim, é mais provável que haja bugs nessa época.

Aprendi que quem está escrevendo os requisitos de um projeto tem certeza de que “Isso deveria ter sido feito ontem, então por que ainda não foi feito?” Já tive muitas vezes em que qualquer equipe que recebe meu trabalho leva três semanas para realmente colocá-lo em produção. E você fica tipo, “Bem, por que todo esse estresse?”

Se uma tarefa precisa ser feita até sexta-feira, e isso acaba sendo feito na sexta-feira seguinte, quase nunca a empresa fecha porque você falhou. Quando você é jovem e não conhece nada melhor, parece: “Oh meu Deus, temos que colocar isso para fora da porta”. Mas depois de ter feito isso várias vezes, e você ver: “Espere um minuto, o que eles estavam nos dizendo não era realmente verdade”, você pode dizer: “Ok, sim. Qualquer que seja. Vai ser feito quando for feito.”

Eu estava um pouco esgotado em outubro passado quando o React anunciou essa coisa chamada React Hooks. Se eu estivesse lá, pronto para pegar qualquer coisa nova e correr com ela, eu poderia ter feito muita quilometragem por ser uma das primeiras pessoas a entrar no React Hooks. Estou meio que mantendo meu olho para o que poderia ser a próxima grande coisa.

O que você faz no seu tempo livre para diminuir o estresse?

Eu faço caminhadas e ouço podcasts que não são sobre desenvolvimento.

Algum que você poderia recomendar?

Os únicos podcasts de tecnologia reais que eu escuto são The Undefined Podcast, que é apenas tangencialmente sobre tecnologia e dicas de desenvolvedores. Também ouço React Podcast – no qual aparecerei em breve (espero que faça algum sentido, dependendo da qualidade de seu editor).

Olhando para o meu pod-catcher de escolha, Overcast, meus podcasts prioritários incluem:

• Rodrigo na linha
• Fazendo sentido
• Podcast de Tecnologia Acidental
• Obras Rodoviárias
• Expoente
• Olá Internet
• Radiolab
• Responder todos

Recentemente, eu mesmo comecei dois podcasts:

O primeiro chama-se Seek Justice, no qual eu, uma pessoa moderadamente inteligente que não sabe quase nada sobre o sistema de justiça criminal, entrevisto um amigo meu que passou toda a sua carreira examinando e trabalhando para reformá-lo. Ele está trabalhando diretamente com governadores de vários estados dos EUA para reduzir a população carcerária e a reincidência após a soltura. Não é um assunto que eu realmente me interesse, mas meu co-apresentador me cativa a cada episódio.

O segundo é um show de pura tolice, chamado Happy Hour com Dennis e Erik, no qual o mesmo amigo e eu tomamos algumas bebidas à noite, conversamos sobre nossas vidas e nos fazemos rir. O Seek Justice é para o seu trajeto de olhos brilhantes para o trabalho, e o Happy Hour é para o seu caminho de volta para casa.

Para trazê-lo de volta aos desenvolvedores, meus esforços de podcast me ajudaram a resolver um problema para o qual não conseguia encontrar uma solução na indústria: um MP3 player fácil, com arte do álbum, que também funcionava como um cartão do Twitter. Então eu escrevi AudioCard.