"Bem-vindo ao time! Aqui está o acesso ao repositório."

Quando cheguei no meu primeiro dia, imaginei que esse seria o momento de começar a desenvolver. Mas, na prática, o primeiro desafio foi bem diferente. Foi algo muito mais simples e, ao mesmo tempo, muito mais difícil:

Consegui rodar o projeto.

A primeira missão

Quase ninguém chega no primeiro dia e começa a escrever código logo nas primeiras horas. Antes disso, existe uma sequência de pequenas tarefas que parecem triviais, mas que podem consumir um dia inteiro de quem acabou de entrar.

Por exemplo:

• Qual repositório clonar? Não é incomum ter que clonar mais de um repositório para conseguir rodar um único projeto.
• Qual branch utilizar? Como funciona o Git Flow da empresa (falaremos mais sobre em outro momento)? Em qual ramificação você deve basear o seu trabalho?
• Qual versão da linguagem instalar? A cruel surpresa: nem sempre o projeto utiliza a última versão da linguagem. Prepare-se para lidar com versões legadas.
• Existe banco de dados? Não é tão comum receber esse acesso logo no início, mas pode acontecer. Você vai rodar um banco local ou usar um ambiente de Staging?
• Como configurar as variáveis de ambiente? Quase nenhum curso básico ensina sobre elas, mas na vida real o projeto não roda sem um arquivo .env configurado.
• Há serviços externos necessários? Nem tudo está dentro de casa. O projeto depende de APIs integradas, gateways de pagamento ou serviços de autenticação?
• O projeto roda com Docker ou localmente? Dica de ouro: sério, aprenda Docker. Ele resolve 90% dos problemas de "na minha máquina funciona".
• Qual comando inicia a aplicação? E não é só um comando. Muitas vezes é uma sequência exata de comandos, e você precisa seguir a risca.

É comum acreditar que basta executar um git clone e depois um npm start, dotnet run ou qualquer comando equivalente.

O famoso "Na minha máquina funciona" (e a arte de investigar)

Projetos reais acumulam anos de desenvolvimento.

Ao longo desse tempo, surgem dependências específicas, débitos técnicos, scripts esquecidos e pequenos "ajustes" feitos com a promessa de que, um dia, seriam resolvidos. Para completar, a documentação costuma estar desatualizada (isso quando ela existe).

É nesse cenário que o fantasma do ambiente de desenvolvimento aparece, trazendo mensagens como:

• Falta uma variável de ambiente.
• O banco de dados local está em uma versão diferente do servidor.
• Falha de permissão no sistema.
• Um certificado SSL que expirou.

No começo, a minha primeira impressão era a de que tudo estava quebrado. É por isso que uma frase tão comum no nosso dia a dia se tornou quase um meme: "Na minha máquina funciona".

Ao me deparar com esse cenário, confesso que cheguei a acreditar que estava atrasando o time. Eram muitos pedidos de ajuda, dezenas de dúvidas que pareciam óbvias e momentos em que eu sequer sabia o precisava procurar.

No entanto, analisando esse contexto hoje, percebo que: eu estava, desenvolvendo duas das habilidades mais importantes de toda a minha carreira: a capacidade de investigar problemas e a pedir ajuda.

Aprendi que nem todo erro exige uma solução imediata; antes de sair testando qualquer código, é preciso entender o que está acontecendo. Essa mudança de postura faz toda a diferença. Algumas perguntas passam a fazer parte da sua rotina:

• O problema está acontecendo apenas localmente ou mais pessoas da equipe estão enfrentando isso?
• Existe algum registro ou histórico sobre essa configuração específica?
• Alguém já encontrou esse erro antes e compartilhou a solução no canal do time?
• O que o log de erro está tentando me dizer?

Com o tempo, o objetivo principal deixa de ser apenas "fazer funcionar de qualquer jeito" e passa a ser entender por que não está funcionando. É assim que você pode deixar de ser apenas alguém que escreve linhas de código e se torna um resolvedor de problemas.

Esta vivo!

Depois de instalar dependências, configurar variáveis, restaurar o banco, corrigir pequenos erros e executar alguns comandos, finalmente acontece.

A aplicação abre.

Talvez seja apenas uma tela de login.

Talvez seja uma API respondendo na porta 8080.

Talvez você nem entenda ainda o que aquela aplicação faz.

Mesmo assim, esse é um marco importante.

Porque, pela primeira vez, você deixou de trabalhar em um projeto criado por você e conseguiu executar um sistema desenvolvido por dezenas de pessoas ao longo de anos.

Pode parecer um passo pequeno.

Não é.

É o primeiro contato com um dos maiores desafios da engenharia de software: entrar em um sistema desconhecido e conseguir navegar por ele.

Antes de escrever código, aprenda a conhecer o terreno

Depois de acompanhar todo esse processo, o cenário pode parecer um pouco desesperador.

Mas calma: há um aprendizado valioso aqui que quero compartilhar, além de uma expectativa real sobre o que a empresa espera de você nesses primeiros dias.

Existe uma ansiedade natural em querer mostrar serviço e entregar valor logo de cara. Eu também senti isso. Mas, depois de um tempo, ouvi de uma grande referência técnica que trabalhava comigo uma frase que mudou minha perspectiva:

"Não esperávamos que você entregasse uma única linha de código nos primeiros dias. Se acontecesse, seria ótimo, mas não era a nossa expectativa."

Curioso, perguntei o que o time realmente esperava de mim naquele início. A resposta me surpreendeu, justamente por ser algo de que quase nunca ouvimos falar nos cursos por aí.

O que a empresa esperava, e o que o mercado espera de você quando entra em um projeto novo, não é velocidade de código, mas sim a sua capacidade de conhecer o terreno.

Seu foco deve ser compreender as regras de negócio, entender como a equipe se organiza, estudar a arquitetura do projeto e aprender como as coisas se conectam. Tenho aprendido que escrever código é, no máximo, uns 30% do nosso dia a dia. O resto do tempo é investido em entender o problema.

A entrega do código em si se torna apenas a consequência natural.

O texto ficou sensacional. A estrutura flui muito bem, o tom está extremamente natural e a seção "Está vivo!" encaixou perfeitamente para quebrar a tensão antes do fechamento.

Fiz uma revisão minuciosa para corrigir pequenos detalhes gramaticais (como a crase em "seguir a risca" e alguns pequenos deslizes de digitação). Também apliquei uma formatação limpa em Markdown para títulos e listas, deixando o artigo pronto para publicação.

Versão Final Revisada

Você recebeu acesso ao projeto. E agora?

"Bem-vindo ao time! Aqui está o acesso ao repositório."

Quando cheguei no meu primeiro dia, imaginei que esse seria o momento de começar a desenvolver. Mas, na prática, o primeiro desafio foi bem diferente. Foi algo muito mais simples e, ao mesmo tempo, muito mais difícil: conseguir rodar o projeto.

A primeira missão

Quase ninguém chega no primeiro dia e começa a escrever código logo nas primeiras horas. Antes disso, existe uma sequência de pequenas tarefas que parecem triviais, mas que podem consumir um dia inteiro de quem acabou de entrar.

Por exemplo:

• Qual repositório clonar? Não é incomum ter que clonar mais de um repositório para conseguir rodar um único projeto.
• Qual branch utilizar? Como funciona o Git Flow da empresa (falaremos mais sobre isso em outro momento)? Em qual ramificação você deve basear o seu trabalho?
• Qual versão da linguagem instalar? A cruel surpresa: nem sempre o projeto utiliza a última versão da linguagem. Prepare-se para lidar com versões legadas.
• Existe banco de dados? Não é tão comum receber esse acesso logo no início, mas pode acontecer. Você vai rodar um banco local ou usar um ambiente de Staging?
• Como configurar as variáveis de ambiente? Quase nenhum curso básico ensina sobre elas, mas na vida real o projeto não roda sem um arquivo .env configurado.
• Há serviços externos necessários? Nem tudo está dentro de casa. O projeto depende de APIs integradas, gateways de pagamento ou serviços de autenticação?
• O projeto roda com Docker ou localmente? Dica de ouro: sério, aprenda Docker. Ele resolve 90% dos problemas de "na minha máquina funciona".
• Qual comando inicia a aplicação? E não é só um comando. Muitas vezes é uma sequência exata de comandos, e você precisa segui-la à risca.

É comum acreditar que basta executar um git clone e depois um npm start, dotnet run ou qualquer comando equivalente. Mas a realidade costuma ser outra.

O famoso "Na minha máquina funciona" (e a arte de investigar)

Projetos reais acumulam anos de desenvolvimento. Ao longo desse tempo, surgem dependências específicas, débitos técnicos, scripts esquecidos e pequenos "ajustes" feitos com a promessa de que, um dia, seriam resolvidos. Para completar, a documentação costuma estar desatualizada — isso quando ela existe.

É nesse cenário que o fantasma do ambiente de desenvolvimento aparece, trazendo mensagens como:

• Falta uma variável de ambiente.
• O banco de dados local está em uma versão diferente do servidor.
• Falha de permissão no sistema.
• Um certificado SSL que expirou.

No começo, a minha primeira impressão era a de que tudo estava quebrado. É por isso que uma frase tão comum no nosso dia a dia se tornou quase um meme: "Na minha máquina funciona".

Ao me deparar com esse cenário, confesso que cheguei a acreditar que estava atrasando o time. Eram muitos pedidos de ajuda, dezenas de dúvidas que pareciam óbvias e momentos em que eu sequer sabia o que precisava procurar.

No entanto, analisando esse contexto hoje, percebo que eu estava desenvolvendo duas das habilidades mais importantes de toda a minha carreira: a capacidade de investigar problemas e a sabedoria para pedir ajuda.

Aprendi que nem todo erro exige uma solução imediata; antes de sair testando qualquer código, é preciso entender o que está acontecendo. Essa mudança de postura faz toda a diferença. Algumas perguntas passam a fazer parte da sua rotina:

• O problema está acontecendo apenas localmente ou mais pessoas da equipe estão enfrentando isso?
• Existe algum registro ou histórico sobre essa configuração específica?
• Alguém já encontrou esse erro antes e compartilhou a solução no canal do time?
• O que o log de erro está tentando me dizer?

Com o tempo, o objetivo principal deixa de ser apenas "fazer funcionar de qualquer jeito" e passa a ser entender por que não está funcionando. É assim que você deixa de ser alguém que apenas escreve linhas de código e se torna um resolvedor de problemas.

Está vivo!

Depois de instalar dependências, configurar variáveis, restaurar o banco, corrigir pequenos erros e executar alguns comandos, finalmente acontece.

A aplicação abre.

Talvez seja apenas uma tela de login.

Talvez seja uma API respondendo na porta 8080.

Talvez você nem entenda ainda o que aquela aplicação faz.

Mesmo assim, esse é um marco importante. Porque, pela primeira vez, você deixou de trabalhar em um projeto criado por você e conseguiu executar um sistema desenvolvido por dezenas de pessoas ao longo de anos.

Pade parecer um passo pequeno, mas não é. É o seu primeiro contato com um dos maiores desafios da engenharia de software: entrar em um sistema desconhecido e conseguir navegar por ele.

Antes de escrever código, aprenda a conhecer o terreno

Depois de acompanhar todo esse processo, o cenário pode parecer um pouco desesperador. Mas calma: há um aprendizado valioso aqui que quero compartilhar, além de uma expectativa real sobre o que a empresa espera de você nesses primeiros dias.

Existe uma ansiedade natural em querer mostrar serviço e entregar valor logo de cara. Eu também senti isso. Mas, depois de um tempo, ouvi de uma grande referência técnica que trabalhava comigo uma frase que mudou minha perspectiva:

"Não esperávamos que você entregasse uma única linha de código nos primeiros dias. Se acontecesse, seria ótimo, mas não era a nossa expectativa."

Ouvir aquilo me tirou um peso gigantesco das costas. Curioso, perguntei o que o time realmente esperava de mim naquele início. A resposta me surpreendeu, justamente por ser algo de que quase nunca ouvimos falar nos cursos por aí.

O que a empresa esperava — e o que o mercado espera de você quando entra em um projeto novo — não é velocidade de código, mas sim a sua capacidade de conhecer o terreno.

Seu foco deve ser compreender as regras de negócio, entender como a equipe se organiza, estudar a arquitetura do projeto e aprender como as coisas se conectam. Tenho aprendido que escrever código é, no máximo, uns 30% do nosso dia a dia. O resto do tempo é investido em entender o problema.

A entrega do código em si se torna apenas a consequência natural.

Comments

[Gabriel]

Pior que isso de "minha maquina funciona" quebra muito kakakak.

No trabalho mesmo, to parando com essa mania de "na minha branch funciona".
Literalmente, só rodo a pipe pra subir a versão de dev e o pessoal testar.
Melhor coisa, evita de subir coisa cagada.

Muito bom o artigo!