O que dois anos de software house me ensinaram sobre como engenheiros crescem
Software house tem uma reputação mista entre devs. Depois de dois anos lá, entendo por que — e entendo também o que ela entrega que outros ambientes não entregam do mesmo jeito.
Software house tem uma reputação ambígua entre desenvolvedores.
De um lado, você ouve: "você vai aprender muito, muitos projetos, muitas tecnologias." De outro: "é exploração disfarçada de oportunidade, cliente difícil, prazo impossível, você vale mais do que estão pagando."
Depois de dois anos numa software house, entendo as duas visões. São as duas verdades ao mesmo tempo.
O que software house entrega de único:
Variedade de contextos. Em dois anos, trabalhei em projetos de e-commerce, sistema de gestão para clínica médica, dashboard de monitoramento industrial, aplicativo de delivery regional. Cada um tinha domínio diferente, restrições diferentes, usuários com necessidades diferentes.
Essa variedade tem um efeito específico: você aprende a mapear problemas novos rapidamente. Você não tem o luxo de semanas de onboarding — você entra num contexto, entende o essencial, e começa a contribuir. Esse ritmo acelera uma habilidade que demora mais para desenvolver em quem fica anos no mesmo produto.
Volume de decisões. Em software house você toma mais decisões de design por semana do que em product company onde você trabalha no mesmo sistema por anos. Você erra mais, mas também aprende mais rápido a calibrar julgamento.
O que é real nas críticas:
Prazo é frequentemente apertado. Não por incompetência de gestão — por estrutura do negócio. O cliente pagou por uma entrega. A entrega tem data. Quando a estimativa estava errada ou o escopo cresceu, o prazo não cresce proporcionalmente. Você aprende a trabalhar sob pressão. Você também aprende a estimar melhor, porque estimativas ruins têm consequência imediata.
A profundidade às vezes fica limitada. Quando você passa seis semanas num projeto e vai para o próximo, você raramente fica tempo suficiente para ver as consequências de longo prazo das suas decisões de design. Você planta uma árvore e não vê ela crescer. Isso é uma limitação real de aprendizado.
Salário raramente acompanha valor de mercado no ritmo de uma big tech. O modelo de negócio da software house tem margens menores. Quem cresce rápido eventualmente percebe que o crescimento de habilidade está superando o crescimento de compensação.
O que eu faria diferente se voltasse:
Documentaria mais as decisões de design em cada projeto. Não para o cliente — para mim. Retrospectiva de cada projeto: o que funcionou, o que não funcionou, o que eu faria diferente. Dois anos de projetos sem documentação pessoal = dois anos de experiências que se dissolvem mais rápido do que deveriam.
Buscaria projetos mais longos quando possível. Projetos de dois a três meses, se o contexto permitisse, dariam mais profundidade. Projetos de três a quatro semanas são aprendizado de largura, raramente de profundidade.
Sairia um ano antes do que saí. A software house me ensinou o que precisava ensinar antes do que eu percebi. Quando você se encontra repetindo padrões que já domina sem aprender algo novo, é tempo de mudar de contexto.
Para quem está considerando software house como opção de carreira:
É um acelerador, não um destino. Dois anos bem aproveitados em software house podem equivaler a mais tempo de aprendizado em ambientes de produto mais lentos. Mas o objetivo deve ser usar essa fase como base e depois ir para onde a profundidade e a complexidade de sistemas aumentam.
A pergunta que eu me faria a cada seis meses: "o que aprendi nos últimos seis meses que não sabia antes?" Se a resposta for pobre, é sinal de que o contexto já deu o que tinha para dar.
Essa semana: se você está numa software house — ou em qualquer trabalho — faça esse exercício: liste três coisas que você aprendeu nos últimos seis meses que não sabia antes de começar. Se a lista estiver vazia, vale investigar o que está impedindo esse aprendizado e se o ambiente atual ainda é o certo para essa fase da sua carreira.