Si me hubieras dicho hace un año que me darían de baja de la universidad y que trabajaría en una startup de tres personas en el espacio de herramientas de desarrollo front-end, me habría reído.

Los últimos 3 meses han transformado mi mentalidad por completo. Entré en esta pasantía con dudas sobre las nuevas empresas, ya que solo sabía cómo era una carrera en una gran empresa. He presentado un plan claro sobre cómo iniciaría mi propia empresa, desde la ideación y la configuración de la base de código hasta la implementación y la comercialización.

El equipo de Vivid hizo que eso sucediera. Después de reflexionar, un par de distinciones clave entre las empresas emergentes en etapa inicial y las grandes tecnológicas marcaron la diferencia.

• Atención. En Vivid, había un gran énfasis en mi aprendizaje. Me animaron a elegir en lo que quería trabajar, hacer preguntas y hablar sobre cualquier cosa que quisiera aprender. Mencioné que estaba interesado en cómo Jorge configuró el monorepo, y al día siguiente tuvimos una discusión de dos horas sobre los entresijos de Vite, Turborepo, pnpm y más. Por mucho que esto sea un testimonio del equipo de Vivid, la atención surge naturalmente en un equipo más pequeño. Mi trabajo estaba directamente relacionado con el éxito de la empresa, por lo que ayudarme a dar lo mejor de mí era lo mejor para todos.
• Amplitud de aprendizaje. En una empresa en etapa inicial, no hay una base de código establecida para construir. Estaba tan acostumbrado a dar por sentado cosas como los scripts de implementación y las cadenas de conexión de la base de datos, pero de repente me encontré teniendo que ser yo quien configurara estas cosas. Creo que en las empresas más grandes, exploras un tema muy profundamente, pero en una startup, te ves obligado a tener un pie en la puerta para cada pieza de tu producto.
• Calidad del código. Aunque las empresas emergentes suelen tener una reputación de código de mala calidad, ciertamente este no fue el caso en Vivid. Aprendí mucho sobre las mejores prácticas de código, haciendo que mis relaciones públicas fueran enviadas para corregir demasiadas veces para contar. Si bien fue doloroso en ese momento, ciertamente soy un mejor ingeniero ahora y entiendo la importancia de una revisión exhaustiva del código.
• ¡Divertido! Por último, pero ciertamente no menos importante, la pasantía en Vivid fue lo más divertido que he tenido en un trabajo. Aryaman, Jorge y Alberto establecieron un ambiente tan tranquilo desde la primera semana, y ahora siento que estoy trabajando en un proyecto de hackathon con mis grandes amigos. En otros trabajos, me moría de ganas de salir del trabajo a las 5 de la tarde, pero aquí me encuentro feliz de quedarme y trabajar hasta cuando sea.

Mientras escribo esta publicación, a solo unas horas de nuestra segunda fiesta de lanzamiento en el mismo techo de WeWork, conocí a Aryaman, Jorge y Alberto, casi deseo que yo también tuviera una oferta de Big Tech para renegar y unirme a Vivid. En lugar de eso, regresaré a Columbia para cursar mi último año de universidad, con cuatro nuevos amigos y el deseo de construir algo con lo que he aprendido.

Ingrese Vívido

Conocí a Aryaman, Jorge y Alberto en persona por primera vez cuando se negaron a aceptar sus ofertas de trabajo de Big Tech en una fiesta de WeWork en la azotea. Después de haber tenido una breve charla de café con Aryaman la semana anterior, pensé que era tan refrescante ver la emoción que tenían los tres sobre lo que estaban trabajando.

Acababa de terminar mi pasantía en Microsoft y había hecho una pasantía en Meta el verano anterior. Sentí que tenía una buena idea de cómo sería la vida en Big Tech, y aunque no lo odiaba, una gran parte de mí también se preguntaba cómo sería trabajar en una startup. Ver al equipo de Vivid regocijarse cuando renunciaron a las ofertas soñadas de mi yo de primer año fue una llamada de atención: tenía que ver lo que me estaba perdiendo.

No fue una sorpresa que un mes después, estaba firmando una carta de oferta para unirme como el primer pasante de Vivid para la primavera de 2023.

el pivote

Entré en mi primer día de trabajo en Vivid sin saber qué esperar.

El día 1, recibí la mayor sorpresa: Vivid ya no estaba construyendo Styler, su producto estrella que me mostraron en esa azotea hace solo un par de meses. Me di cuenta de que me unía a la empresa en un momento increíblemente único: experimentar de primera mano lo que significa construir una empresa desde cero.

Inmediatamente me involucré en sesiones de lluvia de ideas mientras el equipo ideaba nuevas direcciones para la empresa. Rápidamente me puse al día con las ideas que se lanzaban y absorbí los entresijos de lo que hace que una idea sea mejor que otra.

Un par de conclusiones clave de nuestras sesiones de lluvia de ideas:

• Es importante crear un producto que la gente realmente necesite . No importa si su herramienta aumenta la productividad de cada persona del equipo en un 10 %: nadie está dispuesto a interrumpir su flujo de trabajo actual por una pequeña mejora. Más bien, si hay dos o tres ingenieros que experimentan un aumento de productividad del 200 %, su herramienta será mucho más exigente.
• Los competidores no descalifican una idea. Solía ​​pensar que si cualquier otra empresa, por pequeña que fuera, había comenzado a trabajar en una idea similar a la mía, no debería seguirla. Pero ahora, veo que estas empresas existen como prueba de que hay un problema real que debe resolverse.
• La visión a largo plazo es importante. También lo es dejar ir una mala idea. Me sorprendió cuando escuché que Vivid estaba dejando de lado el Styler. Como usuario, pensé que era un producto bien ejecutado con un caso de uso sólido. Ahora entiendo que no había una meta previsible a largo plazo con Styler y pivotar era esencial para el crecimiento de la empresa. Ser capaz de alejarse de una idea sin un camino claro a seguir, independientemente de la falacia del costo irrecuperable, es necesario para que las nuevas empresas se muevan rápido.

¡A continuación se muestra una imagen de mi primera contribución de código al equipo de Vivid!

Al final de las dos primeras semanas en Vivid, pasé de no saber cómo escribir una sola línea de React a estar seguro de que podía crear una página desde cero: más aprendizaje del que había obtenido en 12 semanas de pasantías anteriores.

Sincronización vívida

La segunda parte de mi pasantía fue definida por Vivid Sync. Ya sabíamos que había una fricción sustancial en el traspaso de los desarrolladores a los diseñadores. Pero durante una llamada con un cliente, un líder de ingeniería compartió una idea clave: esta fricción tenía una sola causa raíz. Con el tiempo, las bibliotecas de Figma comienzan a divergir de los repositorios de código, lo que provoca una falta de comunicación constante entre diseñadores y desarrolladores.

Una semana después de que se nos ocurrió la idea, conseguimos un socio de diseño y comenzamos a construir el producto, que esencialmente era un sistema de gestión de tareas que vinculaba los componentes de Figma a una base de código a través de Github Issues.

Me encargaron construir la interfaz de usuario web, que se veía así:

Pero nuevamente, por mucho que pensé que la idea y el producto eran geniales, solo una semana después de entregar el producto a nuestro socio de diseño, estábamos de vuelta en la sala de reuniones comenzando desde cero nuevamente.

Lluvia de ideas pt. 2

Vivid Sync tenía un defecto fatal: no resolvía el problema del cliente. El usuario final estaba motivado por la promesa de limitar el tiempo de ingeniería perdido. A diferencia de Styler, Vivid Sync tenía una visión clara a largo plazo, que era crear una sincronización de extremo a extremo entre Figma y Code, pero el producto tal como se entregó no ahorró tiempo a los ingenieros; en realidad, aumentó la cantidad total de trabajo mediante la creación de tareas para el trabajo de mantenimiento.

El equipo se dedicó a construir algo lo más rápido posible para nuestro socio de diseño, pero en retrospectiva, hubo advertencias claras desde el principio de que el valor agregado inmediato de Sync podría no ser lo suficientemente alto.

Esta vez, estaba preparado para lo que estaba por venir. Me propuse participar activamente en las discusiones de ideación. Aprendí a escribir hojas de hipótesis, realizar investigaciones competitivas y manejar el flujo y reflujo del pensamiento divergente que se reduce a una idea específica. Sobre todo, aprendí cuánto impacto podría tener mi opinión en un equipo pequeño.

Figma a código

Mi historial de confirmación de GitHub dejó en claro exactamente cuánto tiempo pasamos ideando: 3 semanas. Decidimos sumergirnos directamente en la dirección de mayor valor para los clientes: convertir los diseños de Figma en un código de interfaz utilizable. Había una visión clara a largo plazo, abordábamos directamente el punto débil del usuario final y todos teníamos niveles de convicción mucho más altos.

Cuando se trataba de construir, me hice cargo de la incorporación de nuevos usuarios. El objetivo de la incorporación era permitir que Vivid generara código usando componentes que ya estaban en la base de código del usuario.

El desafío técnico clave fue obtener los componentes del código del usuario y vincularlos a sus activos de Figma correspondientes, de modo que cada vez que se usara ese activo de Figma, pudiéramos llamar al componente correcto en el código. También era necesario hacer coincidir las propiedades de los componentes para que nuestra herramienta pudiera llamar a estos componentes sin ningún error.

La función de incorporación tenía un par de piezas diferentes:

1. Aplicación Github . La aplicación Github se conecta a un repositorio y devuelve todos los archivos .tsx dentro del repositorio conectado a través de una API REST
2. Microservicio Python . El microservicio de Python, creado con Flask, utiliza un algoritmo de coincidencia de NLP para hacer coincidir semánticamente los componentes del código con los componentes de Figma.
3. Paquete transversal de código . El paquete transversal de código me permitió conectar la aplicación Github y el microservicio Python juntos. Obtuvo archivos .tsx de la aplicación Github y devolvió los componentes coincidentes del microservicio de Python.
4. Plataforma de coincidencias de incorporación. Finalmente, la interfaz de usuario permitió realizar coincidencias y enviarlas a una base de datos en el backend.

¡Fotos divertidas!