Between the Wires: una entrevista con el desarrollador de código abierto Sindre Sorhus

Aquí está mi entrevista con Sindre Sorhus, un prolífico desarrollador de código abierto que vive en Tailandia.

Cuéntanos un poco sobre tu infancia y dónde creciste.

Crecí en un área suburbana en las afueras de Oslo, Noruega. Cuando era pequeño, estaba realmente interesado en los Legos. Todos los años recibía Legos para cumpleaños y Navidad. Legos realmente despertó mi interés en construir cosas desde el principio. En un momento, construí una enorme ciudad de Lego en mi habitación y casi ocupaba toda la habitación.

¿Cómo te metiste en la programación?

Cuando tenía siete años, mi familia consiguió nuestra primera computadora con Windows 95. Solía ​​jugar un juego llamado Map Blaster en el que el personaje saltaba para resolver problemas matemáticos. Unos años después finalmente obtuvimos acceso a Internet y eso cambió todo para mí. Pasé mucho tiempo escribiendo en libros de visitas en las páginas web de otras personas y recopilando gifs. Un día, sentí curiosidad por saber cómo funcionaba el sitio web y descubrí el botón "Ver código fuente" en el navegador.

Ese fue un descubrimiento alucinante para mí. Podía simplemente hacer clic derecho, ver la fuente y luego pude ver cómo se hizo todo. No entendí mucho al principio, pero mientras miraba lo mismo una y otra vez, comencé a entender cómo funcionaba. Así es como comencé mi viaje de programación.

Hice mi primer sitio web cuando tenía diez años. Fue después de haber mirado la fuente durante unos años. Tenía todo tipo de colores, un fondo estampado de estrellas, animado con música de fondo multimedia: era uno de esos toques que todo el mundo tenía en sus sitios web en ese entonces. Usé Microsoft FrontPage.

Una vez, estaba aburrido, así que creé miles de directorios anidados en la computadora de mi papá y terminó bloqueando la computadora. Mi papá tuvo que reformatear la computadora; estaba impresionado y molesto al mismo tiempo. También fue así como perdí mi primer sitio web.

Más tarde, durante mi año escolar, me metí en los juegos Flash y veíamos muchas películas Flash durante las vacaciones escolares. Tenía curiosidad por saber cómo se hicieron, pero nunca hubo ningún botón de fuente. Así que descompillé los archivos SWIFF, fue fácil porque no estaban ofuscados. Eso, nuevamente, me dio la oportunidad de aprender del trabajo de otras personas. Comencé a modificar los juegos de otras personas y rehice todos los personajes, hice nuevos enemigos, agregué puntuaciones altas. Fue un momento de orgullo cuando me di cuenta de que otros podían jugar un juego que yo había pegado.

Pasó cinco años en el ejército como desarrollador y fotógrafo. ¿Cómo era el desarrollo web en ese momento?

Después de graduarme de la escuela secundaria, fui reclutado directamente al ejército en Noruega. Entré en la unidad de medios donde pasé la mayor parte del tiempo en la oficina trabajando en la intranet. No había mucho que hacer por las noches porque vivíamos en el cuartel, así que decidí construir cosas. Pero la mayor parte de mi experiencia había sido copiar y pegar PHP y JavaScript de otras personas y no entendía muy bien cómo funcionaban. Un día, me topé con Python y Django, tenía gran documentación y tutoriales que PHP nunca tuvo. Leía tutoriales todos los días y comenzaba a construir cosas en el trabajo.

Así es como comenzó mi codificación real. Después del servicio militar obligatorio, planeé viajar antes de la universidad. Pero recibí una oferta de trabajo de una unidad militar llamada Cyber ​​Defense Unit. Fue intrigante, así que acepté la oferta y terminé pasando 5 años allí.

¿Cómo te involucraste con TodoMVC y Yeoman?

Comencé a usar GitHub alrededor de 2011, pero principalmente como consumidor. Iba por ahí, mirando diferentes repositorios y destacándolos porque se veían divertidos. Corregí algunos errores tipográficos en los archivos README.md, pero eso fue todo.

Un día me topé con TodoMVC que te ayuda a seleccionar un marco de JavaScript. Fue una idea realmente asombrosa, aunque en retrospectiva, necesitamos aplicaciones mucho más avanzadas para resolver los problemas de las pruebas de rendimiento y las capacidades del marco. Lo primero que recordé de TodoMVC fue que tenía un bonito logo. Parece muy superficial, pero eso fue lo que me hizo empezar.

Me gustó tanto el logo que decidí mirar un poco más. Noté que realmente no tenían una aplicación jQuery, así que decidí crear una. Envié una solicitud de extracción durante el fin de semana y obtuve una respuesta de Addy Osmani, quien es la encargada de mantener el proyecto. Fusionó mis relaciones públicas rápidamente, lo que fue una experiencia súper agradable para un principiante como yo. Me sentí bien de que mi aplicación estuviera ahora incluida en este proyecto realmente popular. Hice esto durante unas semanas y Addy me agregó al proyecto, lo cual fue realmente genial.

Esto realmente me interesó en el código abierto. Antes de esto, solo era un consumidor pasivo, pero con TodoMVC probé mantener un gran proyecto que era mucho trabajo. Pero aprendí mucho de esa experiencia.

Unos meses más tarde, Addy se puso a trabajar para Google. Su primer proyecto en Google fue Yeoman, una herramienta de andamiaje para aplicaciones web modernas. Debido a que trabajamos tan bien juntos en TodoMVC, decidió invitarme como colaborador externo.

Nuestro objetivo inicial con Yeoman era crear un conjunto de herramientas que todos pudieran usar para crear excelentes aplicaciones web. De lo que no nos dimos cuenta entonces es que es imposible resolver el problema de todos en una sola herramienta porque en la web hay demasiados casos de uso. Yeoman se convirtió en una configuración popular que muchos desarrolladores crearon generadores para extender Yeoman que se adaptara a sus propios casos de uso.

El historial también se repite si miras la aplicación Create React o Webpack. Alguien comienza a fabricar este producto que se supone que resuelve un problema, pero debido a que todos tienen necesidades diferentes, surgen problemas. Cuando se da cuenta de que esta herramienta no puede cubrir todo, agrega la configuración. La clave es tener un enfoque equilibrado. Tienes que decir "No" y necesitas saber cuándo decir "no". Puede decepcionar a algunos usuarios porque tienen casos de uso poco conocidos. Esa es la parte difícil de crear herramientas, y es aún más difícil en proyectos de código abierto porque hay muchos comentarios.

¿Por qué te apasiona el código abierto?

Me encanta el código abierto y creo que vuelve al botón "Ver código fuente" del navegador. En mi opinión, el código abierto es la forma más efectiva de crear software porque nos permite construir sobre el trabajo de los demás. Todos se benefician si una persona resuelve un problema difícil. El código abierto me permite trabajar con personas increíbles de todo el mundo con las que nunca hubiera podido trabajar de otra manera. Nos ponemos a trabajar en lo que nos importa y nos centramos en lo que la comunidad necesita en lugar de centrarnos en generar ingresos.

Paul Irish tiene un excelente video en YouTube titulado "Diez cosas que aprendí de jQuery Source". Eso es lo que me interesó en leer el código fuente de jQuery. Paul Irish tenía razón, aprendes mucho haciendo lo que quieras aprender a hacer.

¿Qué hay de la sostenibilidad de código abierto?

Definitivamente ese es un punto de conflicto en el que he estado pensando mucho recientemente. He trabajado en código abierto a tiempo completo durante unos tres años. No gano nada de dinero, pero sería bueno hacerlo a tiempo completo como un trabajo remunerado. Sin embargo, Vue.js de Evan You es un gran ejemplo de cómo puede funcionar la sostenibilidad de código abierto. Creó un marco que todos querían y ha sido utilizado por bastantes empresas. Otras empresas y particulares tienen incentivos para invertir en su proyecto porque es útil en producción. La clave es hacer que su proyecto sea confiable. Personalmente, no creo que las contribuciones de individuos sean suficientes para sostener un proyecto.

He estado pensando en usar Open Collective para poder recolectar dinero para recompensar a los contribuyentes y las promociones de eventos. Webpack ha hecho un gran trabajo allí. De hecho, estuve en contra de esto durante mucho tiempo, porque me preocupaba que hubiera expectativas de que hiciéramos cambios no deseados cada vez que alguien invirtiera dinero en el proyecto. Por lo general, si una empresa invierte en un proyecto, quiere que se priorice el trabajo y que los problemas se solucionen rápidamente.

Actualmente vivo en Tailandia y creo que estaría bien con menos de 1500 dólares.

Tienes más de 1000 paquetes npm. ¿Cómo te mantienes tan productivo?

Eso es un error. La gente ve los paquetes número 1000 y creen que soy increíblemente productivo, pero lo que no se dan cuenta es que la mayoría de esos paquetes son pequeños y modulares. Están prácticamente terminados cuando se publican. Me gusta comparar la programación con la construcción con Lego: creo muchos ladrillos de Lego que se pueden ensamblar para construir construcciones más grandes. Los uso con otros paquetes antes de publicarlos para asegurarme de que resuelvan mis problemas. Es también por eso que los usuarios no enviarían muchas solicitudes de funciones porque son muy pequeñas. Si necesitan algo más, pueden simplemente construir otro módulo. El 90% de mi tiempo lo dedico a mis 10 proyectos más importantes.

¿Cuál es un consejo que puede dar a los nuevos colaboradores de OSS cuando se trata de personas exigentes y tóxicas?

He estado haciendo código abierto durante seis años, así que he desarrollado una piel gruesa. No creo que nada me moleste más porque me gusta pensar que lo he experimentado todo. Hablo con muchos principiantes que experimentan cierta toxicidad y luego abandonan. Se supone que el código abierto es algo divertido que haces, no una causa de estrés en tu vida.

Mi consejo para los nuevos desarrolladores es que no deben permitir que extraños en Internet afecten negativamente su estado de ánimo o su conducción. No vale la pena. Si tiene la opción de retirarse, tómela: utilice el botón para cancelar la suscripción. Los mantenedores de código abierto deben recordar que los usuarios no son clientes que pagan. Les proporcionamos algo gratis, en nuestro propio tiempo libre.

Con personas tóxicas, siempre debes ser la persona más grande. Suena mal, pero lo que trato de hacer es matarlos con amabilidad. De alguna manera me ha funcionado durante muchos años. Por ejemplo, si alguien es molesto, intentaré ser tan abierto y amable con la situación. Me aseguro de nunca ser sarcástico ni hablarles con desprecio. Los trolls se alimentan de tu molestia y tu discurso, así que cuando no está ahí te dejarán en paz.

Utilizo la opción de silenciamiento dondequiera que esté disponible, especialmente en Twitter. Es bueno darse cuenta de cuando alguien está al borde de la toxicidad, y es mucho mejor simplemente apagar esa voz y dar entrada a cabo en lugar de causar un conflicto innecesario.

Diseñaste algunos logotipos para tus propios módulos, son increíbles. ¿Cómo aprendiste a diseñar?

Comencé siguiendo tutoriales en línea para crear efectos geniales. Solía ​​usar Adobe Illustrator, pero ahora uso Sketch.

Es muy divertido para mí diseñar, y creo que más programadores deberían probarlo. Después de programar durante horas, es bueno tomarse un descanso para hacer un trabajo creativo de una manera diferente.

También beneficia mis proyectos al crear logotipos, porque le da más personalidad al proyecto. Por lo general, cuando ingresa a un repositorio en GitHub, obtiene las mismas cosas basadas en texto: un encabezado, una introducción y README.md. Es bueno condimentarlo con algunos gráficos. Resulta que es más probable que las personas utilicen el proyecto si hay un logotipo. Por ejemplo, Vadim Demedes, un desarrollador de Ucrania, envió esta solicitud de extracción justo después del lanzamiento de AVA. Más tarde, Vadim se convirtió en miembro del equipo AVA. Me dijo que se interesó en AVA por su bonito logo.

¿Qué te impulsó a mudarte a Tailandia? Cuéntenos cómo es un día típico para usted.

Realmente no sabía mucho sobre Tailandia. Cuando trabajaba en el servicio militar obligatorio, planeaba viajar. Recibí una oferta y terminé quedándome otros cuatro años. Simplemente me dejé llevar, porque la vida pasa.

Un día, cuando estaba preparando una entrevista telefónica con Google, decidí que si alguna vez iba a viajar, sería ahora, de lo contrario, nunca sucedería. Así que cancelé la entrevista y presenté mi renuncia al trabajo al día siguiente. Compré un boleto de ida a Tailandia y eso fue todo.

Hice mochilero durante medio año en el sudeste asiático, y ahí fue donde conocí a mi novia. Finalmente me instalé en Tailandia porque era mi favorito. Me encanta su rica cultura, su gente amable y su comida. Vivo en Tailandia desde hace dos años.

Trabajo en cafeterías locales tres días a la semana porque soy más productivo cuando tengo gente a mi alrededor. De lo contrario, de nueve a seis realizo mucho mantenimiento y codificación de código abierto, a veces mis proyectos paralelos. La mayoría de los días, recibo más de 20 solicitudes de extracción y toneladas de problemas que solucionar. Por la noche, paso tiempo con mi novia Im; a los dos nos encanta la comida callejera picante en los mercados nocturnos. A veces el deber llama y me encuentro de nuevo frente a la computadora a altas horas de la noche.

No aprendí el idioma tailandés porque, si bien soy bueno en los lenguajes de programación, el lenguaje hablado es mucho más difícil que cualquier lenguaje de programación, y el tailandés es especialmente difícil. Mi novia, por otro lado, habla tailandés, ruso e inglés con fluidez y bastante bien en sueco. En algún momento, quiero aprender tailandés y otros idiomas, pero no tengo tiempo.

¿Qué te motivó a iniciar el proyecto AVA?

Usaba mucho Mocha porque hice muchos módulos que tenían que probarse. No estaba muy contento con cómo funcionó. Mocha inyecta algunos objetos globales pero no están definidos en ninguna parte. Como lo estaba haciendo en Node.js, tenía muchas API asíncronas y no era muy conveniente hacerlo con Mocha.

Quería algo más simple y optimizado para mi caso de uso. Así que un fin de semana, decidí trabajar en ello y el domingo por la noche publiqué la versión 0.0.1 para AVA en npm. Aunque JavaScript es de un solo subproceso, la IO en Node.js puede ocurrir en paralelo debido a su naturaleza asíncrona. AVA se aprovecha de esto y ejecuta sus pruebas al mismo tiempo, lo cual es especialmente beneficioso para pruebas pesadas de IO. Además, los archivos de prueba se ejecutan en paralelo como procesos separados, lo que permite un rendimiento potencialmente incluso mejor y un entorno aislado para cada archivo de prueba.

Debido a que no tuve tiempo para corregir errores y solo quería usarlo en mis propios proyectos, era privado. Después de un año y medio, finalmente hice un logo para AVA, limpié el repositorio, escribí mucha documentación. Luego publiqué el proyecto.

La mayoría de los usuarios parecen muy felices con AVA porque recibimos tweets positivos sobre el proyecto todo el tiempo. Les gusta mucho lo simple que es la sintaxis y lo fácil que es comenzar. Lo hice para rascarme mi propia picazón, pero resulta que otras personas tenían el mismo problema y les gustó mi solución.

Hoy en día, dedico más tiempo a administrar el proyecto porque hay tantos problemas nuevos y solicitudes de extracción cada semana, lo que me deja muy poco tiempo para codificar.

¿Por qué decidió entrar en el desarrollo de macOS?

Hice un poco de programación Objective-C pero no tuve una gran experiencia. Este enero, tuve una idea para una aplicación para Mac y tenía algo de tiempo libre, así que me lancé directamente a Swift. Así es como suelo aprender cosas nuevas. Es muy espontáneo. Empiezo con el deseo de hacer un producto, luego averiguo qué habilidades necesito para hacer ese producto y luego las aprendo. La idea viene antes que la planificación.

Swift es mucho más difícil de aprender inicialmente que JavaScript, pero Swift brilla porque está fuertemente tipado. Cuando compila, es mucho más improbable que se bloquee si usa los opcionales correctamente. Lo único que no me gustó de Swift es que a veces todavía tienes que interactuar con las API antiguas en C.

Escribí algunas aplicaciones de productividad y utilidad. Lungo es una aplicación de barra de menú que escribí y la encuentras en la App Store. El otro que escribí es Indicador de batería.

¿Cuál es su plan para el próximo año? ¿Está planeando trabajar a tiempo completo o considerar otras formas de ser financieramente sostenible?

He estado viviendo de los ahorros durante los últimos tres años y haciendo software de código abierto. Eso es mucho más fácil en Asia, pero no dura para siempre. Idealmente, me gustaría hacer código abierto de una manera financieramente sostenible, pero eso es difícil, por lo que probablemente haga algunas contrataciones el próximo año.

He probado algunas cosas diferentes. Una cosa que hice fue solicitar soporte en el archivo README.md de GitHub. No lo llamaría un anuncio, sino más bien un pequeño banner. Gané un poco de dinero, pero está lejos de poder sostenerme.

Podría darle una oportunidad a Patreon.

¿Cuáles son algunas de las cosas que desea mejorar en el ecosistema de JavaScript?

En mi opinión, el ecosistema de JavaScript ya es excelente, pero todavía tenemos muchas peculiaridades para solucionar en el lado del navegador. Hay tantos proyectos con este script de compilación gigante solo para obtener una aplicación simple, por eso me encanta Node.js.

El problema con los navegadores es que son muy complejos. Tiene la red en la que pensar, necesita optimizar tanto el tamaño como el rendimiento, tiene muchos casos de uso diferentes, marcos para elegir. Todos intentan simplificarlo, pero luego terminas siendo demasiado obstinado, luego agregas la configuración pero hay demasiada repetición. No veo un camino fácil hacia adelante a menos que arregle la plataforma real en lugar de crear muchas soluciones sobre ella. Una cosa que creo que mejorará la situación es cuando finalmente obtengamos módulos en el navegador. Es posible que entonces no necesite un paso de compilación para todo.

¿Por qué los desarrolladores de JavaScript están obsesionados con los unicornios?

De hecho, todo el movimiento de ponis comenzó con la comunidad de Django. Cuando comenzaba a preguntar sobre las funciones que deseaba, los desarrolladores decían "Quiero un analizador HTTP más rápido" o "Quiero un ORM que simplemente funcione". Un día, uno de los desarrolladores principales de la lista de correo de Django respondió a una de las solicitudes de funciones con un "¡no, no puedes tener un pony!" Todo el movimiento del unicornio comenzó con la denegación de esa solicitud de función.

Incluso hay un sitio web dedicado al adorable pony.

No recuerdo exactamente cómo se extendió a la comunidad de JavaScript. Fue una de esas cosas que simplemente sucedieron por sí solas. Tener algo tan divertido y tonto como los unicornios me ayuda a trabajar con la programación y el OSS y me eleva la moral. Lo mismo ocurre con los gifs tontos.

Originalmente publiqué esta entrevista en Between the Wires, una serie de entrevistas que presenta a quienes están construyendo productos para desarrolladores y diseñadores.

Este proyecto es posible gracias a los patrocinios de frontendmasters.com, egghead.io, Microsoft Edge y Google Developers.