Escalando Rápido – Lecciones de Ingeniería de ~15 Años de Startups Tecnológicas

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

Construir un negocio es una lucha para ver quién consigue más clientes primero. Tienes que adoptar esa mentalidad al escribir código. Como me dijo una vez un viejo jefe: El código limpio no importará si estamos muertos. Tienes que cambiar tu mentalidad de las mejores prácticas a hacer las cosas. Pero no puedes volverte demasiado loco o la deuda técnica te matará. 

This talk has been presented at React Advanced 2024, check out the latest edition of this React Conference.

Swizec Teller
Swizec Teller
27 min
28 Oct, 2024

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Hola, discutiremos cómo escalar rápidamente y las lecciones de ingeniería aprendidas en los últimos 15 años de startups tecnológicas. Escalar involucra tres cosas: negocio, equipo y tecnología. La escalabilidad del negocio depende de las ventas y los costos de adquisición de clientes. La ingeniería es una herramienta que utiliza el negocio. Escalar el equipo es vital ya que los problemas tecnológicos a menudo son problemas de personas. La estructura del equipo afecta la arquitectura y el proceso de desarrollo del producto. Organiza los equipos en función del propósito, no de la tecnología. Pasa menos tiempo siendo bloqueado por otros equipos. Lanza características sin ser bloqueado. Hazte cargo de tu propio desorden. Enfócate en la asociación de ingeniería de productos. Construye más rápido usando ciclos de retroalimentación. Construye soluciones apropiadas para tu caso de uso. Deja ir el ego y experimenta con diferentes enfoques. Los ingenieros se hacen cargo de su propio desorden. Evita el trabajo en progreso. Termina el trabajo y enfócate en arreglarlo después. Ten una conversación antes de escribir código. Escalar la tecnología es más fácil de lo que piensas. Elige un diseño prefabricado. Guarda la innovación para las partes centrales. Elige soluciones existentes. Enfócate en resolver el problema. No pierdas tiempo tratando de predecir la escala futura. La escala te sorprenderá. Haz lo que funcione para tu negocio. Rechaza la complejidad innecesaria. Entiende el costo de las ideas. Modifica la situación para que se ajuste al diseño existente. La arquitectura es como un gráfico de dependencias en tu código. Reduce la complejidad arquitectónica organizando el código en función de lo que hace. Usa modelos verticales y evita crear dependencias excesivas. En el cliente, usa módulos verticales. En el back end, considera una arquitectura orientada a servicios. Comienza con un monolito y transiciona a microservicios si es necesario. Usa carpetas en lugar de microservicios cuando tienes un equipo pequeño. Usa modelos verticales y desarrollo basado en contratos o tipos para definir APIs e interfaces claras. Evita el código altamente interconectado y la duplicación. Enfócate en las estructuras de datos para evitar la complejidad y la necesidad de capas de traducción. Construir capas de traducción puede llevar a una experiencia de usuario lenta. Los equipos verticales alineados con el código vertical permiten una rápida resolución de problemas, control total de las características y manejo eficiente de datos. Comprender todo el dominio permite un desarrollo más rápido con menos errores.

1. Scaling Fast and Engineering Lessons

Short description:

Hola, hablaremos sobre escalar rápidamente y las lecciones de ingeniería aprendidas en los últimos 15 años de startups tecnológicas. Escalar implica tres cosas: negocio, equipo y tecnología. La escalabilidad del negocio depende de las ventas y los costos de adquisición de clientes. La ingeniería es una herramienta que utiliza el negocio. Escalar el equipo es vital ya que los problemas tecnológicos a menudo son problemas de personas. La estructura del equipo afecta la arquitectura y el proceso de desarrollo del producto.

Hola, soy Swiss, y vamos a hablar sobre escalar rápidamente y algunas de las lecciones de ingeniería que aprendí en los últimos 15 años haciendo startups de tecnología.

Has construido algo que la gente quiere, y está creciendo súper rápido. ¿Ahora qué vas a hacer? Hay tres cosas que vas a necesitar para escalar. Vas a tener que escalar el negocio, el equipo y la tecnología.

Escalar el negocio es bastante simple, pero sigue siendo un trabajo duro. Realmente solo hay dos maneras de escalar. Puedes hacer más ventas o puedes hacer ventas más grandes. Y por eso todo es una suscripción o se dirige a empresas en estos días. La razón por la que te importa esto como ingeniero es porque sin el negocio, no hay ingeniería. La ingeniería se trata de construir la cosa correcta en el momento correcto para la situación correcta. Y no importa lo que intentes, no puedes salvar un mal negocio con mejor tecnología. Y también el negocio es el combustible para todo lo que haces. Los números que quieres saber son el costo de adquirir clientes y su valor de vida. Y tu objetivo es construir tecnología que se ajuste a estos números. Pero honestamente, eso es principalmente lo que van a estar haciendo los de negocios. Lo que realmente estás haciendo es esto. Estás construyendo las vías antes de que el tren se detenga. Y estás tratando de ir, básicamente estás tratando de ir lo más rápido posible para asegurarte de que la ingeniería nunca sea el cuello de botella que detenga el negocio. Y no importa lo que escuches en Twitter o en internet, la ingeniería es solo una herramienta que el negocio usa para lograr sus objetivos. No es lo principal que, en su mayor parte, no es lo principal que el negocio está haciendo. Lo que estás tratando de hacer es construir esa flor. Pero lo que estás vendiendo a los usuarios son nuevos usuarios que pueden hacer cosas increíbles. Sé que amo mi tecnología, pero a los usuarios no les importa un carajo lo que estás haciendo. Solo quieren usar tu cosa y seguir con su vida. Así que eso es sobre escalar el negocio.

Escalar el equipo también es algo importante, aunque no hablamos mucho de eso como tecnólogos, porque muchos problemas tecnológicos son secretamente problemas de personas. Tu arquitectura y el proceso que usas para construir productos va a reflejar la estructura de tu equipo. Así que, por ejemplo, si pones QA en un equipo separado, vas a pasar mucho tiempo esperando que QA te dé su feedback. Y vas a tener ingenieros que están lanzando cosas por encima del muro en lugar de asegurarse de que su código funcione. Y luego tienes mucho ida y vuelta al final después de que el código está escrito, lo que te ralentiza y es realmente molesto para todos los involucrados.

2. Vertical Teams and Engineering Ownership

Short description:

Organiza equipos basados en el propósito, no en la tecnología. Pasa menos tiempo bloqueado por otros equipos. Lanza características sin ser bloqueado. Hazte cargo de tu propio desorden. Enfócate en la asociación de ingeniería de producto. Construye más rápido usando ciclos de retroalimentación. Construye soluciones apropiadas para tu caso de uso. Deja ir el ego y experimenta con diferentes enfoques. Los ingenieros se hacen cargo de su propio desorden.

Y lo peor que he visto que las startups hacen es que organizan equipos basados en la tecnología en lugar de basados en el objetivo o el propósito de lo que estás construyendo. Así que si organizas tus equipos de esa manera, vas a terminar pasando mucho tiempo bloqueado. Principalmente vas a estar esperando. Construyes la cosa, construyes tu parte de la cosa, y luego va a otro equipo y luego a otro equipo y terminas con un proceso muy lineal y lento.

Mientras que si puedes orientar tus equipos basados en su propósito, basados en su objetivo, como un equipo de administración que posee usuarios de administración, un equipo de compradores que posee compradores, un equipo de crecimiento que se enfoca en hacer crecer el producto, vas a pasar mucho menos tiempo bloqueado por otros equipos y siendo capaz de construir proyectos o nuevas características, de principio a fin como parte de un solo grupo. El objetivo de hacer eso es que quieres entregar valor sin ser bloqueado. Y hay muchos nombres diferentes para este tipo de estructura de equipo. Algunas personas los llaman equipos empoderados equipos extremadamente alineados, equipos centrados en la capacidad de negocio. Es todo un libro de capacidad de consultoría, y solo depende de qué libro leas.

El objetivo principal, el punto principal que todos intentan transmitir cuando hablan de esto es que quieres un equipo que pueda lanzar características de principio a fin sin ser bloqueado. Y parte de eso, mi parte favorita de eso es que puedes hacerte cargo de tu propio desorden. Así que usé QA como ejemplo. Um, si tienes ingenieros que se hacen cargo de su propio desorden y que son responsables de las cosas que lanzan, vas a tener muchos menos errores. Se siente más lento, pero en realidad vas a tener muchos menos, muchos menos problemas. Así que, por ejemplo, hace un par de días, me llamaron como a las 3am, me sacaron de la cama, fui a ver las alertas, y era algo increíblemente estúpido y tonto. Ahora adivina qué me aseguré realmente de que se arreglara al día siguiente. Um, sabes, me llamaron, arreglé el error en un día y el error, y eso no va a volver a suceder, lo cual es mucho más rápido de lo que muchos, muchos equipos logran hacerlo. También un poco más estresante. Uh, la otra parte de tener equipos verticales que pueden hacerse cargo de su dominio es que puedes enfocarte en una mejor asociación de ingeniería de producto donde los ingenieros trabajan en llevarnos al otro lado del agua, no solo construyendo el puente.

Así que terminas con este ciclo de retroalimentación circular en lugar de un proceso lineal donde puedes trabajar junto con el producto para construir las, para construir esas flores que, um, que los clientes quieren para moverse más rápido. Te permite, te permite construir más rápido, um, usando ciclos de retroalimentación, y puedes iterar en soluciones. Yo, personalmente, lo encuentro muy gratificante como ingeniero cuando puedo hablar con los clientes, entender sus necesidades, diseñar, diseñar mi código y mis productos como una forma de resolver esas necesidades de usuario y luego, um, devolvérselo a ellos e iterar en esas soluciones. La idea es que puedes construir cosas que puedes construir la solución apropiada para tu caso de uso, no solo algo de lo que escuchaste en la charla. Y de eso se trata realmente la ingeniería. Lo que eso significa es que sí, a veces vas a tener que fusionar código realmente malo que apesta, uh, porque al final del día, tu código no necesita ser perfecto. Solo necesita funcionar. Así que vas a tener que dejar ir tu ego y dejar que otras personas experimenten con diferentes enfoques. Está bien si alguien escribe código de una manera que, uh, de una manera diferente a como tú lo harías porque está bien, siempre y cuando funcione. Y siempre y cuando esos ingenieros se hagan cargo de su propio desorden, uh, si se rompe, lo van a arreglar. Si funciona, es genial.

3. Scaling Tech and Avoiding Work In Progress

Short description:

Evita el trabajo en progreso. Termina el trabajo y concéntrate en arreglarlo más tarde. Ten una conversación antes de escribir código. Escalar la tecnología es más fácil de lo que piensas. Elige un diseño disponible. Guarda la innovación para las partes centrales. Elige soluciones existentes. Concéntrate en resolver el problema.

Y no pasaste un montón de tiempo discutiendo sobre pequeños detalles que al final no importaron de todos modos. Uh, la razón por la que eso importa es que el trabajo en progreso mata tu progreso. Quieres evitar tener un montón de PRs obsoletos y ramas de larga duración y cosas así por ahí porque tienden a acumular polvo. Um, y cuanto más tiempo tengas código que no se ha fusionado o que simplemente ha estado ahí, más difícil se vuelve fusionarlo, más ideas tienes. Oh, pero aún podemos mejorar esto o, oh, podemos ajustar eso. Siempre puedes ajustar, ajustar cosas y mejorar tu código más tarde. Ahora mismo deberías simplemente terminar el, terminar el trabajo, sacar la característica, ver si a los usuarios les gusta y concentrarte en arreglarlo mejor, uh, en arreglarlo más tarde. Y el mejor truco que he encontrado para, uh, tener ciclos de PR más lentos y hacer que sea más fácil fusionar rápidamente es hablar sobre lo que estás haciendo antes de comenzar a escribir el código. Sé que somos ingenieros, odiamos las reuniones, pero te prometo que una conversación de cinco minutos sobre cómo vas a abordar un problema, cómo vas a, uh, escribir el código, cuáles son los compromisos, um, asegurarte de que todos entiendan todo lo que está involucrado es mucho más rápido y mucho más fácil que tener una discusión de PR de tres días donde escribes el comentario, luego trabajas en tu propio código, y luego vuelves tres horas después cuando responden y, ya sabes, solo ten esa conversación de cinco minutos y mantén la revisión de código y las solicitudes de extracción como solo una verificación rápida al final.

Bien, así que hablamos sobre escalar el negocio y escalar tu equipo y, uh, hacer que el equipo trabaje más suavemente, si esa es una palabra. Um, entonces, ¿qué hay de escalar la tecnología? Bueno, a pesar de lo que la gente dice en línea, la tecnología es realmente la parte fácil. Um, principalmente estás resolviendo problemas que tienen soluciones conocidas. Así que deberías simplemente elegir un diseño disponible, aplicarlo a tu dominio y seguir adelante. Lo que quieres evitar es gastar todas tus fichas de innovación en cosas que realmente no importan. Así que hay un gran libro llamado how big things get done, donde hablan sobre proyectos del mundo real. Y uno de mis ejemplos favoritos es por qué China construye muchas más plantas de energía nuevas, carreteras, puentes y todas esas cosas que nosotros en Occidente, tanto en los EE.UU. como, um, y en Europa. Lo que los autores identificaron es que China se mueve rápido porque tienen como 10 diseños estandarizados. Eligen el que está más cerca de la situación, de la situación con la que están lidiando. Y luego cambian la situación para que se ajuste al diseño en lugar de la forma en que lo hacemos en Occidente, donde tratamos cada proyecto como un pequeño copo de nieve único. Pasamos un montón de años innovando en un diseño completamente nuevo, luego lidiando con todas las repercusiones de tener desconocidos desconocidos y siendo sorprendidos por cosas que no predijimos. Y luego, cuando está construido, tiramos todas esas lecciones y comenzamos de nuevo desde cero la próxima vez. No estoy diciendo que no debas innovar. Lo que estoy diciendo es que deberías guardar tu innovación para las partes centrales de tu producto, donde realmente estás haciendo una diferencia. No necesitas inventar una nueva biblioteca de sistema de diseño o inventar un nuevo marco de gestión de estado o resolver todas estas cosas. Simplemente elige uno. Estamos en JavaScript. Te prometo que hay 10 o 20 bibliotecas para cada pequeña cosa que estás tratando de hacer. Simplemente elige la que funcione y sigue adelante y concéntrate en, ya sabes, concéntrate en resolver el problema, no en un problema diferente y más difícil.

4. Scaling Tech and Pushing Back on Complexity

Short description:

No pierdas tiempo tratando de predecir la escala futura. La escala te sorprenderá. Haz lo que funcione para tu negocio. Rechaza la complejidad innecesaria. Entiende el costo de las ideas. Modifica la situación para que se ajuste al diseño existente.

Escribir una versión de framework genérico de ese mismo código que intenta ser súper flexible, predecir todo lo que va a suceder en el futuro y escalar de tus cinco usuarios actuales a los 50 millones de usuarios que esperas tener en los próximos años. Eso es realmente difícil. Y te prometo que solo estás perdiendo el tiempo. Lo más probable es que estés tratando de escalar antes de lo necesario. Y te prometo, puedo prometerte que la forma en que piensas que tu código se va a romper cuando alcances más escala no es cómo realmente se va a romper. La escala te sorprenderá. Las cosas se rompen de maneras extrañas. Y además, no necesitas hacer todo de la misma manera que Facebook, Google, Shopify o quien sea lo hace. E incluso Shopify.

Shopify es en realidad un gran ejemplo. Ellos todavía hasta el día de hoy en su escala actual, son una tienda de Ruby on Rails y usan MySQL para operar. Creo que les gusta compartir números alrededor del Día de Acción de Gracias. Hace unos años, estaban haciendo varios millones de consultas por segundo y API, varios millones de solicitudes de API y usuarios por segundo, todo en Ruby on Rails y MySQL. Así que la tecnología escalará. Y cuando llegues allí, podrás resolverlo entonces. No intentes escalar demasiado rápido porque tu trabajo principal es rechazar la complejidad. Como dije antes, estás tratando de llevarnos sobre el agua ahora mismo. No estás tratando de simplemente construir un puente porque alguien dijo, alguien pidió un puente.

Parte de eso es que cuando trabajas con tu gerente de producto y tienes esa asociación de ingeniería de producto porque posees un dominio vertical del negocio, puedes rechazar sus ideas. Si hay un requisito que arruina completamente un proyecto y lo hace tomar 10 veces más tiempo de lo que tomaría de otra manera, está bien mirar a tu gerente de producto a los ojos y decirle, oye, ¿realmente necesitamos esta parte de la característica? ¿Podemos simplemente no hacer esto y luego aún resolver el problema lo suficientemente bien? Y lo que podría sorprenderte es que muchas veces cuando encuentran, cuando les dices el costo real de sus ideas o el costo de lo que tomará construir algo, simplemente dirán, sí, tienes razón. No vale la pena. No hagamos eso. Porque realmente entiendes el código mucho mejor que tus gerentes, tus gerentes de producto. Incluso entiendes los detalles de tu código mucho mejor que tus, creo que ya no los llamamos arquitectos, que tus ingenieros principales. No conocen los detalles. Si algo es mucho más difícil de lo que parece desde afuera, tienes que decírselo a la gente y es muy probable que cambien los requisitos. Como mencionaba antes de cómo se hacen las cosas grandes, puedes modificar la situación para que se ajuste al diseño que ya existe. Eso es casi siempre más rápido que doblarse hacia atrás para mover un montón de código, reescribirlo y ajustarse a este único requisito que tal vez ni siquiera necesites. Y mucho de lo que hace que algunas cosas sean difíciles y otras no es la forma en que has estructurado tu arquitectura. El código, como el código de bajo nivel real, cambia mucho más a menudo que tu arquitectura general.

5. Code Architecture and Reducing Complexity

Short description:

La arquitectura es como un gráfico de dependencias en tu código. Reduce la complejidad arquitectónica organizando el código según lo que hace. Usa modelos verticales y evita crear dependencias excesivas. En el cliente, utiliza módulos verticales. En el back end, considera una arquitectura orientada a servicios. Comienza con un monolito y transiciona a microservicios si es necesario.

Puedes pensar en la arquitectura como un gráfico de dependencias en tu código donde cada caja es como un módulo, función, clase, componente, como quieras llamarlos. Y las líneas son cómo esos componentes interactúan. Cuantas más líneas tengas en este gráfico, más difícil será trabajar con tu código, más tendrás que cruzar diferentes límites, tendrás que hacer que las cosas funcionen juntas, más difícil será, y más encontrarás esos pequeños, oh, ¿y si solo movemos este botón de aquí para allá? Y de repente todo explota y se desmorona.

A un nivel alto, tu arquitectura va a seguir tu estructura de equipo. A un nivel más bajo, depende un poco de lo que hagas. Idealmente, puedes usar modelos verticales donde la idea de los modelos verticales es que puedes reducir tu complejidad arquitectónica, así que tener menos de esas líneas, si organizas tu código basado en lo que hace, no basado en lo que es. Así que todo lo que necesitas para construir, el panel de control va junto, todo para un equipo va junto, todo para una lista de tareas va al menos en la misma carpeta. Y luego, si se vuelve súper complejo, puedes fractalmente dividirlo más. Lo que quieres evitar es tener una carpeta para componentes, una carpeta para hooks, una carpeta para tipos, una carpeta para utils, porque entonces todo termina dependiendo de todo lo demás, sabrás que estás en esta situación si cada archivo comienza con como 50 declaraciones de importación porque cada archivo necesita importar casi todos los demás archivos en tu código.

Así que en el cliente, vas a terminar llamando a estos módulos verticales componentes o páginas, a veces grupos de páginas. En el back end, estás buscando algo como una arquitectura orientada a servicios. Puedes hacer esto con un monolito. Los monolitos son geniales. De hecho, soy un gran fan de los monolitos, pero los monolitos pueden ser difíciles de mantener limpios y de realmente hacer cumplir esas separaciones. Así que si tu equipo realmente no puede mantenerlo limpio, y si estás creciendo mucho, está bien usar microservicios o micro frontends, pero esos en realidad traen mucha complejidad propia que al menos en una startup, puedes evitar por mucho más tiempo del que necesitas.

6. Avoiding Architectural Complexity

Short description:

Usa carpetas en lugar de microservicios cuando tienes un equipo pequeño. Usa modelos verticales y desarrollo basado en contratos o tipos para definir APIs e interfaces claras. Evita código altamente interconectado y duplicación. Enfócate en estructuras de datos para evitar complejidad y la necesidad de capas de traducción.

A todos les gusta usar Amazon y AWS como un ejemplo de, oye, deberíamos solo comunicarnos entre nosotros a través de APIs y todo debería ser un microservicio. Solo hicieron eso cuando tenían, creo, más de 500 o 600 ingenieros trabajando en el mismo producto. He estado en startups donde comenzamos a dividir todo en microservicios cuando éramos como 10 ingenieros. Eso es demasiado pronto. No necesitas microservicios o micro frontends si solo hay 10 de ustedes y se están pisando los talones un poco. Usa carpetas. Están bien.

Con modelos verticales, lo que realmente ayuda es que te da una API clara. Porque no todo está cruzado e importando otras cosas, puedes definir una API clara o una interfaz clara. Lo que me gusta usar para esto es el desarrollo basado en contratos o tipos así que el desarrollo basado en contratos o tipos básicamente significa que defines la interfaz primero y luego construyes los internos de esa interfaz. Esto automáticamente te obliga a diseñar modelos verticales y también te obliga a tener esas discusiones arquitectónicas desde el principio cuando las cosas aún son flexibles y fáciles de cambiar, no más tarde en tus PRs cuando estás discutiendo sobre el código.

Lo principal que estás tratando de evitar es ser golpeado por la Ley de Hiram que establece que si alguien puede depender de algo en tu código, lo hará. Y así es como obtienes esos super cruzados, esa es una gran parte de cómo obtienes esos APIs cruzados que son poco claros y terminas rompiendo código que ni siquiera te diste cuenta que estaba conectado. Mi opinión controvertida aquí es que si haces esto bien, necesitarás escribir muchas menos pruebas de las que haces si todo está interconectado porque los límites del módulo ya están garantizando que no estás rompiendo código que no parece estar relacionado con lo que estás haciendo.

Una de las principales fuentes de este código arquitectónicamente complejo altamente interconectado que he visto es intentar no repetirte. Es probablemente alguno de los peores códigos que he escrito de esa manera. De hecho, hubo un muy buen ejemplo de esto en mi nueva startup hace un par de semanas donde teníamos una función que parecía, oh, estamos repitiendo esta misma función en tres o como esta misma cosa en tres cosas diferentes en tres lugares diferentes. ¿Qué pasa si consolidamos esto y lo hacemos más fácil de usar? Así que lo consolidamos y estaba bien y luego unos días después alguien más vino y dijo, oh, esta función parece realmente útil y la movió a un lugar diferente, cambió cómo se comportaba la función y terminó rompiendo cosas completamente no relacionadas con lo que estaban haciendo porque estaban conectadas. Así que lo que sucedió allí fue que estábamos desduplicando código que parecía similar pero en realidad tenía diferentes objetivos. Así que hicimos que nuestro diagrama de arquitectura se viera así y la forma más fácil de reconocer cuando tienes dry en lugar de separación de preocupaciones, la forma más fácil de identificar eso es si alguna vez has usado un componente que para una función que toma como cinco o seis propiedades booleanas solo para especificar cómo se comporta o qué está haciendo en esta situación, eso fue probablemente una señal de que estás usando un componente que ha sido desduplicado incorrectamente y debería dividirse en múltiples componentes. Está bien tener código repetido. El código es barato. Lo que no quieres repetir es la intención y la fuente de verdad de tu lógica. Así que una forma en que me gusta identificar esto es si el código parece similar ahora pero sirve a diferentes usuarios, casi con certeza va a evolucionar de diferentes maneras. O si el código parece similar ahora pero los usuarios están tratando de lograr una tarea o un objetivo diferente al usar este código, también se va a dividir y necesitará evolucionar de diferentes maneras. Así que no deberías fusionar ese código.

Hay mucho que decir al respecto, pero esta es una charla de 20 minutos. Así que lo último que quiero decir sobre cómo puedes evitar la complejidad arquitectónica o simplemente la complejidad en tu código es realmente enfocándote en tus estructuras de datos. Si tus datos están en la forma incorrecta para lo que estás tratando de hacer, vas a tener que doblarte hacia atrás para que funcione.

7. User Experience and Vertical Teams

Short description:

Construir capas de traducción puede llevar a una experiencia de usuario lenta. Los equipos verticales alineados con el código vertical permiten una rápida resolución de problemas, control total de las características y manejo eficiente de datos. Comprender todo el dominio permite un desarrollo más rápido con menos errores.

En el peor de los casos, terminarás construyendo capas de traducción. Así que una vez estaba hablando con un amigo que estaba resolviendo el problema del vendedor viajero, que es súper difícil, irresoluble, como un caso tradicional de código NP-completo que es irresoluble a menos que añadas algunas restricciones. Tenían ingenieros de back-end brillantes que hicieron que todo este código funcionara, construyeron algoritmos increíbles que eran súper rápidos, pero luego la experiencia de usuario, a pesar de todo este increíble trabajo de ingeniería en el back-end, la experiencia de usuario era súper lenta porque la API del back-end devolvía datos en una forma completamente incorrecta. Así que mi amigo en el lado del cliente construyendo una aplicación de React para mostrar estos datos tuvo que hacer tantos cálculos que esencialmente reimplementaron toda la lógica difícil de resolver este loco problema en el front-end, donde terminaron teniendo que mover un montón de sus cálculos a Wasm solo para hacerlo lo suficientemente rápido para que la interfaz de usuario no se bloquee cuando haces clic en un botón. Porque llegaron a un punto donde si hacías clic en algo, tardaba de cinco a diez segundos en volver a renderizar el lado del cliente.

Así que el re-renderizado de React tardaba de cinco a diez segundos solo porque básicamente tenía que rehacer todo el trabajo que ya había sucedido en el back-end para obtener los datos en la forma correcta para lo que necesitaban. Y eso, amigos míos, es por lo que quieres tener equipos verticales que estén alineados a lo largo de tu código vertical porque puedes enfocarte en resolver problemas de usuario rápidamente, tienes control total de las características y las cosas que estás construyendo de principio a fin, puedes diseñar cómo se almacena en la base de datos, cómo se comunica con tu... cómo se almacena en la base de datos, cómo se procesa en el back-end, cómo son las APIs e interfaces, puedes hacer que se ajusten realmente bien al lado del cliente que estás construyendo, asegurarte de obtener todos los datos que necesitas. Eso hace que tu aplicación funcione más rápido, hace que todo esté alineado, y también significa que entiendes todo el dominio de principio a fin de lo que estás tratando de construir, lo que te permite avanzar más rápido y con menos errores.

Así que gracias, he estado escribiendo este libro durante mucho tiempo, pero prometo que se terminará eventualmente. He expandido todo lo que he dicho hoy en básicamente un libro. Puedes encontrar más información en scalingfastbook.com y enviarme un correo electrónico si tienes preguntas, realmente no uso DMs de Twitter.

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

Cómo automatizar cambios de código para 100 repositorios: Introducción a los Codemods
React Day Berlin 2022React Day Berlin 2022
28 min
Cómo automatizar cambios de código para 100 repositorios: Introducción a los Codemods
This Talk discusses automating code changes for Android repositories, utilizing tools like JSCodeShift and Abstract Syntax Tree. The speaker shares a real use case example of maintaining a design system library and making changes to a component. The talk emphasizes the importance of automating repetitive tasks and using the power of abstract syntax tree for code changes. The Q&A session covers topics like source code formatting, TypeScript support, and cultural embedding of code mods. The talk concludes with insights on when automation is worth it and the limitations of code mods for monorepo changes.
Arquitectura de código de próxima generación para construir aplicaciones de Node mantenibles
Node Congress 2023Node Congress 2023
30 min
Arquitectura de código de próxima generación para construir aplicaciones de Node mantenibles
Today's Talk focused on code architecture, modularization, and scaling in software development. The speaker discussed the benefits of separating code by domain and using tools like NX to improve productivity and enforce modular architecture. They also highlighted the importance of automating library creation and configuration. Additionally, the Talk covered code scaling and deployment strategies, including caching and automated code migrations. The speaker emphasized the flexibility and scalability of Fastify and the advantages of using a monorepo for front-end and back-end development.
El Futuro Stack de la Revisión de Código
JSNation 2023JSNation 2023
22 min
El Futuro Stack de la Revisión de Código
The Talk discusses the challenges of code reviews and the need to redefine the code review process in light of changes in software development. It emphasizes the importance of collaboration, security, performance, and clean code in the new stack of code review. The Talk also highlights the benefits of automating code review comments and optimizing the code review process. Overall, the Talk aims to build a better code review process that promotes collaboration and improves the quality of software development.
Camino a Cero Fallos de Lint: Abordando Desafíos de Calidad de Código a Gran Escala
React Summit US 2023React Summit US 2023
11 min
Camino a Cero Fallos de Lint: Abordando Desafíos de Calidad de Código a Gran Escala
This Talk discusses the journey from thousands of Lint failures to zero in a codebase at Linton that is over 80 years old. The approach involved implementing rules, incentives, and tooling to address the issue. The tool called Checkup was used to visualize ESLint failures by team and lint rule, providing accountability and responsibility. The efforts resulted in cleaning up over 6,000 lint failures, with 55 contributors, and a 30% increase in perceived code quality.
Acelerando la calidad del código con las métricas de DORA
JSNation Live 2021JSNation Live 2021
27 min
Acelerando la calidad del código con las métricas de DORA
This Talk discusses the Dora Metrics and their relation to continuous code improvement. High and elite performers deploy more frequently and have a lower change failure rate. Continuous code improvement involves identifying and fixing bugs in real time. Rollbar is a continuous code improvement platform that provides visibility into actionable errors. It helps organizations reduce the risk of losing customers and optimize developer productivity. Rollbar's unique error fingerprints and advanced features enable a deeper understanding of issues and faster resolution.
Lo que aprendí sobre la calidad del software de los 10 proyectos de Javascript más populares en Github
TestJS Summit 2023TestJS Summit 2023
27 min
Lo que aprendí sobre la calidad del software de los 10 proyectos de Javascript más populares en Github
The Talk discusses the code review process and the importance of software quality. It emphasizes the need for maintainability in code and the use of guidelines tailored to the team. The Talk also highlights the significance of functional suitability and the challenges of code review. Automation and documentation are recommended to improve code reviews and ensure software quality.

Workshops on related topic

Desarrollando Aplicaciones Listas para Producción en Colaboración con Agentes de AI
React Summit 2025React Summit 2025
102 min
Desarrollando Aplicaciones Listas para Producción en Colaboración con Agentes de AI
Featured Workshop
Alex Shershebnev
Alex Shershebnev
Los asistentes de codificación ya están cambiando la forma en que desarrollamos código, y en varios años se espera que cambien completamente cómo los desarrolladores interactúan con el código y lo escriben. En esta masterclass, compartiré consejos y mejores prácticas sobre el uso de tales herramientas mientras desarrollamos la aplicación lista para producción con Zencoder.
Aporta Calidad y Seguridad al pipeline de CI/CD
DevOps.js Conf 2022DevOps.js Conf 2022
76 min
Aporta Calidad y Seguridad al pipeline de CI/CD
Workshop
Elena Vilchik
Elena Vilchik
En esta masterclass repasaremos todos los aspectos y etapas al integrar tu proyecto en el ecosistema de Calidad y Seguridad del Código. Tomaremos una aplicación web simple como punto de partida y crearemos un pipeline de CI que active el monitoreo de calidad del código. Realizaremos un ciclo completo de desarrollo, comenzando desde la codificación en el IDE y abriendo una Pull Request, y te mostraré cómo puedes controlar la calidad en esas etapas. Al final de la masterclass, estarás listo para habilitar esta integración en tus propios proyectos.