Seu primeiro mês em uma startup deixa uma marca. Não há uma rampa de aprendizado lenta, nem uma semana assistindo a vídeos de integração enquanto espera o TI provisionar um laptop. No primeiro dia, espera-se que você construa, quebre e conserte coisas que pessoas reais realmente usarão. Aprendi isso rapidamente ao ingressar na Treevah, uma empresa que desenvolve ferramentas para ajudar candidatos a organizar suas candidaturas. Trinta dias em um ambiente de estágio inicial me ensinaram mais sobre desenvolvimento de software do que qualquer sala de aula ou competição jamais poderia ensinar.
O Ritmo é Implacável
Na Treevah, o trabalho não espera você se acomodar. A equipe está se esforçando para mover o produto do alfa para o beta e, eventualmente, para a produção, o que significa que cada tarefa tem peso. Não há espaço para trabalhos de preenchimento ou tarefas que são arquivadas na caixa de entrada de um professor. Quando você lança uma funcionalidade, ela vai direto para usuários que estão tentando acompanhar prazos, entrevistas e acompanhamentos enquanto buscam seu próximo emprego.
O ritmo é exaustivo. Você se move rápido todos os dias, e a carga de trabalho acumula mais rápido do que você espera. Os prazos não são abstratos; eles estão ligados a marcos que determinam se a empresa pode atender mais candidatos ou corrigir lacunas na experiência atual. Esse peso desgasta você. Mas também cria uma clareza que é difícil de encontrar em organizações maiores. Quando termino uma tarefa, consigo traçar uma linha direta entre o que construí e uma pessoa que agora tem mais facilidade para gerenciar sua busca por emprego. Esse senso de dono é raro, e faz com que o cansaço pareça valer a pena.
As Habilidades se Acumulam Mais Rápido em Produção
Antes deste verão, grande parte da minha energia era voltada para palestras e hackathons. Ambos me ensinaram a pensar rápido e a apresentar ideias sob pressão. Hackathons, especialmente, treinam você para montar demonstrações funcionais às pressas em poucas horas. Mas há uma diferença entre um projeto de fim de semana que impressiona juízes e um código de produção que precisa sobreviver ao contato com centenas de usuários reais.
Passar um mês focado em desenvolvimento web na Treevah fechou essa lacuna. Na escola, os projetos vêm com proteções. O escopo é fixo, os requisitos são entregues mastigados e, se o seu esquema de banco de dados falhar, você pode justificar isso em um slide de apresentação. Dentro de uma startup, seu esquema tem que aguentar o tranco porque candidatos reais estão armazenando dados reais de candidaturas nele. O ciclo de feedback é imediato e implacável. Quando uma página carrega lentamente ou um formulário falha ao salvar, ninguém se importa com sua nota; eles se importam se acabaram de perder uma oportunidade.
Essa pressão força o crescimento. Você aprende a escrever um código mais limpo não porque uma rubrica exige, mas porque você será o responsável por depurá-lo à meia-noite. Você aprende a fazer perguntas mais aguçadas durante o code review porque implantar uma build quebrada significa que usuários reais baterão de frente com um problema. As oportunidades aqui simplesmente impactam mais forte do que projetos escolares. Os erros custam mais caro, e por isso as lições fixam melhor.
A Realidade Humilhante dos Bugs
Se há um mito que eu gostaria de destruir, é a ideia de que todo bug de software é uma falha lógica dramática. Alguns são, é claro. Mas muitos dos bugs que encontrei na Treevah eram irritantemente pequenos. Eles se escondiam à vista de todos e desperdiçavam horas da minha vida.
Dois padrões continuavam aparecendo. O primeiro eram regras de CSS duplicadas. Quando vários desenvolvedores mexem no mesmo componente ao longo de vários sprints, as folhas de estilo incham. Uma pessoa adiciona uma classe utilitária de margem, enquanto outra insere um valor fixo (hardcoded) no arquivo do componente. Nenhum dos dois está errado isoladamente. Mas, juntos, eles criam mudanças de layout ou guerras de especificidade que fazem um botão parecer correto no Chrome e quebrado no Safari. Rastrear isso significa abrir as ferramentas de desenvolvedor do navegador e percorrer os estilos computados linha por linha, em vez de ler uma lógica algorítmica elegante.
O segundo era definir elementos fora de suas divs pai. Um gatilho de modal ou um dropdown pode ser anexado ao nó errado no DOM. A tela parece quase correta, então você assume que a estrutura está sólida. Então, um conflito de z-index aparece, ou um evento de clique propaga para o manipulador errado, e de repente um usuário não consegue fechar um popup que está cobrindo seu formulário de candidatura. Esses não são quebra-cabeças de ciência da computação. São equívocos espaciais e estruturais que se acumulam quando você está se movendo rapidamente.
Alguns desses bugs levaram semanas para serem encontrados. Eu ficava encarando o código, me convencendo de que a lógica estava correta, e seguia por becos sem saída que não levavam a lugar nenhum. A frustração é real. Você sente que está deixando passar algo óbvio, e você está. Mas a satisfação de finalmente encontrar uma regra duplicada ou uma tag de fechamento mal posicionada é surpreendentemente