Tienes Tiempo para Construirlo Dos Veces

Rate this content
Bookmark

Si no tienes tiempo para construirlo bien, ¿cuándo tendrás tiempo para construirlo dos veces? En las startups de crecimiento hiperactivo, el viejo adagio se desmorona. Obtienes un horizonte de tiempo en expansión, SI puedes hacer que se envíe. Una característica imperfecta la próxima semana supera a la característica perfecta dentro de 2 meses. Tu código no importará si estás muerto. No creí esto hasta que lo vi yo mismo. Una startup al borde del hockeystick me contrató para reescribir su aplicación jQuery en React. Su tecnología probó 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 un código base que es un placer trabajar con él, 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 de mala calidad funciona, habrá tiempo y recursos para arreglarlo más tarde. Esta charla es sobre lo que he aprendido mientras reescribía una aplicación con usuarios golpeando la puerta.

Swizec Teller
Swizec Teller
21 min
17 Jun, 2022

Comments

Sign in or register to post your comment.

Video Summary and Transcription

La Charla de hoy se centra en las reescrituras de software, específicamente la transición de jQuery a React. El orador comparte su experiencia de reescribir una aplicación jQuery a React, destacando los beneficios de la reescritura en términos de mejor experiencia de usuario y aumento de las conversiones. Se discuten los enfoques para las reescrituras de software, incluyendo 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 tarde es el momento mágico cuando 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 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 utilizándolo. React ha ganado las Guerras de Framework con un 8% de JavaScript de producción. Se discute la objeción a reescribir desde cero, utilizando el ejemplo de Netscape perdiendo ante IE.

Hola a todos. Soy Suez. Soy ingeniero de software, autor, y puedes decir 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 construirlo bien, ¿cuándo tendrás tiempo para construirlo dos veces? No pude encontrar una atribución para esta cita porque muchas personas la han dicho. Lo que quiero decirles hoy es que tendrán tiempo para construirlo dos veces más tarde. Porque más tarde es el momento mágico cuando todo puede suceder. Porque, al menos en una empresa en crecimiento que está yendo realmente bien, más tarde también viene con más dinero, un equipo más grande, más experiencia, una mejor comprensión de tu problema, y simplemente, más tarde es este momento mágico, mágico.

La historia que quiero contarles es cómo reescribimos una aplicación jQuery, sí, una aplicación jQuery en 2020, de jQuery a React, reescritura completa, empezamos desde cero, y mientras lo hacíamos no solo no ralentizamos la velocidad del equipo, en realidad hicimos crecer la empresa cuatro o cinco veces y conseguimos una ronda de Serie B de $100 millones que se anunció en la famosa pantalla de NASDAQ, que por cierto, no sucede solo para las IPOs. Si conoces a las personas correctas, puedes simplemente pagarles cien dólares y apareces allí.

Así que sé, sé, sé, dije jQuery y quién aquí ha usado jQuery en el último, quién recuerda haber usado jQuery. Vale, vale. ¿Quién ha usado jQuery en 2020 justo antes de la pandemia? Vale, tenemos tres manos. Genial. Así que sé que jQuery es malo, pero en realidad sigue siendo súper 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% de la producción de JavaScript sigue siendo jQuery. Y tiene este bonito gráfico que, vale genial, puedes verlo. Si miras el gráfico, hay como jQuery, 84%, luego tienes jQuery, Migrate, y yo no sé ni qué es eso. Y luego React está en como el 8% de la producción de JavaScript. Sin embargo, eso todavía significa que estás en la conferencia correcta porque React 1, porque ninguno de los otros frameworks están en el gráfico. Así que, al poseer el 8% de la web, React ha ganado las Guerras de Framework, sí, increíble.

La otra objeción que podrías tener a reescribir y empezar desde cero es si alguna vez has leído esta entrada 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 luego pasó a hacer stack overflow y un montón de otras cosas escribió un artículo realmente genial llamado Cosas que nunca deberías hacer y esencialmente explica por qué no todos estamos usando Netscape ahora mismo. ¿Quién recuerda Netscape? Vale. ¿Quién ha usado realmente Netscape? Genial. Vale. Así que hay un par de ustedes. Hace el argumento de que Netscape estaba ganando las guerras de los navegadores hasta que decidieron, sabes qué, Netscape 4 es un poco malo. Vamos a escribir Netscape 5 desde cero. Y luego IE entró y se comió su almuerzo.

2. Reescritura de jQuery a React

Short description:

Cuando me uní a la empresa, tenían una aplicación jQuery con 100,000-200,000 líneas de código. Era difícil de trabajar con ella, utilizando variables globales y mezclas mágicas. 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 felices. La reescritura nos permitió mejorar el producto y aprovechar lo que aprendimos. Escribir software es como patear una lata, explorando y resolviendo problemas de manera incremental. Nuestra reescritura implicó cambiar y actualizar cosas basándonos en los comentarios de los usuarios.

Entonces, la historia sobre la reescritura de jQuery a React. Cuando me uní a la empresa en junio de 2020, tenían esta pequeña aplicación. ¿Se reproducirá? Se está reproduciendo. Vale. Entonces, esta es una aplicación jQuery. Se grabó en modo móvil porque eso era todo lo que había. Si abres esto en pantalla completa, todavía se vería tan ancho como se ve ahora. Y esto era aproximadamente 100,000, 200,000 líneas de código jQuery. Nadie sabía exactamente dónde estaban todas las funciones. Si intentabas mover algo, básicamente explotaría en tu cara. Estaba haciendo todas las mejores cosas de jQuery, variables globales, mezclas mágicas que simplemente crean nuevo code. Y gran parte de ello estaba trabajando en el frontend. Y aquí está la parte súper divertida. Cuando entré en la empresa, dije, vale, tenemos que reescribir. 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 se renderizaba en el servidor porque así es como se usa jQuery. Tomas express, escupes un montón de HTML, luego añades variables globales de jQuery y funciones 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. Estamos usando en realidad 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 contentos, nuestros puntajes NPS, eso es el puntaje de promotor neto sobre cuánto disfrutan los usuarios de tu empresa, tu producto en realidad subió. 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 reescribir.

Entonces, y eso es porque escribir software es como patear una lata, sabes, cuando estás caminando, es un bonito domingo, el sol está brillando, y estás caminando por la calle y hay una lata, y obviamente, te acercas y pateas la lata. Y luego sigues caminando y la lata rebota y va al otro lado y tú la pateas desde este lado, y estás como yendo a donde va la lata, ¿verdad? Y eso es más o menos cómo funciona el software también. El software se trata de exploración y descubrimiento lúdico de tu espacio de problemas, algo como patear una lata, sabes, vale, tengo este pequeño problema y voy a resolverlo, pateas la lata un poco más lejos por el camino, luego vas a donde te lleva el software y dices, vale, ahora sé mejor, tengo que intentar patearlo más en esa dirección. Entonces, eso es más o menos de lo que se trataba nuestra reescritura. Estábamos cambiando cosas, actualizando, obteniendo feedback de los usuarios, y esa es la parte importante, porque cuando tienes mal code, el nivel de esfuerzo que se necesita para hacer un cambio aumenta exponencialmente.

3. Abordando una Reescritura

Short description:

Construir una buena versión de una aplicación requiere 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 de 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 la finalización de reescrituras o refactorizaciones antes de que sea demasiado tarde. Enfoques como el patrón Strangler o la reescritura del Ship of Tethius permiten el reemplazo gradual del código. Dos enfoques comunes son de arriba hacia abajo, reemplazando páginas enteras, y de abajo hacia arriba, creando una isla React dentro de la aplicación existente.

Generalmente, construir la primera versión de una aplicación mediocre es súper fácil. Puedes hacerlo de la noche a la mañana, puedes hacer como un primer prototipo muy básico, puedes hacerlo de la noche a la mañana eres como, todos ustedes son personas increíbles. Yo no puedo, soy viejo. Entonces haces la primera versión, y es súper rápida, y la lanzas al mercado. Pero si te tomaras el tiempo para construir una buena versión y trataras de seguir todas las best practices, todos los advice de los libros de texto, te llevaría mucho tiempo construirlo. Sería más difícil empezar.

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

Pero ese espacio en los gráficos, donde el mal code es rápido para empezar y luego se vuelve realmente difícil, y el buen code es lento para empezar y luego se vuelve realmente fácil, eso es lo que yo llamaría tu espacio de oportunidad. Si tú, mierda, ¿cómo iba a explicar esto? Entonces, ese es tu espacio de oportunidad. Ahí es donde puedes obtener mucha retroalimentación muy rápidamente y empezar a usarla en una reescritura que te permite mejorar y obtener un mejor code. Y lo que esperas lograr es que antes de que las dos líneas se crucen, si tu reescritura o si tu refactorización o mejoras no están listas, mueres. Y esa es la parte divertida de trabajar en startups. Es como, o lo hacemos o en realidad no importa porque a nadie le importa una startup cuyo code ya no se usa. Podría usar un ejemplo realmente contundente allí. Pero de todos modos, ¿cómo abordas una reescritura, verdad? Estoy seguro, en realidad, ¿quién aquí ha abogado por dejar de trabajar en características e ir a reescribir el code? Sí. ¿Quién tiene una lista de pendientes de ingeniería a la que nunca llegas? 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 ir a trabajar en la deuda técnica, porque eso es cómo murió Netscape. No fue porque estaban reescribiendo, es porque dijeron, simplemente no vamos a tener una nueva versión del software durante tres años mientras hacemos esto. Y eso no funciona. Lo que sí funciona es algo llamado el patrón Strangler, o puedes, también he oído que se llama la reescritura del Ship of Tethius donde reemplazas lentamente tu code pieza por pieza hasta que no queda nada de tu viejo code. En realidad no recuerdo por qué se llama el patrón Strangler. No es como agarrar el viejo code y estrangularlo hasta que desaparezca. Tiene un origen mucho más agradable. Creo que es algo sobre las enredaderas en la selva. Entonces, hay dos formas en que puedes abordar esto. Siempre que estés construyendo una nueva característica o añadiendo funcionalidad a tu aplicación, puedes decidir si vas a 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 React, donde esencialmente construyes un plug-in tipo GQuery que renderiza React en un div.

4. Enfoque Página por Página

Short description:

El enfoque página por página para reescribir una aplicación completa es más fácil y proporciona una experiencia de usuario más suave. Los usuarios pueden pasar de la versión antigua a la nueva de la aplicación, pero siempre que se mantenga la continuidad del diseño, a los usuarios no les importan los cambios.

Eso realmente funciona muy bien. Si estás reescribiendo una aplicación completa, si tienes tiempo para reescribir toda la aplicación, el enfoque página por página es, creo, 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 desordenada. Los usuarios utilizarían la aplicación GQuery, harían clic en un botón aleatorio y terminarían en la hermosa aplicación rediseñada React, y luego harían clic en otro botón y volverían a la tierra de GQuery, que parece terrible. Como usuario, es como, ¿qué demonios está pasando aquí? Creo que el mayor ejemplo de esto en la práctica que he visto fue mi banco, donde la página de inicio de sesión era increíble y hermosa, y luego haces clic en iniciar sesión, y estás en esta vieja aplicación desordenada que parece que fue diseñada hace 10 años. Pero siento que, como personas, como usuarios, estamos acostumbrados a estos rediseños, por lo que siempre que los diseñadores hagan un buen trabajo, y mantengan esa continuidad de diseño, o lo que sea que quieras llamarlo, a los usuarios en realidad no les importa. Entienden, sí, sabes, un nuevo BMW sale cada año y tiene parrillas cada vez 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 son las mismas, pero las cosas pequeñas siguen cambiando.

5. Beneficios del Enfoque Página por Página

Short description:

El enfoque página por página permite la innovación del producto, no solo las correcciones de código. Comenzar con un monopatín y gradualmente construir un producto increíble es un proceso gratificante. A los gerentes de producto les encantan las reescrituras porque pueden centrarse 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, resultando en una mayor valoración. Estoy escribiendo un libro sobre refactors y reescrituras. Si estás interesado, escanea el código QR para actualizaciones.

Y el enfoque página por página también te da una excusa o una oportunidad para hacer producto innovación. No solo estás arreglando el code, también estás arreglando cómo funciona el producto. Comienzas con un monopatín, 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 Este coche genial que a todos les va a encantar.

Y la reescritura en realidad, en mi experiencia, a los gerentes de producto les encanta si lo haces de esta manera, porque también odian lidiar con cosas heredadas. Les encantaría simplemente tener nuevas características y vienen a ti con esta gran idea y tú dices, sí, ¿sabes qué? Eso va a ser realmente fácil, podemos construirlo porque estamos desechando todo el viejo code y lo estamos haciendo en el nuevo estilo que es más rápido para trabajar, así que no tenemos que lidiar con todo lo demás, porque déjame decirte, en una compañía más antigua que tuvimos, como, estábamos arrastrando alrededor de cinco años de producto, de iteración de modelo de precios y el PM vino a mí y me dijo, oye, ¿podemos agregar este nuevo tipo de cobro a los usuarios? Y yo dije, sí, podemos cobrarles de otra manera. Va a tomar tres meses agregar eso. Y desafortunadamente decidimos agregar eso y una lección que aprendí es que nunca innoves en la preparación, en tu esquema de precios. La gente solo quiere pagar por mes y no les importa nada más. Simplemente, no vale la pena. Pero sí innova en el producto, sí innova en lo que los usuarios están usando realmente.

Ahora, al final del día, pasamos un año entero reescribiendo la aplicación desde cero. Ahora mismo si vas a nuestra cosa, si haces clic en ciertos botones, todavía vuelves al viejo mundo de jQuery, porque no pudimos actualizar el backend. Y la pregunta podría ser, ¿valió la pena? ¿Valió la pena todo este esfuerzo? ¿Valió la pena poner el esfuerzo para reescribir la aplicación de jQuery a React? Y honestamente, lo fue. Cuando recaudamos la ronda, como la ronda de cien millones de dólares, fue, nuestro esfuerzo fue esencialmente vale medio millón de dólares por empleado, pero la valoración subió 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í. Vales mucho dinero para tus empleadores, ve a negociar eso y cobra. Y, de hecho, ahora mismo estoy escribiendo un libro basado en esta experiencia. Va a profundizar mucho más en cómo funcionan los refactors y las reescrituras. Y si quieres ser notificado cuando esté listo, ese es el código QR para ti. Y eso es realmente 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 ahora en el momento en que estaban decidiendo construir su primer prototipo. ¿Vamos a JQuery, lo iniciamos, o vamos a construirlo correctamente? Y para mí, esa fue una decisión difícil, porque no quería ir a ellos si decidían ir al mundo de JQuery bootstrap. Soy un poco snob, quizás. ¿Pero qué te hizo decidir que realmente querías hacerlo? Entonces, esa es realmente una historia divertida, porque cuando el jefe de ingeniería me convenció para venir a reescribir su aplicación JQuery a React, dijo, necesitamos hacer esto porque es imposible contratar ingenieros para que trabajen 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 con React, establecer el futuro de la empresa. Me uní cuando la parte de jQuery React ya estaba hecha en producción. Buena experiencia. Pregunta de 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 portátiles. Protegerse contra el alcance excesivo: unirse a una empresa en rápido crecimiento con usuarios que demandan innovación.

Nadie quiere hacer esto. Y sí, por eso fui. Porque era como, sí, tengo la oportunidad de design toda la experiencia con 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 hecha en producción? Vale. Sí. Así que me uní cuando eso ya estaba listo. Era lo mejor que sabían en ese momento. Era lo mejor, era la forma más rápida para ellos de construirlo. Sí. Y luego dijeron, necesitamos un experto en React para que venga y lo arregle para nosotros. Y tú eres el chico para hacerlo. Genial. Bueno, buena experiencia.

Así que vamos a pasar a las preguntas de la audiencia. Pregunta de anónimo. ¿La aplicación sigue siendo mobile first? Creo que lo mostraste, ¿verdad? Sí. ¿Verdad? Así que estamos usando un framework de CSS en componentes. Como dije, un framework de CSS y JS llamado Team UI. Eso es súper adaptable. Así que la aplicación es mobile first, pero funciona en todas partes y se adapta automáticamente. Y esa fue una de las razones por las que reescribimos, porque podríamos hacerlo más fácil con las herramientas modernas. Pero, ¿todavía ves en tus estadísticas que tal vez nueve de cada diez personas todavía acceden a través del móvil porque están acostumbrados a acceder al producto desde el móvil? Y en realidad eso fue disminuyendo lentamente. A medida que la aplicación empezó a funcionar mejor en los navegadores, la gente empezó a acceder más desde los portátiles. Y probablemente también nuevos usuarios que no sabían que no había experiencia de escritorio. Sí. Genial. ¿Cómo te proteges del alcance excesivo cuando se trata de la innovation del producto durante la reescritura? Correcto. El alcance excesivo es principalmente... Honestamente, la mejor solución que encontré para el alcance excesivo es unirme a una empresa que está creciendo realmente rápido y tiene usuarios golpeando la puerta.

Pruebas, Funcionalidad del lado del servidor y Conclusión

Short description:

No tuvimos tiempo de 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 se aplicaban debido a la reinvenció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 con, está bien, vamos a sacar esto rápidamente. No tenemos tiempo para hacerlo perfecto porque literalmente estamos perdiendo usuarios al no poder enviar. Eso hace que sea realmente fácil decirle a tus PMs, oye, no tenemos tiempo para esto. Sí, tenemos que seguir adelante.

¿Y en la aplicación Legacy, había alguna prueba escrita o simplemente tenías 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 se aplicaban porque las características eran diferentes. No era solo una reescritura desde una perspectiva técnica, también era una reinvenció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. Entonces es como, ya sabes, estás convirtiendo un submarino en un barco, no muchas pruebas todavía se aplican. Sí, tal vez una o dos pruebas, se hace esta llamada backend, pero eso es todo. Sí, exactamente.

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

Bueno, parece una sólida ingeniería de software. Sí, el backend, hicieron un gran trabajo. Bien, entonces, eso es todo el tiempo que tenemos para SwissEx, así que voy a agradecerte. Bueno tenerte. ¡Así que, 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

Don't Solve Problems, Eliminate Them
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.
Impact: Growing as an Engineer
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.
On Becoming a Tech Lead
TechLead Conference 2023TechLead Conference 2023
25 min
On Becoming a Tech Lead
Top Content
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.
Emma Bostian: I landed my dream job by sharing my blogs on Twitter
10 min
Emma Bostian: I landed my dream job by sharing my blogs on Twitter
Top Content
Featured Article
Emma Bostian
Emma Bostian
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
Kent C. Dodds: Consume, build, and teach — and level up your career
14 min
Kent C. Dodds: Consume, build, and teach — and level up your career
Top Content
Featured Article
Kent C. Dodds
Kent C. Dodds
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
Jotai Atoms Are Just Functions
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, TypeScript, and TDD
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
Paul Everitt
Paul Everitt
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.
Web3 Workshop - Building Your First Dapp
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Top Content
Featured WorkshopFree
Nader Dabit
Nader Dabit
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.
Remix Fundamentals
React Summit 2022React Summit 2022
136 min
Remix Fundamentals
Top Content
Featured WorkshopFree
Kent C. Dodds
Kent C. Dodds
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
Vue3: Modern Frontend App Development
Vue.js London Live 2021Vue.js London Live 2021
169 min
Vue3: Modern Frontend App Development
Top Content
Featured WorkshopFree
Mikhail Kuznetcov
Mikhail Kuznetcov
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
Developing Dynamic Blogs with SvelteKit & Storyblok: A Hands-on Workshop
JSNation 2023JSNation 2023
174 min
Developing Dynamic Blogs with SvelteKit & Storyblok: A Hands-on Workshop
Top Content
Featured WorkshopFree
Alba Silvente Fuentes
Roberto Butti
2 authors
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.
Back to the Roots With Remix
React Summit 2023React Summit 2023
106 min
Back to the Roots With Remix
Featured Workshop
Alex Korzhikov
Pavlik Kiselev
2 authors
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)