Meu primeiro dia numa software house — o choque
Saí de uma telco com processo lento e entrei numa software house com múltiplos clientes, prazos curtos e tecnologia diferente toda semana. O choque foi real — e necessário.
Telco grande para software house pequena é um choque.
Não porque um seja melhor que o outro. Porque são ambientes radicalmente diferentes, com ritmos diferentes, com o que é valorizado diferente, com o que é considerado "bom trabalho" diferente. E eu não estava preparado para a magnitude da diferença.
Na Oi, eu tinha anos de contexto. Sabia os sistemas, sabia as pessoas, sabia as regras não escritas. Tinha estabilidade — não a estabilidade de um ambiente seguro, mas a estabilidade de saber o que esperar.
Na POA Software, no primeiro dia, eu não sabia nada disso.
O primeiro choque foi o ritmo. Software house trabalha com múltiplos clientes ao mesmo tempo, com prazos muito mais curtos do que empresa grande. O que numa telco levava meses de planejamento e aprovação, numa software house precisava estar rodando em semanas. Às vezes em dias.
Minha primeira semana, eu fui apresentado a dois projetos ativos e um novo cliente que estava chegando. Cada um com stack diferente. Cada um com contexto diferente. Eu precisava entrar em cada um com velocidade, e eu vinha de um ambiente onde a velocidade de onboarding não era uma prioridade.
O segundo choque foi a tecnologia. Na telco, você usa o que a empresa usa. Stack é definido, ferramentas são aprovadas, você se aprofunda naquilo. Na software house, a tecnologia muda com o cliente. Um cliente quer PHP. Outro quer Node. Outro tem uma aplicação legada em Python 2 que ninguém mais mantém e você precisa entender rápido.
Breadth em vez de depth. Em empresa grande, você vai fundo em poucas coisas. Em software house, você vai largo em muitas coisas.
Nenhum dos dois é superior — são trade-offs diferentes. Mas meu modo de aprendizado estava calibrado para depth, e o ambiente exigia breadth. Tive que recalibrar.
O terceiro choque foi mais sutil: a proximidade com o cliente.
Em empresa grande, o cliente é abstrato. Você implementa o que o produto manager pediu que foi aprovado em reuniões que você não participou baseado em feedback que chegou filtrado por três camadas. Você raramente tem contato direto com quem vai usar o que você constrói.
Em software house, o cliente está no Slack. Às vezes numa reunião de quinta de manhã. Às vezes mandando mensagem às 18h pedindo uma mudança para amanhã. A distância entre "o que o cliente quer" e "o que você faz" é quase zero.
Isso é assustador no começo porque você está exposto. Mas é valioso porque você aprende como o que você faz afeta alguém real.
Lembro do primeiro bug que identifiquei em produção no novo emprego. Em empresa grande, havia processo: abre ticket, categoriza, vai para a fila, alguém prioriza, você recebe a tarefa, resolve, passa por review, vai para staging, sobe em janela de manutenção.
Na software house: "tem bug, resolve e sobe hoje à tarde."
Primeiro instinto foi entrar em pânico. Segundo instinto foi resolver o bug. O bug foi resolvido, subiu, funcionou.
Processo é útil em escala. Em escala menor, processo vira burocracia. O ambiente menor me ensinou a confiar mais no meu julgamento e menos no protocolo — o que foi, descobri depois, exatamente o que eu precisava aprender.
Sobre o estado em que eu cheguei: ainda estava em processo de recuperação do burnout. O ambiente novo ajudou — novidade e variedade são estimulantes. Mas também foi cansativo, porque eu precisava de energia para adaptar e minha reserva de energia ainda estava recarregando.
Não recomendo fazer uma transição grande de emprego enquanto ainda está em burnout, se você tiver escolha. Eu não tinha a opção de esperar mais — precisava de renda, precisava sair do ambiente anterior. Mas é útil saber que o custo de adaptar é maior quando você está com recurso reduzido.
Essa semana: você está num ambiente de depth ou breadth agora? Qual desses modos de aprendizado você tem mais treino? O que aconteceria se você passasse um mês deliberadamente praticando o oposto?