Consejos para desarrolladores de pila completa del creador de la biblioteca de formularios Redux

En febrero de 2019, el equipo de la comunidad de Toptal lanzó una nueva iniciativa: una oportunidad mensual para interactuar con los expertos de la red de Toptal en tiempo real. Las sesiones Ask Me Anything (AMA) están abiertas a todos los miembros del equipo central y la red de talentos de Toptal: cualquiera puede hacer una pregunta. En este artículo, hemos seleccionado preguntas y respuestas seleccionadas de un experto en AMA con JavaScript y Redux, Erik Rasmussen. Erik analiza los desafíos del desarrollo de software de código abierto, los consejos para desarrolladores y el mundo fluctuante de JavaScript, cómo lidia con el síndrome del impostor y el agotamiento como desarrollador en demanda, y sus principales recomendaciones de podcasts.

Erik es un experto en JavaScript de pila completa con más de 25 años de experiencia en desarrollo, especializado en React, Redux, formularios en React y GraphQL. En GitHub, un servicio de hospedaje basado en la web para el control de versiones con más de 28 millones de usuarios, obtuvo un lugar entre los 100 mejores con más de 20 000 estrellas. También es el autor de la primera y tercera bibliotecas de formularios más populares en React: Redux-Form y React-Final-Form.

Redux Form y el estado del software de código abierto

¿Por qué decidiste crear otra biblioteca de formularios después del tremendo éxito detrás de Redux Form?

Aprendí muchas lecciones en el camino con Redux Form y obtuve información sobre las necesidades de los desarrolladores de React Form en todo el mundo. Algunos de los problemas con React Form simplemente no podrían abordarse sin analizar el problema desde una nueva perspectiva. (Más detalles aquí.)

Muchos desarrolladores sueñan con crear un proyecto de código abierto masivamente popular. ¿Cuáles son algunas de las consecuencias inesperadas (buenas y malas) de tener un proyecto tan exitoso como Redux Form?

Es extremadamente gratificante cuando puede corregir un error que ha impedido que un desarrollador o un equipo completo completen un proyecto. También es realmente increíble cuando las personas encuentran y corrigen errores por sí mismos. Hasta ahora, las personas han sido muy amables y amables cuando piden ayuda; Todavía no he tenido una interacción con un usuario honrado que piense que le debo una solución.

En el lado desafiante, el agotamiento es algo real, y aún no hemos descubierto una forma de compensar a los desarrolladores de OSS por dedicar su tiempo y energía a los proyectos de OSS. Redux Form es utilizado por corporaciones de miles de millones de dólares en todo el mundo para realizar transacciones comerciales, y su existencia ha ahorrado miles de horas de desarrollo para los equipos que lo han instalado, pero no hay una buena solución para dar incluso una pequeña parte de ese dinero a los autores. .

¿Hay alguna solución prometedora en proceso para compensar a los desarrolladores de código abierto como usted?

Un amigo mío fundó esta empresa llamada CodeFund. Tenía esta idea de "¿Qué pasaría si pudiéramos poner anuncios en la documentación de la biblioteca de códigos?" Como desarrolladores, pasamos todo el día mirando la documentación y descifrando cómo implementar lo que sea que estemos haciendo. Además, los desarrolladores ganan mucho más dinero que el internauta promedio, por lo que somos un producto potencial de lujo.

A CodeFund se le ocurrió la idea de que la documentación es un excelente lugar para hacer publicidad. Yo era uno de los pilotos originales. Funcionó bastante bien, pero se encontraron con un problema con GitHub. Originalmente, estábamos poniendo anuncios en el repositorio de GitHub, pero GitHub y los abogados intervinieron y dijeron que no. Que es una pena. CodeFund negoció con ellos por un tiempo, pero al final dijeron que no.

Con la documentación de la biblioteca bien traficada, puede obtener tal vez $ 150 dólares al mes, que no está pagando lo que vale. Hay algunas bibliotecas raras, como Babble o Webpack, donde se les da suficiente dinero para que puedan apoyar a dos o tres desarrolladores de tiempo completo que trabajan para mejorar eso. Babble y Webpack: miles y miles de millones de dólares en empresas se encuentran en su infraestructura y, por supuesto, Redux Form las respalda.

En casi cualquier sitio web al que vaya, puede buscar en la fuente y puede ver un código que fue escrito por una persona en particular que no está recibiendo la compensación adecuada. Es necesario generar conciencia para que las personas aprecien más qué es el código abierto y las horas que algunos de nosotros dedicamos.

¿Por qué crear algo que sea de código abierto y gratuito? ¿Cuál es el incentivo para desarrolladores como usted?

La razón por la que lo creas es porque lo necesitas para lo que sea que estés trabajando en este momento. Cuando lo liberas, otros vienen y lo mejoran. El sueño de código abierto es que digas: "Construí una pequeña carretilla que me ayuda a llevar mis rocas de aquí para allá", y luego viene alguien y lo mejoran. En tu próximo proyecto, regresas y usas la misma biblioteca y dices: “Vaya, esto se mueve mucho más rápido. Es mejor ahora."

También es muy gratificante. Siento un golpe de dopamina cuando la gente dice: "Esto nos ha estado retrasando durante tres semanas y esta pequeña solución que te llevó tres horas nos ha ahorrado tres semanas". Hay un pequeño ciclo de adicción con eso, donde obtienes un refuerzo positivo y se siente bien.

Con mi biblioteca de segundo formulario, no era tanto que la gente dijera: "Oye, queremos otra biblioteca de formulario", sino que pensé en una forma de mejorarla.

Ese es el sueño de por qué lo haces. Pero ciertamente no es por el dinero.

En un mundo ideal, ¿cuánta compensación recibiría por crear software de código abierto? ¿Solo un poco de guinda en el pastel?

No me importaría que alguien me pagara seis cifras solo por trabajar en código abierto todo el día. Si observa el valor generado frente al costo, la proporción de código abierto es muy alta. Llegas a pequeñas bibliotecas diminutas que hacen una cosa, y una cosa muy, muy bien.

Si todas las empresas del mundo tuvieran que asignar su propio equipo de desarrolladores para hacerlo, los resultados variarían mucho. El hecho de que tengamos código abierto y podamos tener una solución para eso, una burbuja de algoritmo en la parte superior que sea la mejor, significa que todos en el mundo tienen esa eficiencia incorporada.

Otro valor del código abierto es que si está usando algo que usted escribió y solo su empresa lo está usando. . . compare eso con algo que 1,000 empresas están usando. Han encontrado cada pequeño rincón y grieta del espacio de errores que podría ser un problema potencial, y lo tomas y lo conectas a tu cosa, eres dorado. Tendrás mucha más confianza en eso.

El mundo dinámico de JavaScript

Después de haber estado en el espacio de JavaScript durante tanto tiempo, debe haber visto tantos marcos nuevos y atractivos [para crear aplicaciones de JavaScript] ir y venir. ¿Cómo se mantiene al tanto de la industria para poder decidir con qué marcos comprometerse?

Tienes que tener una idea de los vientos de la comunidad de desarrollo. La batalla actual entre TypeScript y Flow es un gran ejemplo. Inicialmente, elegí el caballo equivocado en esa carrera, asumiendo que Facebook sería un mejor administrador de un marco de escritura. Pero creo que TS prácticamente ha ganado esa batalla, y ahora estoy migrando lentamente las cosas en esa dirección.

Hay un rincón de Twitter que es el "Twitter de desarrolladores". Si sigues a suficientes personas, tal vez necesites una muestra de cien o más, puedes tener una idea de dónde soplan los vientos y qué se está volviendo popular. Recibirá muchas publicaciones como "Solía ​​usar la biblioteca A, pero acabo de aprender sobre la biblioteca B y todo es mucho más fácil". Obtienes suficientes de esos y dices: "Bueno, tal vez debería ver esta otra biblioteca".

Las tendencias van y vienen en el espacio de JavaScript. ¿Estará siempre en movimiento?

Creo (y espero) que seguirá evolucionando. El estancamiento es la muerte en tecnología. Incluso Java está innovando significativamente en este momento: lo que puede hacer en Java 10 no se parece en nada al Java 6 de su abuela.

Puede ser agotador finalmente construir su aplicación con Tech X solo para ver que todos los chicos geniales ahora usan Tech Y. Pero esa es la industria en la que estamos.

En su opinión, ¿qué conceptos de JavaScript son especialmente importantes para comprender realmente para dominar el lenguaje?

Diría que la programación funcional y la idea de pasar funciones es bastante importante. Especialmente si vienes de un lenguaje como Java o C++.

¿Cree que React debería usarse para crear SPA [aplicaciones de una sola página] o solo para componentes en una página normal?

Esa es la belleza de React: es tan versátil. Poco a poco he estado introduciendo React para todas las funciones nuevas en una antigua aplicación Java/jQuery en mi trabajo diario. React funciona bien dado un nodo DOM para actuar. No es necesario que tenga el control de toda la aplicación.

Al iniciar una nueva aplicación React, ¿cuáles son las herramientas y bibliotecas que usa regularmente desde cero?

Creo que create-react-app es el claro ganador en este momento. Hace cuatro años, cuando no había nada de eso, era mucho más difícil.

¿Cómo maneja el estado de la aplicación en sus aplicaciones de reacción?

Cuando salió Redux fue claramente la respuesta. Sin embargo, descubrí que gran parte de mi "estado" de Redux era cosas como loading y listOfObjects , y recientemente he estado usando Apollo GraphQL para esas cosas. Otras cosas como isSideNavOpen se pueden administrar con componentes basados ​​en contexto con bastante facilidad. Dicho esto, todavía hay algunos casos de uso legítimos para Redux, pero ninguno que haya encontrado en mis aplicaciones React simples.

¿Cuál es tu editor/IDE favorito?

¡Ay, esa pregunta!

Vengo de Java y he estado muy contento con JetBrains IntelliJ durante muchos años, pero es un poco lento para JS. Primero fui a Atom, pero finalmente me decidí por VS Code. Sus integraciones para Jest and Flow y TypeScript son imbatibles.

¿Cuál es su opinión sobre el desarrollo isomórfico como opal que traduce ruby ​​a JS y luego abre el camino para que Rubysts escriba aplicaciones estructuradas React/Flux en Pure Ruby (sin escribir ningún JS)?

Creo que el hecho de que JavaScript haya dado el salto al servidor es un gran problema. Ser capaz de renderizar con el mismo código tanto en el cliente como en el servidor es enorme , y es más probable que sea el futuro.

¿Cuál cree que es el mayor problema de nuestros marcos JS actuales más populares?

No estoy del todo seguro, pero realmente me gusta la dirección de css-in-js, serverless y SSR que empresas como Zeit están siguiendo con Next.js.

Es muy divertido para mí, como alguien que estaba creando sitios web a finales de los 90, que volvamos a los sitios web estáticos. Vamos a volver a generar todo en el momento de la compilación, y luego tienes tus cosas estáticas en el servidor y luego puedes agregar cosas dinámicas mediante lo que llaman rehidratación. Una vez que haya renderizado toda la página, puede obtener el JavaScript adicional para animar las cosas y mover los componentes.

Zeit, con su marco Now, también admite la construcción estática de su sitio web, porque nada es más rápido que descargar un archivo HTML estático. Es solo un archivo de texto y luego boom, lo tienes. Mientras que si está accediendo a un servidor, tiene que acceder a una base de datos tal vez cuatro o cien veces solo para construir la página que necesita mostrar. Eso es súper lento.

La idea estática está ganando popularidad.

¿Cree que JavaScript puede adoptar lenguajes "maduros" (como Java y C++) y convertirse en el lenguaje de elección para las empresas?

Definitivamente. Lo que la gente está haciendo ahora con el nodo "sin servidor" es extremadamente escalable y creo que las API empresariales [interfaces de programación de aplicaciones] pueden y serán reescritas en JavaScript, al menos por las corporaciones más ágiles y con visión de futuro.

¿Qué debe buscar un desarrollador en un cliente?

Desea que se le otorgue un nivel de confianza y autonomía, suponiendo que sea lo suficientemente mayor como para merecerlo. No me gustaría aceptar un trabajo en el que alguien estuviera mirando por encima del hombro todo el tiempo. Mucho tiempo, con el trabajo de desarrollo, puedes tener algo que tarda cinco minutos en arreglarse, pero pasas cuatro horas trabajando en algún pequeño problema con la compilación que hace que no puedas probarlo. Hay muchas veces en las que dedico ocho o diez horas a un problema, donde realmente estoy trabajando, realmente concentrado todo el tiempo, y la solución real es como dos líneas de código. Quiere un empleador que tenga ese nivel de comprensión de cómo es su trabajo.

Sobre el síndrome del impostor, el agotamiento y el desestresamiento

El síndrome del impostor parece ser un fenómeno común entre los desarrolladores. ¿Lo experimentas y, de ser así, cómo lo enfrentas?

Absolutamente. Especialmente cuando se habla en una conferencia. (¿O haciendo un AMA?)

Cuando se trata de enseñar/orientar, debe darse cuenta de que sabe más sobre lo que hace que el mes pasado. Ergo, siempre hay personas que están de vuelta donde solías estar que podrían beneficiarse de tu conocimiento.

También es importante poder decir: “No sé, investiguemos juntos” (también un buen consejo para padres).

¿Cómo es un día en tu vida? ¿Cómo programa todo para que no trabaje 100 horas a la semana y se queme?

Cuando me he adentrado mucho en el código abierto, eso me quita mucho más tiempo; a veces, tengo que retirarme durante un mes más o menos a la vez. Llevo a mis hijos a la escuela y luego dedico tiempo a observar qué tipo de problemas tiene la gente. Si son realmente serios, entonces me esfuerzo un poco tratando de remediarlos o responder de una manera útil.

Tengo un trabajo diario que no está relacionado en absoluto con el código abierto, lo que requiere mucho de mi tiempo. A lo largo del día, tengo notificaciones configuradas para poder ver si hay un problema grave con algo. Si se ha lanzado una nueva función o algo así, es más probable que haya errores en ese momento.

Aprendí que quien escribe los requisitos para un proyecto está seguro de que "esto debería haberse hecho ayer, entonces, ¿por qué no se ha hecho todavía?" He tenido tantas ocasiones en las que el equipo que recibe mi trabajo tarda como tres semanas en ponerlo en producción. Y dices: "Bueno, ¿a qué se debe todo ese estrés?"

Si una tarea debe realizarse para el viernes y termina el viernes siguiente, casi nunca el negocio cierra porque usted falló. Cuando eres joven y no sabes nada mejor, se siente como, "Dios mío, tenemos que sacar esto por la puerta". Pero después de haber hecho eso suficientes veces, y ves, “Espera un minuto, lo que nos dijeron no era realmente cierto”, puedes decir, “Está bien, sí. Lo que. Se hará cuando se haga”.

Estaba un poco agotado en octubre pasado cuando React anunció esto llamado React Hooks. Si hubiera estado allí, listo para tomar cualquier cosa nueva y ejecutarla, podría haber obtenido muchos beneficios al ser una de las primeras personas en ingresar a React Hooks. Estoy un poco atento a lo que podría ser la próxima gran cosa.

¿Qué haces en tu tiempo libre para disminuir el estrés?

Salgo a caminar y escucho podcasts que no tratan sobre desarrollo.

¿Alguno que puedas recomendar?

Los únicos podcasts tecnológicos reales que escucho son The Undefined Podcast, que solo trata tangencialmente sobre consejos tecnológicos y para desarrolladores. También escucho React Podcast, en el que apareceré pronto (espero que tenga algún sentido, dependiendo de la calidad de su editor).

En cuanto a mi captador de pods de elección, Overcast, mis podcasts de mayor prioridad incluyen:

• Roderick en la línea
• Tener sentido
• Podcast de tecnología accidental
• Trabajo en la carretera
• Exponente
• hola internet
• radiolaboratorio
• Responder a todos

Recientemente, yo mismo comencé dos podcasts:

El primero se llama Seek Justice, en el que yo, una persona moderadamente inteligente que no sabe casi nada sobre el sistema de justicia penal, entrevisto a un amigo mío que ha pasado toda su carrera examinándolo y trabajando para reformarlo. Está trabajando directamente con los gobernadores de varios estados de EE. UU. para reducir la población carcelaria y la reincidencia posterior a la liberación. No es un tema que me haya interesado mucho, pero mi coanfitrión me cautiva en cada episodio.

El segundo es un espectáculo de pura tontería, llamado Hora feliz con Dennis y Erik, en el que el mismo amigo y yo tomamos unas copas por la noche, hablamos de nuestras vidas y nos hacemos reír. Seek Justice es para su viaje diario al trabajo con ojos brillantes, y Happy Hour es para su relajante viaje a casa.

Para traerlo de vuelta a los desarrolladores, mis esfuerzos de podcast me ayudaron a resolver un problema para el que no pude encontrar una solución en la industria: un sencillo reproductor de MP3, con la carátula del álbum, que también funcionaba como una tarjeta de Twitter. Así que escribí AudioCard.