Sí tienes tiempo para construirlo dos veces

Rate this content
Bookmark

Si no tienes tiempo para construirlo correctamente, ¿cuándo tendrás tiempo para construirlo dos veces? En las startups de crecimiento acelerado, el viejo dicho se desmorona. Obtienes un horizonte de tiempo en expansión, SI puedes enviarlo. Una función imperfecta la próxima semana supera a una función perfecta 2 meses después. Tu código no importará si estás muerto. No lo creí hasta que lo vi por mí mismo. Una startup al borde del éxito me contrató para reescribir su aplicación jQuery en React. Su tecnología demostró la idea y luego se convirtió en una carga. Durante el próximo año, reescribimos toda la aplicación desde cero, formamos un equipo de expertos en React, creamos una base de código con la que es un placer trabajar y llevamos a la empresa a una Serie B de $100,000,000. Todo porque los primeros ingenieros sabían que si la versión mediocre funciona, habrá tiempo y recursos para arreglarlo más tarde. Esta charla trata sobre lo que he aprendido al reescribir una aplicación con usuarios golpeando la puerta.

21 min
17 Jun, 2022

Video Summary and Transcription

La charla de hoy se centra en las reescrituras de software, específicamente en la transición de jQuery a React. El orador comparte su experiencia al reescribir una aplicación jQuery en React, destacando los beneficios de la reescritura en términos de mejor experiencia de usuario y mayores conversiones. Se discuten enfoques para las reescrituras de software, incluido el enfoque página por página que permite la innovación del producto. El orador enfatiza la importancia de priorizar las reescrituras o refactorizaciones para las startups. La charla concluye con ideas sobre pruebas, funcionalidad del lado del servidor y el valor general de la reescritura.

Available in English

1. Introducción a las reescrituras de software

Short description:

Hoy quiero hablar sobre las reescrituras de software. Más adelante es el momento mágico en el que todo puede suceder, con más dinero, un equipo más grande, más experiencia y una mejor comprensión del problema. Reescribimos una aplicación de jQuery a React, lo que no ralentizó la velocidad del equipo, sino que en realidad hizo crecer la empresa. jQuery sigue siendo popular, con un 84% de JavaScript de producción que lo utiliza. React ha ganado la Guerra de los Frameworks con un 8% de JavaScript de producción. Se discute la objeción de reescribir desde cero, utilizando el ejemplo de Netscape perdiendo ante IE.

¡Hola a todos! Soy Suez, ingeniero de software, autor y pueden ver que soy legítimo porque hay una gran pantalla detrás de mí. Así que hoy quiero hablarles sobre las reescrituras de software.

¿Quién ha visto esta cita antes? Si no tienes tiempo para hacerlo bien, ¿cuándo tendrás tiempo para hacerlo dos veces? No pude encontrar la atribución de esta cita porque mucha gente la ha dicho. Lo que quiero decirles hoy es que tendrán tiempo para hacerlo dos veces más adelante. Porque más adelante es el momento mágico en el que todo puede suceder. Porque, al menos en una empresa en crecimiento que está yendo muy bien, más adelante también viene con más dinero, un equipo más grande, más experiencia, una mejor comprensión de su problema y simplemente, más adelante es este momento mágico, mágico.

La historia que quiero contarles es cómo reescribimos una aplicación de jQuery, sí, una aplicación de jQuery en el año 2020, de jQuery a React, reescritura completa, partimos desde cero y mientras lo hacíamos no solo no ralentizamos la velocidad del equipo, sino que en realidad hicimos crecer la empresa como cuatro o cinco veces y obtuvimos una ronda de financiación de $100 millones que se anunció en la famosa pantalla de NASDAQ, lo cual, por cierto, no sucede solo para las salidas a bolsa. Si conoces a las personas adecuadas, solo les pagas cien dólares y ya estás allí.

Sé que dije jQuery y quién aquí ha usado jQuery en los últimos tiempos, quién recuerda haber usado jQuery. Bien, bien. ¿Quién ha usado jQuery en 2020 justo antes de la pandemia? Bien, tenemos tres manos. Bien. Así que sé que jQuery es malo, pero en realidad sigue siendo muy popular. Esto es lo que tuiteé justo después de que SWIX, Shawn Wang, diera una charla en React.com en San Francisco hace un par de meses. Resulta que el 84% del JavaScript de producción todavía es jQuery. Y él tiene este bonito gráfico que, está bien, puedes verlo. Si miras el gráfico, hay como jQuery, 84%, luego tienes jQuery Migrate y ni siquiera sé qué es eso. Y luego React está en alrededor del 8% del JavaScript de producción. Sin embargo, eso aún significa que estás en la conferencia correcta porque React 1, porque ninguno de los otros frameworks está en el gráfico. Así que, al tener el 8% de la web, React ha ganado la Guerra de los Frameworks, sí, increíble.

La otra objeción que podrías tener para reescribir y comenzar desde cero es si alguna vez has leído esta publicación de blog que salió en 2020, no, lo siento, no en 2020, en el año 2000 cuando los blogs todavía eran populares, este tipo de software Jolon que más tarde creó Stack Overflow y muchas otras cosas escribió un artículo muy interesante llamado Cosas que nunca deberías hacer y básicamente explica por qué no todos estamos usando Netscape en este momento. ¿Quién recuerda Netscape? Bien. ¿Quién ha usado realmente Netscape? Bien. Bien. Así que hay algunos de ustedes. Él argumenta que Netscape estaba ganando la guerra de los navegadores hasta que decidieron, saben qué, Netscape 4 es un poco malo. Vamos a escribir Netscape 5 desde cero. Y luego IE llegó y se comió su almuerzo.

2. Reescritura de jQuery a React

Short description:

Cuando me uní a la empresa, tenían una aplicación de jQuery con 100,000-200,000 líneas de código. Era difícil trabajar con ella, utilizando variables globales y mixins mágicos. Decidimos reescribirla utilizando React, sin renderizado del lado del servidor. La nueva aplicación no solo se ve mejor, sino que también tiene más conversiones y usuarios más satisfechos. La reescritura nos permitió mejorar el producto y aprovechar lo que aprendimos. Escribir software es como patear una lata, explorando y resolviendo problemas incrementalmente. Nuestra reescritura implicó cambiar y actualizar cosas basadas en los comentarios de los usuarios.

Así que la historia sobre la reescritura de jQuery a React. Cuando me uní a la empresa fue en junio de 2020, y tenían esta pequeña aplicación. ¿Funcionará? Está funcionando. Bien. Así que esta es una aplicación de jQuery. Está grabada en modo móvil porque eso era todo lo que había. Si lo abres en pantalla completa, se vería igual de ancho que se ve ahora. Y esto era aproximadamente de 100,000 a 200,000 líneas de código de jQuery. Nadie sabía exactamente dónde estaban las funciones. Si intentabas mover algo, básicamente explotaba en tu cara. Estaba haciendo todas las mejores cosas de jQuery, variables globales, mixins mágicos que simplemente crean nuevo código. Y mucho de eso funcionaba en el frontend. Y en realidad, aquí está la parte súper divertida. Cuando entré en la empresa, pensé, bueno, tenemos que reescribirlo. Vamos a hacer una SPA basada en React, sin renderizado del lado del servidor, etc. Ahora el renderizado del lado del servidor es popular y todo esto en realidad se renderizaba en el servidor porque así es como se usa jQuery. Tomas express, generas un montón de HTML, luego agregas variables y funciones globales de jQuery y funciona, más o menos.

Esto es lo que tenemos ahora. Está un poco mejor diseñado. Creo que se ve mejor. Hay algunos spinners de carga. En realidad, estamos utilizando React Query, que resolvió muchos de nuestros problemas. Esa fue una de las partes agradables. Y además de verse mejor, también tiene más conversiones, los usuarios están más satisfechos, nuestras puntuaciones de NPS, que es la puntuación del promotor neto sobre cuánto disfrutan los usuarios de tu empresa, tu producto, en realidad aumentaron. Y el punto que estoy tratando de hacer aquí es que no solo reescribimos la aplicación desde cero, también utilizamos todo lo que aprendimos para mejorar el producto en sí y la reescritura fue lo que nos dio la capacidad de reescribirlo.

Y eso se debe a que escribir software es como patear una lata, ya sabes, cuando estás caminando, es un bonito domingo, el sol brilla y estás caminando por la calle y hay una lata, obviamente, te acercas y pateas la lata. Y luego sigues caminando y la lata rebota y va al otro lado y la pateas desde ese lado, y estás yendo hacia donde va la lata, ¿verdad? Y así es como funciona el software también. El software se trata de explorar y descubrir de manera lúdica tu espacio de problemas, como patear una lata, ya sabes, tienes este pequeño problema y lo vas a resolver, pateas la lata un poco más lejos por el camino, luego vas a donde el software te lleva y dices, okay, ahora sé mejor, tengo que intentar patearla más en esa dirección. Así que eso es básicamente de lo que se trató nuestra reescritura. Estábamos cambiando cosas, actualizando, obteniendo comentarios de los usuarios, y esa es la parte importante, porque cuando tienes un código malo, el esfuerzo que se necesita para hacer un cambio aumenta exponencialmente.

3. Enfoque para una Reescritura

Short description:

Construir una buena versión de una aplicación lleva tiempo y esfuerzo, pero es más fácil hacer mejoras una vez que tienes una base sólida. React ofrece flexibilidad y facilidad de mantenimiento del código en comparación con jQuery. El espacio de oportunidad radica en el equilibrio entre el desarrollo rápido y el código de calidad. Las startups deben priorizar completar reescrituras o refactorizaciones antes de que sea demasiado tarde. Enfoques como el patrón Estrangulador o la reescritura del Barco de Tethius permiten la sustitución gradual del código. Dos enfoques comunes son de arriba hacia abajo, reemplazando páginas enteras, y de abajo hacia arriba, creando una isla de React dentro de la aplicación existente.

Por lo general, construir la primera versión de una aplicación mediocre es muy fácil. Puedes hacerlo de la noche a la mañana, como un primer prototipo, puedes hacerlo de la noche a la mañana, eres increíble. Yo no puedo, soy viejo. Así que haces la primera versión, y es muy rápida, y la lanzas al mercado. Pero si te tomas el tiempo para construir una buena versión y tratas de seguir todas las mejores prácticas, todos los consejos de los libros de texto, te llevaría mucho tiempo construirlo. Sería más difícil empezar.

Así que esa es la curva del buen código, es muy difícil empezar, pero una vez que lo tienes, es más fácil seguir adelante y hacer mejoras, porque, especialmente con React, una de mis cosas favoritas de React, comparando el código de jQuery con el código de React, fue que con jQuery no quiero tocar nada. Si mueves una función a un archivo diferente, no tienes idea de lo que se va a romper. Con React, puedes simplemente entrar, tomar una función, y porque todo está contenido en sí mismo y solo se basa en props y todo eso, puedes moverlo a otro lugar y VSCode arregla tus importaciones y todo funciona genial. Así que obtienes mucha flexibilidad, lo cual, una vez que tienes mucho código y más ingenieros, facilita el trabajo en equipo.

Pero ese espacio en las gráficas, donde el código malo es rápido para empezar y luego se vuelve muy difícil, y el buen código es lento para empezar y luego se vuelve muy fácil, eso es lo que yo llamaría tu espacio de oportunidad. Si, maldición, ¿cómo iba a explicar esto? Así que, ese es tu espacio de oportunidad. Ahí es donde puedes obtener mucha retroalimentación muy rápidamente y comenzar a usarlo en una reescritura que te permita mejorar y obtener un código mejor. Y lo que esperas lograr es que antes de que esas dos líneas se crucen, si tu reescritura o tus refactorizaciones o mejoras no están listas, mueres. Y esa es la parte divertida de trabajar en startups. Es como, o lo terminamos o en realidad no importa porque a nadie le importa una startup cuyo código ya no se utiliza. Podría usar un ejemplo muy impactante allí. Pero de todos modos, ¿cómo te acercas a una reescritura, verdad? Estoy seguro, en realidad, ¿quién aquí ha abogado por dejar de trabajar en características y reescribir el código? Sí. ¿Quién tiene un backlog de ingeniería al que nunca llega? Exactamente. Y la razón por la que eso sucede es porque las personas de negocios no son tan estúpidas como podrías pensar. No tienes tiempo para detener la empresa y simplemente trabajar en la deuda técnica, porque así es como murió Netscape. No fue porque estaban reescribiendo, es porque dijeron, no vamos a tener una nueva versión del software durante tres años mientras hacemos esto. Y eso no funciona. Lo que funciona es algo llamado el patrón Estrangulador, o también he oído que se llama la reescritura del Barco de Tethius, donde reemplazas lentamente tu código pieza por pieza hasta que no quede nada de tu código antiguo. En realidad no recuerdo por qué se llama el patrón Estrangulador. No se trata de agarrar el código antiguo y estrangularlo hasta que desaparezca. Tiene una historia de origen mucho más agradable. Creo que tiene algo que ver con las enredaderas en la jungla. Así que hay dos formas de abordar esto. Cuando estás construyendo una nueva característica o agregando funcionalidad a tu aplicación, puedes decidir ir de arriba hacia abajo, donde reemplazas páginas enteras con nueva funcionalidad, o puedes ir de abajo hacia arriba, donde creas algo como, en mi empresa, lo llamamos una isla de React, donde básicamente construyes un complemento similar a jQuery que renderiza React en un div.

4. Enfoque por Página

Short description:

El enfoque por página para reescribir una aplicación completa es más fácil y proporciona una experiencia de usuario más fluida. Los usuarios pueden transicionar entre las versiones antiguas y nuevas de la aplicación, pero siempre y cuando se mantenga la continuidad del diseño, a los usuarios no les importan los cambios.

En realidad, eso funciona muy bien. Si estás reescribiendo una aplicación completa, si tienes tiempo para reescribir toda la aplicación, el enfoque por página es, en mi opinión, mucho más fácil. Lo que hicimos fue que durante aproximadamente un año o seis meses, algo así, tuvimos una experiencia un poco defectuosa. Los usuarios usaban la aplicación GQuery, hacían clic en un botón aleatorio y terminaban en la hermosa y rediseñada aplicación React, y luego hacían clic en otro botón y volvían a la tierra de GQuery, que se veía bastante mal. Como usuario, es como, ¿qué diablos está pasando aquí? Creo que el mejor ejemplo de esto en la práctica que he visto fue en mi banco, donde la página de inicio de sesión era increíble y hermosa, y luego hacías clic en iniciar sesión y estabas en esta antigua y defectuosa aplicación que parecía haber sido diseñada hace 10 años. Pero siento que, como personas, como usuarios, estamos acostumbrados a estas rediseños, así que mientras los diseñadores hagan un trabajo realmente bueno y mantengan esa continuidad del diseño, o como quieras llamarlo, a los usuarios realmente no les importa. Ellos entienden, sí, sabes, un nuevo BMW sale cada año y tiene parrillas más grandes y más grandes y más grandes, pero sigue siendo un BMW, reconoces que es un BMW, sabes que es un coche, sabes cómo conducirlo y las cosas principales siguen siendo las mismas, pero las pequeñas cosas siguen cambiando.

5. Beneficios del Enfoque por Página

Short description:

El enfoque por página permite la innovación del producto, no solo correcciones de código. Comenzar con una patineta y gradualmente construir un producto increíble es un proceso gratificante. Los gerentes de producto aman las reescrituras porque pueden enfocarse en nuevas características sin lidiar con problemas heredados. Innova en el producto, no en el esquema de precios. A pesar de los desafíos, reescribir la aplicación de jQuery a React valió la pena, lo que resultó en una mayor valoración. Estoy escribiendo un libro sobre refactorizaciones y reescrituras. Si estás interesado, escanea el código QR para recibir actualizaciones.

Y el enfoque por página también te brinda una excusa o una oportunidad para hacer innovación del producto. No solo estás arreglando el código, también estás arreglando cómo funciona el producto. Comienzas con una patineta, luego construyes un scooter, lo conviertes en una bicicleta, luego tienes una motocicleta y al final tienes un increíble BMW o Porsche, o simplemente un automóvil genial que a todos les encantará.

Y en mi experiencia, a los gerentes de producto realmente les encanta si lo haces de esta manera, porque también odian lidiar con cosas heredadas. Les encantaría tener solo nuevas características y ellos vienen con esta gran idea y tú dices: sí, sabes qué, eso va a ser muy fácil, podemos construirlo porque estamos desechando todo el código antiguo y lo estamos haciendo en el nuevo estilo que es más rápido de trabajar, por lo que no tenemos que lidiar con todo lo demás, porque déjame decirte, en una empresa anterior que tuvimos, arrastramos alrededor de cinco años de producto, de iteración del modelo de precios y el gerente de producto vino a mí y me dijo: hey, ¿podemos agregar este nuevo tipo de cobro a los usuarios? Y yo le dije: sí, podemos cobrarles de una manera diferente. Va a tomar tres meses agregar eso. Y desafortunadamente decidimos agregarlo y una lección que aprendí es que nunca debes innovar en la preparación, en tu esquema de precios. Las personas solo quieren pagar por mes y no les importa nada más. Simplemente no vale la pena. Pero sí innova en el producto, innova en lo que realmente están usando los usuarios.

Al final del día, pasamos un año entero reescribiendo la aplicación desde cero. Ahora, si vas a nuestra plataforma y haces clic en ciertos botones, todavía regresas al antiguo mundo de jQuery, porque no pudimos actualizar el backend. Y la pregunta podría ser, ¿valió la pena? ¿Valió todo este esfuerzo? ¿Valió la pena invertir el esfuerzo en reescribir la aplicación de jQuery a React? Y honestamente, en cierta medida, sí lo valió. Cuando recaudamos la ronda, como la ronda de cien millones de dólares, nuestro esfuerzo valía aproximadamente medio millón de dólares por empleado, pero la valoración aumentó a alrededor de tres millones. Puede valer la pena si tu empresa está en la trayectoria correcta.

Y por favor, escucha la última línea de mi tweet allí. Tienes mucho valor para tus empleadores, negocia eso y obtén un buen salario. Y, de hecho, en este momento estoy escribiendo un libro basado en esta experiencia. Profundizará mucho más en cómo funcionan las refactorizaciones y las reescrituras. Y si quieres recibir una notificación cuando esté listo, ese es el código QR para ti. Y eso es todo lo que tenía que decir. Buen trabajo, hombre. Gracias. Sí. Oh, hay líneas en el suelo. Entonces, Swissec, charla refrescante. Estaba pensando en una experiencia que tuve cuando estaba entrevistando en una empresa que en ese momento estaba decidiendo construir su primer prototipo. ¿Y vamos a usar jQuery, bootstrap o vamos a construirlo adecuadamente? Y para mí, esa fue una decisión difícil, porque no quería ir con ellos si decidían ir al mundo de jQuery con bootstrap. Soy un poco snob, tal vez. Pero ¿qué te hizo decidir realmente querer hacerlo? Esa es en realidad una historia muy divertida, porque cuando el jefe de ingeniería me propuso reescribir su aplicación de jQuery a React, dijo que necesitábamos hacer esto porque era imposible contratar ingenieros para que vinieran a trabajar en jQuery.

QnA

Experiencia con React y Aplicación Mobile-first

Short description:

Nadie quiere hacer esto. Tengo la oportunidad de diseñar toda la experiencia de React, establecer el futuro de la empresa. Me uní cuando la parte de React jQuery ya estaba en producción. Buena experiencia. Pregunta de un anónimo: ¿La aplicación sigue siendo mobile first? Sí, es mobile first, funciona en todas partes y se adapta automáticamente. Las estadísticas muestran un cambio de móviles a laptops. Protegiéndonos contra el alcance excesivo: únete a una empresa en crecimiento rápido con usuarios que demandan innovación.

Nadie quiere hacer esto. Y sí, por eso me uní. Porque era como, sí, tengo la oportunidad de diseñar toda la experiencia de React, el framework, establecer el futuro de la empresa, y creo que hasta ahora ha funcionado bien.

¿Entonces te uniste cuando la parte de React jQuery ya estaba en producción? De acuerdo. Sí. Así que me uní cuando eso ya estaba listo. Era lo mejor que sabían en ese momento. Era la forma más rápida de construirlo. Sí. Y luego dijeron, necesitamos un experto en React que venga y lo arregle por nosotros. Y tú eres el indicado para hacerlo. Bueno, buena experiencia.

Entonces vamos a pasar a las preguntas de la audiencia. Pregunta de un anónimo. ¿La aplicación sigue siendo mobile first? Creo que lo mostraste, ¿verdad? Sí. ¿Verdad? Así que estamos usando un framework de componentes de CSS. Como dije, un framework de CSS y JS llamado Team UI. Es muy receptivo. Así que la aplicación es mobile first, pero funciona en todas partes y se adapta automáticamente. Esa fue una de las razones por las que reescribimos, porque podíamos hacerlo más fácil con herramientas modernas. Pero ¿todavía ves en tus estadísticas que tal vez nueve de cada diez personas todavía acceden desde móviles porque están acostumbradas a acceder al producto desde el móvil? Y en realidad eso desapareció lentamente. A medida que la aplicación comenzó a funcionar mejor en los navegadores, la gente empezó a usar más las laptops. Y probablemente también hay nuevos usuarios que no sabían que no había una experiencia de escritorio. Sí. Bueno. ¿Cómo te proteges del alcance excesivo cuando se trata de la producción, la innovación del producto mientras se reescribe? De acuerdo. El alcance excesivo es principalmente... Honestamente, la mejor solución que encontré para el alcance excesivo es unirse a una empresa que está creciendo muy rápido y tiene usuarios que están demandando a la puerta.

Pruebas, Funcionalidad del lado del servidor y Conclusión

Short description:

No tuvimos tiempo para hacer la reescritura perfecta, ya que estábamos perdiendo usuarios al no poder enviar rápidamente. Algunas pruebas en la antigua aplicación ya no eran aplicables debido a la reimaginación y mejora de la aplicación. La funcionalidad del lado del servidor fue manejada por una aplicación Express, utilizando llamadas API en lugar de renderizar HTML con jQuery. El equipo de backend hizo un gran trabajo. Gracias por su tiempo.

Sí. Porque entonces todos están de acuerdo en que debemos sacarlo rápidamente. No tenemos tiempo para hacerlo perfecto porque literalmente estamos perdiendo usuarios al no poder enviar. Eso hace que sea muy fácil decirles a tus PMs, ey, no tenemos tiempo para esto. Sí, hay que seguir adelante.

Y luego, en la aplicación antigua, ¿se escribieron pruebas o simplemente tuviste que esperar que lo que reescribiste fuera lo mismo? Había algunas pruebas en la antigua aplicación. El beneficio de nuestra reescritura fue que los PMs también querían mejorar el producto. Así que todas las pruebas antiguas simplemente ya no eran aplicables porque las características eran diferentes. No fue solo una reescritura desde una perspectiva técnica, también fue una reimaginación y mejora de la aplicación.

Sí, está bien, no fue una reescritura uno a uno. Sí, no fue una reescritura uno a uno. Así que es como, ya sabes, estás convirtiendo un submarino en un barco, no muchas pruebas siguen siendo aplicables. Sí, tal vez una o dos pruebas, se realiza esta llamada backend, pero eso es todo. Sí, exactamente.

De acuerdo. Y luego, ¿hubo alguna funcionalidad del lado del servidor? Y si es así, ¿qué framework o biblioteca usaste? Había mucha funcionalidad del lado del servidor, porque esta era una aplicación Express que estaba renderizando HTML y luego jQuery se encargaba. Así que tenían, básicamente, hidratación antes de que supiéramos sobre la hidratación. Así que todo el backend se mantuvo. Lo convertimos en llamadas API y ahora estamos reescribiendo lentamente el backend también. Está escrito en Express, Node.js con JavaScript puro.

De acuerdo, suena como una sólida ingeniería de software. Sí, el backend hizo un gran trabajo. Bueno, eso es todo el tiempo que tenemos para SwissEx, así que te agradezco. Bueno tenerte aquí. ¡Un gran aplauso, por supuesto!

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Top Content
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.
React Summit 2022React Summit 2022
27 min
Impact: Growing as an Engineer
Top Content
Becoming a web engineer is not easy, but there are tons of resources out there to help you on your journey. But where do you go from there? What do you do to keep growing, and to keep expanding the value you bring to your company? In this talk we’ll look at the different kinds of impact you can have as a web engineer. We’ll walk through what it means to take on bigger, more complex projects, and how to scale yourself, and grow the community around you. By driving our own development we can all grow our impact, and in this talk, we’ll discuss how to go about this.
TechLead Conference 2023TechLead Conference 2023
25 min
On Becoming a Tech Lead
Tech lead sounds like a lot of work. And not the fun coding kind either. Why would you ever want that? What does it feel like when you get it?In this talk Swizec explains why he took the step towards technical leadership, how his priorities changed, and why it means he’s doing more engineering than ever. A whole new world where writing code is the easy part.
10 min
Emma Bostian: I landed my dream job by sharing my blogs on Twitter
Top Content
Featured Article
Software engineer, lecturer, podcast host, author — is there something Emma Bostian hasn't done? She moved from America to Sweden, started working at Spotify, and took up a few challenges along the way. And now she has some career tips to share.

What led you to software engineering? 
I was raised in the ecosphere of tech because my dad is a software engineer at IBM, and my mom was a designer there, too. My dad always encouraged me to join STEM and take a look at computer science — however, I was convinced I wanted to be a medical doctor. In my first year of college, I declared a biology major and quickly realized I was not too fond of it. In my second semester, I switched to an actuarial science major where I took Introduction to Computer Science, and the rest is history. In my second year of college, I declared a computer science major and began my journey from there.
What is the most impactful thing you ever did to boost your career?
Writing blog posts and documenting my learning journey on Twitter has far been the best career boost. I wrote purely for myself to reference the things I learned over time, and I even utilized my design skills in Figma to create custom graphics depicting difficult concepts like CSS specificity. By sharing my blogs on Twitter and engaging with the people reading them, I was able to grow an audience extremely quickly. I began receiving conference speaking opportunities, podcast requests, and course invitations to teach with LinkedIn Learning and Frontend Masters.
Ultimately, I landed my job at Spotify through Twitter, too, when a friend and follower of mine asked if I would be interested in interviewing. Now I live in Stockholm working my dream job. It still blows my mind how tweeting about my blog led me to some of the most amazing career opportunities.
What would be your three tips for engineers to level up their career? 
First, be patient. I often see posts on Twitter or LinkedIn about developers who were promoted to a senior position after a year. And while this is wonderful, I think we forget that each company has a different standard for what constitutes a senior developer, and everyone's journey will be different.
Second, don't be afraid to ask questions. If you try your best to solve a problem or answer a question you have, but you can't figure it out after a reasonable amount of time, ask a team member or mentor for help.
And lastly, invest in the right resources for learning. When I started my journey, I didn't know which platforms worked for me to learn. Now, I have a few trusted platforms such as Frontend Masters, Free Code Camp, or Level Up Tutorials that I go to when I need to learn a new skill.
You're currently working as a software engineer at Spotify. What does a typical day of yours look like there?
I begin my day answering emails. Then we have a team breakfast and a standup remotely as we're all still remote at Spotify. After that, we might have a web tech sync with the other squads in our business unit. The day usually includes some form of pair or mob programming, depending on the work stream. 
My team always has Fika, a traditional Swedish coffee break, scheduled every afternoon. Every couple of Fridays, we have team games planned to release some stress. 
Also, I tend to have a lot of free time to focus, which is nice but makes for a boring answer to this question!
Do you have some rituals or tools that keep you focused and goal-oriented?
I'll admit that I've been struggling with staying motivated in the time of remote work. I've been remote with Spotify since onboarding a year ago, but my team is wonderful, and they help me when I'm down.
Apart from that, I use Todoist to keep track of my tasks, and, naturally, I listen to Spotify while working. But other than that, not really. Maybe I should adopt some new tools to keep me on track!
My current favorite Spotify playlist is Brand New Chill: https://open.spotify.com/playlist/37i9dQZF1DX6uQnoHESB3u?si=380263b3c853442e
I also love Chillout Daily: https://open.spotify.com/playlist/7ozIozDp260fjNOZy1yzRG?si=66d6c839ec9b458a
You wrote a book called De-coding the Technical Interview. What was the impulse to do it?
I wanted to give the community a manual of the essentials of computer science knowledge to ace the technical interviews. The book covers data structures like stacks, queues, or linked lists, tackles algorithms, and deals with systems design. You'll also learn about the interview process from start to finish, get tips on how to submit an amazing take-home project, or understand how to problem solve. You'll also gain knowledge on the frontend coding skills needed to excel at a frontend interview.

If you could stress one piece of advice on surviving a technical interview, which would it be?
Do not lie your way through an interview. If you don't know the answer to something, just admit it. There's no shame in admitting you don't know the answer to something. There is shame in faking it and pretending like you do know the answer.
What's the single best practice everyone who writes code should follow?
Remember that while you are technically writing code for computers, you're also writing it for humans. Your code should be readable and have as little complexity as possible without sacrificing accessibility or performance.
In addition to the book, you co-host the Ladybug Podcast. What inspired you to enter this field, and what are the podcast's main topics?
We talk about everything tech and career on the podcast, from Java and GraphQL to how to start a business and cross-cultural communication. The podcast is a way for me and my co-hosts to share our experiences in tech, having taken different paths. And I'm really glad for doing it — it has allowed me to meet so many incredible people, learn many new things, and support my dream of teaching.
What pieces of your work are you most proud of?
My technical interview book was a huge feat for me as well as my courses with LinkedIn Learning on building a tech resume. I enjoy creating things that help other people advance their careers, so I'm also proud of my courses with Frontend Masters on design systems and CSS.
***
Follow Emma on Twitter
14 min
Kent C. Dodds: Consume, build, and teach — and level up your career
Top Content
Featured Article
Even though his bio offers quite a hefty reading, he only applied for one job in his career. The rest came along as he was building his name as a renowned speaker, teacher, and a prolific figure of the open-source community. How did Kent do it? “Commit to creating high-quality content,” he says.


What led you to programming?
I had a friend when I was a teenager who was really into it, and he tried to teach me. But I just couldn't get it — it didn't make any sense to me. So I never really thought I'd get into programming, but I liked computers a lot, and I ended up going to school for electrical engineering. 
Well, that didn't work because I'm not good at math. But right when I started the program, I got a job at a company uploading videos to YouTube and that sort of thing. The work was tedious, so I decided to write a computer program to automate lots of the work I was doing with the knowledge I had about programming. And that was the first spark of things for me to use programming to solve real-world problems. 
What is the most impactful thing you ever did to boost your career? 
Committing to creating high-quality content. That might sound obvious because I'm a full-time educator now, but I would not have gotten my job at PayPal if I hadn't been so active with my blog. In fact, lots of my jobs came out of me being involved in the community around meetups, conferences, or open-source projects. 
How do you choose topics for the content you create, be it for your blog or podcast?
I don't think too much about the content other people are creating. And I don't often consume it. My ideas come from the things that I'm working on, things that I'm learning myself, or — when I was working with a team of developers — the things that I had to remind people of in code reviews regularly. Anytime that I would have a code review comment that was pretty long to describe my position, that was an excellent opportunity for a blog post. Also, if people ask me about a topic regularly, I'll make a blog post rather than answer that question multiple times.


What would be your three tips for engineers to level up their career? 
The number one thing I tell people is to be a nice person. I know that sounds fluffy or silly, but it cannot be overstated. You will get so much further in your career and just in life in general if you're a nice person. That doesn't mean that you take people being jerks lying down, but how you interact with others is out of kindness. You could be the best engineer in the entire world, but if you're not a nice person, you will not reach your full potential or accomplish your goals, whatever they may be.
Second, it's just as important to decide what you are not going to learn as it is to decide what you are going to learn. You could jump into countless things — and there are successful people who are polyglot programmers, but I can't speak to that a whole lot. All I can tell you is that in my experience, focusing on specific things that I want to be truly good at has worked out great for my career. That doesn't mean that I closed myself off to other things. With my website rewrite, I have been doing a lot of dev ops-related work and a lot of back-end stuff that I've typically not been involved in. You want to keep your head up on what's going on outside of what you're doing so that you know what direction to go in when you come across problems you need to solve. However, finding a focus on what you want to be good at has helped me a lot. That way, you feel a little less stressed.
And the third one? 
Learn how to learn effectively. It's a three-step process: you consume, build, and teach. The consumption of newsletters and Twitter and whatever inspires you, but you don't want to spend too much time doing that — implementing it into actually building something matters. This happens naturally if you work at a company, but maybe you're not making the things you want to learn, so you may want to start a side project. The building phase is where you get experience, but you also want to solidify that experience. How? You start teaching. You don't necessarily have to teach it to people, it could be stuffed animals. The goal of the teaching is to retain in your mind what you've learned through the building process.
What are you working on right now? 
The big thing I'm working on right now is a rewrite of my website. It'll be much more than just a developer portfolio — I'll have user accounts, and there'll be fun things that you can do with it. And because it's more than just a website, I'm using Remix, a new cool framework in the React ecosystem. I'm also working on updating my material on TestingJavaScript.com and a TypeScript course as well. 
So, whatever I'm working on, it ends up resulting in lots of opportunities for content.


Do you have some rituals that keep you focused and goal-oriented? 
I have a notepad where I keep all of my notes of what I'm going to do for the day so that when I'm checking things off, I'm not distracted notifications. I've tried apps for that, and that does not work well for me. 
I also am a firm believer in inbox zero. I have my work inbox and my personal inbox, and I keep them both at zero. And I kind of use that as a to-do list. 
And if I'm not feeling excited about working for some reason, I will often hop on my Onewheel, which is an electric skateboard that only has one giant wheel in the middle. It's just a total blast, and I'll hop on that with my backpack and a charger, and I'll go to a Starbucks or a park just to declutter my mind.
What things in the React universe are you excited about right now?
React version 18 is coming out soon. The experimental version is out there, and it's fun to play with. I'm just really thrilled that it's no longer a concurrent mode but concurrent features that you can opt into. Cool things like that will enable React server components in the future. 
But the biggest thing I'm excited about is Remix. That's huge. It eliminates a lot of problems that are solved well other tools, but when I'm using Remix, I don't have those problems, so I don't need those clusters.
You already said that teaching is an integral part of the learning process, and you stand your word since you're also a full-time educator. What inspired you to enter this field?
I have been a teacher for as long as I can remember. I grew up in a church where you talk in front of your peers from a very young age, and my mom was an elementary school teacher, so teaching has just always been a part of me. 
I really just enjoy sharing what I'm learning with others. As far as teaching technical topics, I gave my first workshop when I was still a student at Brigham Young University. With my fellow, we taught how to use AngularJS, and I got Firebase to sponsor pizza so they would show up, and that was pretty fun.
Then I started teaching on the side at egghead.io right after I'd graduated. That was when I first got a paycheck for teaching. And I realized that teaching could be quite lucrative and support my family and me as a full-time endeavor. So I did it — I quit my job. I'm a very risk-averse person, so I'd done teaching as a side hustle for four years just to verify that I could make this work.
When TestingJavaScript was released, and I got that paycheck, I realized that I didn't need my PayPal salary anymore. I could just focus my daytime on teaching and give my evenings back to my family, which was a nice trait.


Apart from that, how has teaching impacted your career? 
Earlier I mentioned that pretty much all of my jobs came because I was perceived as an expert. After the first job, where I was an intern and then converted into full-time, I never applied to another. I worked for four different companies, and they wouldn't have recruited me if they didn't know who I was and what I was doing. My content is how they knew who I was — I just made it easy for them to find me. Teaching made that impact. It made my career. 
We talked about React and Remix. Are there any other open-source projects that you'd recommend keeping an eye on or contributing to?
I have some myself. React Testing Library is probably the biggest one that people are familiar with. And if React isn't your jam, then other framework versions of the testing library. 
React Query is also really popular. If you're using Remix, you don't need it, but if you're not, I strongly advise using React Query cause it's a stellar, fantastic library, and Tanner Linsley, the creator, is a stellar and fantastic person. 
What pieces of your work are you most proud of? 
Probably the biggest thing I've ever done is EpicReact.Dev. It has helped tens of thousands of people get really good at React, improve their careers and make the world a better place with the skills that they develop. My whole mission is to make the world a better place through quality software, and I feel like I've done that best with Epic React. 
There are things that I've built at other companies that are still in use, and I'm proud of those cause they've stood the test of time, at least these last few years. But of everything, I think Epic React has made the biggest impact.
***
Follow Kent on Twitter and listen to his favorite Spotify playlist
React Day Berlin 2022React Day Berlin 2022
22 min
Jotai Atoms Are Just Functions
Top Content
Jotai is a state management library. We have been developing it primarily for React, but it's conceptually not tied to React. It this talk, we will see how Jotai atoms work and learn about the mental model we should have. Atoms are framework-agnostic abstraction to represent states, and they are basically just functions. Understanding the atom abstraction will help designing and implementing states in your applications with Jotai

Workshops on related topic

React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Top Content
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
React Summit 2022React Summit 2022
136 min
Remix Fundamentals
Top Content
Featured WorkshopFree
Building modern web applications is riddled with complexity And that's only if you bother to deal with the problems
Tired of wiring up onSubmit to backend APIs and making sure your client-side cache stays up-to-date? Wouldn't it be cool to be able to use the global nature of CSS to your benefit, rather than find tools or conventions to avoid or work around it? And how would you like nested layouts with intelligent and performance optimized data management that just works™?
Remix solves some of these problems, and completely eliminates the rest. You don't even have to think about server cache management or global CSS namespace clashes. It's not that Remix has APIs to avoid these problems, they simply don't exist when you're using Remix. Oh, and you don't need that huge complex graphql client when you're using Remix. They've got you covered. Ready to build faster apps faster?
At the end of this workshop, you'll know how to:- Create Remix Routes- Style Remix applications- Load data in Remix loaders- Mutate data with forms and actions
Vue.js London Live 2021Vue.js London Live 2021
169 min
Vue3: Modern Frontend App Development
Top Content
Featured WorkshopFree
The Vue3 has been released in mid-2020. Besides many improvements and optimizations, the main feature of Vue3 brings is the Composition API – a new way to write and reuse reactive code. Let's learn more about how to use Composition API efficiently.

Besides core Vue3 features we'll explain examples of how to use popular libraries with Vue3.

Table of contents:
- Introduction to Vue3
- Composition API
- Core libraries
- Vue3 ecosystem

Prerequisites:
IDE of choice (Inellij or VSC) installed
Nodejs + NPM
JSNation 2023JSNation 2023
174 min
Developing Dynamic Blogs with SvelteKit & Storyblok: A Hands-on Workshop
Featured WorkshopFree
This SvelteKit workshop explores the integration of 3rd party services, such as Storyblok, in a SvelteKit project. Participants will learn how to create a SvelteKit project, leverage Svelte components, and connect to external APIs. The workshop covers important concepts including SSR, CSR, static site generation, and deploying the application using adapters. By the end of the workshop, attendees will have a solid understanding of building SvelteKit applications with API integrations and be prepared for deployment.
React Summit 2023React Summit 2023
106 min
Back to the Roots With Remix
Featured Workshop
The modern web would be different without rich client-side applications supported by powerful frameworks: React, Angular, Vue, Lit, and many others. These frameworks rely on client-side JavaScript, which is their core. However, there are other approaches to rendering. One of them (quite old, by the way) is server-side rendering entirely without JavaScript. Let's find out if this is a good idea and how Remix can help us with it?
Prerequisites- Good understanding of JavaScript or TypeScript- It would help to have experience with React, Redux, Node.js and writing FrontEnd and BackEnd applications- Preinstall Node.js, npm- We prefer to use VSCode, but also cloud IDEs such as codesandbox (other IDEs are also ok)