Se você me dissesse um ano atrás que eu seria cancelado da faculdade, trabalhando em uma startup de três pessoas no espaço de ferramentas de desenvolvedor de front-end, eu teria rido.

Os últimos 3 meses transformaram minha mentalidade inteiramente. Entrei neste estágio hesitante em relação a startups, sabendo apenas como é uma carreira em uma grande empresa. Apresentei um plano claro de como iniciar minha própria empresa, desde a concepção e configuração da base de código até a implantação e entrada no mercado.

A equipe Vivid fez isso acontecer. Após reflexão, algumas distinções importantes entre startups em estágio inicial e Big Tech fizeram toda a diferença.

• Atenção. Na Vivid, havia uma grande ênfase no meu aprendizado. Fui incentivado a escolher no que queria trabalhar, fazer perguntas e falar sobre qualquer coisa que desejasse aprender. Mencionei que estava interessado em como Jorge configurou o monorepo e, no dia seguinte, tivemos uma discussão de duas horas sobre os meandros do Vite, Turborepo, pnpm e muito mais. Por mais que isso seja uma prova da equipe Vivid, a atenção vem naturalmente em uma equipe menor. Meu trabalho estava diretamente ligado ao sucesso da empresa, portanto, ajudar-me a ter o melhor desempenho era do interesse de todos.
• Amplitude do aprendizado. Em uma empresa em estágio inicial, não há uma base de código estabelecida para construir. Eu estava tão acostumado a considerar coisas como scripts de implantação e strings de conexão de banco de dados como garantidos, mas de repente me vi tendo que configurar essas coisas. Acho que em empresas maiores, você explora um tópico profundamente, mas em uma startup, você é forçado a ter um pé na porta para cada peça de seu produto.
• Qualidade do Código. Embora as startups geralmente tenham uma reputação de má qualidade de código, esse certamente não era o caso da Vivid. Aprendi muito sobre as melhores práticas de código, tendo meus PRs enviados de volta para correções muitas vezes para contar. Embora tenha sido doloroso na época, certamente sou um engenheiro melhor agora e entendo a importância da revisão completa do código.
• Diversão! Por último, mas não menos importante, estagiar na Vivid foi o trabalho mais divertido que já tive. Aryaman, Jorge e Alberto estabeleceram um ambiente descontraído desde a primeira semana, e agora sinto que estou apenas trabalhando em um projeto de hackathon com meus grandes amigos. Em outros empregos, eu estaria ansioso para sair do trabalho às 17h, mas aqui me sinto feliz em ficar e trabalhar até quando quiser.

Enquanto escrevo este post, a poucas horas de nossa segunda festa de lançamento no mesmo telhado WeWork em que conheci Aryaman, Jorge e Alberto, quase desejo que eu também tivesse uma oferta da Big Tech para renegar e ingressar na Vivid. Em vez disso, estou voltando para Columbia para meu último ano de faculdade, levando comigo quatro novos amigos e a vontade de construir algo com o que aprendi.

Entrar vívido

Eu conheci Aryaman, Jorge e Alberto pessoalmente pela primeira vez quando eles desistiram de suas ofertas de emprego na Big Tech em uma festa da WeWork na cobertura. Tendo tido apenas uma breve conversa de café com Aryaman na semana anterior, achei muito revigorante ver a empolgação dos três com o que estavam trabalhando.

Eu tinha acabado de sair do meu estágio na Microsoft e havia estagiado na Meta no verão anterior. Eu senti que tinha uma boa noção de como seria a vida na Big Tech e, embora não odiasse, uma grande parte de mim também se perguntava como seria trabalhar em uma startup. Observar a equipe Vivid se alegrar ao desistir das ofertas dos meus sonhos de calouro foi um alerta - eu tinha que ver o que estava perdendo.

Não foi nenhuma surpresa que, um mês depois, eu estava assinando uma carta de oferta para ingressar como o primeiro estagiário da Vivid na primavera de 2023.

o pivô

Entrei no meu primeiro dia de trabalho na Vivid sem saber o que esperar.

No dia 1, fui atingido pela maior surpresa: a Vivid não estava mais construindo o Styler - seu principal produto que eles demonstraram para mim naquele telhado apenas alguns meses atrás. Percebi que estava entrando na empresa em um momento incrivelmente único - experimentando em primeira mão o que significa construir uma empresa do zero.

Fui imediatamente lançado em sessões de brainstorming enquanto a equipe idealizava novos rumos para a empresa. Eu rapidamente me atualizei com as ideias que estavam sendo lançadas e absorvi os prós e contras do que torna uma ideia melhor do que outra.

Algumas das principais conclusões de nossas sessões de brainstorming:

• É importante construir um produto que as pessoas realmente precisem . Não importa se sua ferramenta aumenta a produtividade de cada pessoa da equipe em 10% — ninguém está disposto a interromper seu fluxo de trabalho atual para uma pequena melhoria. Em vez disso, se houver dois ou três engenheiros que experimentam um aumento de produtividade de 200%, sua ferramenta será muito mais rígida.
• Os concorrentes não desqualificam uma ideia. Eu costumava pensar que se qualquer outra empresa, por menor que fosse, começasse a trabalhar em uma ideia semelhante à minha, eu não deveria persegui-la. Mas agora, vejo que essas empresas existem como prova de que existe um problema real que precisa ser resolvido.
• Visão de longo prazo é importante. Então, está deixando de lado uma má ideia. Fiquei surpreso quando soube que Vivid estava deixando de lado o Styler. Como usuário, achei que era um produto bem executado com um caso de uso sólido. Agora entendo que não havia um objetivo previsível de longo prazo com o Styler e o pivotamento foi essencial para o crescimento da empresa. Ser capaz de se afastar de uma ideia sem um caminho claro a seguir, independentemente da falácia do custo irrecuperável, é necessário para que as startups avancem rapidamente.

Abaixo está uma imagem da minha primeira contribuição de código para a equipe Vivid!

No final das duas primeiras semanas no Vivid, passei de não saber como escrever uma única linha do React para confiante de que poderia construir uma página do zero - mais aprendizado do que consegui em 12 semanas de estágios anteriores.

sincronização vívida

A segunda parte do meu estágio foi definida pelo Vivid Sync. Já sabíamos que havia um atrito substancial na transferência de desenvolvedores para designers. Mas, durante uma ligação com o cliente, um líder de engenharia compartilhou um insight importante: esse atrito tinha uma única causa raiz. Com o tempo, as bibliotecas Figma começam a divergir dos repositórios de código, o que causa problemas de comunicação consistentes entre designers e desenvolvedores.

Uma semana depois de termos a ideia, conseguimos um parceiro de design e começamos a desenvolver o produto, que era essencialmente um sistema de gerenciamento de tarefas que ligava os componentes do Figma a uma base de código por meio do Github Issues.

Fui encarregado de construir a interface do usuário da web, que se parecia com isto:

Mas, novamente, por mais que eu tenha achado a ideia e o produto ótimos, apenas uma semana depois de entregarmos o produto ao nosso parceiro de design, estávamos de volta à sala de reunião começando do zero novamente.

Brainstorming Pt. 2

O Vivid Sync tinha uma falha fatal - não resolveu o problema do cliente. O usuário final foi motivado pela promessa de limitar o desperdício de tempo de engenharia. Ao contrário do Styler, o Vivid Sync tinha uma visão clara de longo prazo, que era criar uma sincronização de ponta a ponta entre o Figma e o Code, mas o produto entregue não economizava tempo dos engenheiros - na verdade, aumentava a quantidade total de trabalho criando tarefas para trabalhos de manutenção.

A equipe estava empenhada em construir algo o mais rápido possível para nosso parceiro de design, mas, em retrospecto, houve avisos claros desde o início de que o valor agregado imediato do Sync pode não ser alto o suficiente.

Desta vez, eu estava preparado para o que estava por vir. Eu estabeleci meu objetivo de participar ativamente das discussões de ideação. Aprendi a escrever planilhas de hipóteses, conduzir pesquisas competitivas e gerenciar o fluxo e refluxo do pensamento divergente sendo reduzido a uma ideia específica. Acima de tudo, aprendi quanto impacto minha opinião poderia ter em uma equipe pequena.

Figma para Código

Meu histórico de commits do GitHub deixou claro exatamente quanto tempo passamos idealizando - 3 semanas. Decidimos mergulhar direto na direção do maior valor para os clientes - convertendo os designs do Figma em código de front-end utilizável. Havia uma visão clara de longo prazo, estávamos abordando diretamente o ponto problemático do usuário final e todos tínhamos níveis muito mais altos de convicção.

Quando se tratava de construção, assumi a propriedade da integração de novos usuários. O objetivo da integração era permitir que o Vivid gerasse código usando componentes já existentes na base de código do usuário.

O principal desafio técnico foi obter os componentes de código do usuário e vinculá-los aos ativos Figma correspondentes, de modo que, sempre que o ativo Figma fosse usado, pudéssemos chamar o componente correto no código. As propriedades do componente também precisavam ser combinadas para que nossa ferramenta pudesse chamar esses componentes sem erros.

O recurso de integração tinha algumas peças diferentes:

1. Aplicativo Github . O aplicativo Github se conecta a um repositório e retorna todos os arquivos .tsx no repositório conectado por meio de uma API REST
2. Microsserviço Python . O microsserviço Python — construído com Flask — usa um algoritmo de correspondência NLP para combinar semanticamente os componentes de código aos componentes Figma.
3. Pacote de travessia de código . O pacote de travessia de código permite conectar o aplicativo Github e o microsserviço Python juntos. Ele obteve arquivos .tsx do aplicativo Github e retornou os componentes correspondentes do microsserviço Python.
4. Plataforma de correspondência de integração. Por fim, a interface do usuário permitiu que as correspondências fossem feitas e enviadas a um banco de dados no back-end.

Fotos divertidas!