Primeiros 90 Dias: Manual Passo a Passo para Engenheiros de Software

Tem estado na linha da frente.

Reviu o seu currículo até este ficar impecável. Reforçou as suas competências e certificações.

Aperfeiçoou o seu GitHub, estudou perguntas sobre arquitetura de sistemas até estas se confundirem umas com as outras e clicou em «candidatar-me» mais vezes do que gostaria de contar.

Enfrentou o desafio das entrevistas — quadros brancos, exercícios para realizar em casa, silêncios constrangedores e tudo o resto. Elevou as suas competências e manteve a calma.

E depois… chegou a carta de oferta. Conseguiu o emprego! Agora começa o verdadeiro trabalho.

Porque, embora contratar seja difícil, integrar eficazmente é ainda mais difícil. É aqui que passa de candidato a colaborador e que as primeiras impressões se tornam duradouras. Os seus primeiros 90 dias estabelecerão as bases para tudo o que se seguirá.

Neste guia prático, explicarei como começar com o pé direito enquanto novo engenheiro de software, com conselhos práticos de dois profissionais experientes da área tecnológica que já passaram por isso, sabem o que funciona e conhecem bem o terreno. Mas, primeiro, comecemos por analisar com clareza o que realmente significa ser engenheiro de software atualmente.

O que é um engenheiro de software?

Por onde havemos de começar? A sério, poderia escrever-se um livro sobre este tema, em parte porque o termo é por vezes utilizado como um termo abrangente para várias funções possíveis que cobrem todas as fases do ciclo de vida do desenvolvimento de software. Por isso, outros títulos também podem ser relevantes neste contexto, como programador ou desenvolvedor. Utilizamos «engenheiro de software» como termo abrangente.

Eis uma definição sucinta de engenharia de software, da Michigan Technological University, para nos mantermos no caminho certo: «A engenharia de software é o ramo da informática que lida com a conceção, o desenvolvimento, os testes e a manutenção de aplicações de software. Os engenheiros de software aplicam princípios de engenharia e conhecimentos de linguagens de programação para criar soluções de software para os utilizadores finais.»

Se reduzirmos isto aos termos mais simples, o resultado será algo deste género: os engenheiros de software criam coisas digitais para serem utilizadas por pessoas e máquinas. Em vez de utilizarem um martelo e pregos, utilizam código, juntamente com um conjunto de ferramentas como o Git e outros componentes. 

Devemos também mencionar uma das razões pelas quais muitas pessoas querem trabalhar como engenheiros de software: o emprego pode ser bem remunerado. O site de carreiras Glassdoor estima que a remuneração total mediana dos engenheiros de software seja de $147,000 por ano (última verificação: 28 de abril de 2025), embora os valores reais variem em função de fatores como a experiência, a localização e o setor.

Vejamos agora algumas dicas e ideias práticas para começar com o pé direito.

Os primeiros 30 dias

No nosso artigo complementar sobre carreiras na cibersegurança, referimos que os primeiros 30 dias acabam por se resumir a aprender. Isso inclui tudo, desde bases de código e ferramentas até novos rostos e novos lugares. E continua a ser verdade neste caso, embora com alguns ajustes.

Dica n.º 1: Nem todas as arquiteturas tecnológicas são iguais

Adaptar-se à sua nova função deve envolver tanto a aprendizagem sobre as pessoas e os processos como a aprendizagem sobre a base de código ou a arquitetura tecnológica.

«Com base na minha experiência em grandes empresas, é mais importante compreender as pessoas [e] os processos do que a arquitetura do código», afirma Justin Garrison, Diretor de Produto da Sidero Labs. Antes de assumir a sua função atual, Justin trabalhou como Defensor sénior de programadores na AWS e em várias funções de engenharia na Disney, incluindo a de Engenheiro de software sénior. 

Dica n.º 2: Compreenda como a empresa gera receitas

Para maximizar o seu valor, tem de compreender como a organização gera o seu valor.

«Além de aprenderem a arquitetura tecnológica e os requisitos, os engenheiros devem perceber como a empresa cria valor e recebe pelos seus serviços», explica-nos Chris Carter, Gestor Principal de Produto na NetApp Instaclustr. Antes de assumir a sua função atual, Chris começou na empresa como engenheiro de desenvolvimento sénior e líder de uma equipa de engenharia. E prossegue:

«Subscrições diretas? Equipa de vendas no terreno e acordos personalizados? Audiência e publicidade? Perceba como a empresa se avalia a si própria e como passa do código ao KPI.»

Construa essa compreensão desde o início. É pouco provável que os engenheiros de software capazes de estabelecer a ligação entre o seu código e as finanças da empresa passem de moda.

“Ao compreender como a própria empresa mede o seu sucesso, pode posicionar-se para fazer parte da criação desse sucesso e contribuir para os resultados financeiros,” afirma Chris.

Dica n.º 3: Clone o repositório, mas não se precipite a efetuar a submissão

É claro que está ansioso por criar o seu primeiro PR. Mas trate a base de código como um organismo vivo: observe os seus padrões, compreenda a sua anatomia e faça perguntas antes de intervir. Utilize as funcionalidades de navegação de código do seu IDE, comandos grep ou a pesquisa no repositório para acompanhar o fluxo de dados e da lógica pelo sistema.

E se ficar bloqueado? Tente reproduzir o comportamento localmente e depois rastreá-lo passo a passo. Os depuradores são subvalorizados e falar com o pato de borracha continua a funcionar.

Dica profissional: Analise os PRs recentemente integrados para compreender o estilo do código, a cultura de revisão e o verdadeiro significado de “concluído”.

Os primeiros 60 dias

Uma das melhores formas de se adaptar rapidamente é mostrar curiosidade, não apenas sobre o que o código faz, mas também sobre por que razão o faz dessa forma.

Dica n.º 4: Pergunte: “Porque foi isto criado desta forma?”

O código legado pode parecer esparguete, mas muitas vezes há substância no molho. Restrições impostas por um serviço entretanto descontinuado, uma escolha entre desempenho e outros fatores, um requisito comercial de uma funcionalidade de produto entretanto retirada — estas decisões têm uma história. Conhecer essa história ajuda a evitar sugerir algo que já foi tentado (e falhou), além de reforçar a sua credibilidade.

Comece pela documentação interna (mesmo que esteja desatualizada). Depois, peça a um colega que lhe explique algo confuso e trate-o como um coautor da história do sistema.

“Que decisões estão codificadas neste código?” é uma pergunta melhor do que “Porque é que este código é tão mau?”

Dica n.º 5: Identifique as “regras não escritas” da sua equipa

Todas as organizações de engenharia as têm. Talvez a equipa prefira RFC no Notion em vez de tarefas no Jira, ou talvez todos façam a implementação às quintas-feiras, ou talvez os testes unitários sejam opcionais — mas os testes e2e sejam sagrados.

Estas normas nem sempre estarão num manual, mas moldarão o seu sucesso tanto quanto as suas competências de programação. Observe os padrões no Slack, analise as mensagens de submissão do Git e pergunte aos colegas o que gostariam de ter sabido quando entraram para a equipa.

Dica n.º 6: Continue a reunir-se com pessoas — e a aprender com elas

Justin, da Sidero Labs, defende que conhecer pessoas ajuda os engenheiros a compreender como os sistemas funcionam em conjunto para além do código: “No final dessas reuniões, tornou-se muito mais fácil compreender por que razão os sistemas têm o aspeto que têm.”

Isso traz todo o tipo de benefícios em cadeia, incluindo reduzir a sua tensão arterial ao ler código que, à primeira vista, parece não fazer sentido. Se foi uma pessoa que o escreveu, é provável que essa pessoa tivesse uma razão para o escrever dessa forma, e essas razões podem incluir variáveis organizacionais, limitações de tempo e muito mais. 

Este tipo de compreensão holística ajuda no que diz respeito à cultura e à comunicação da equipa, mas também à empatia e à diplomacia quando chegar o momento de procurar e sugerir melhorias.

Os primeiros 90 dias

Já cresceu: “Aos 90 dias, deverá já estar integrado e, esperemos, ser capaz de assumir a responsabilidade por tarefas maiores,” afirma Chris, da NetApp Instaclustr.

Esta última fase consiste realmente em planear e começar a executar. Onde pode
começar a causar um impacto real?

Dica n.º 7: Comece a otimizar com propósito e impacto

Ao fim de 90 dias, já não é apenas o “novo engenheiro” — é um colaborador em ascensão. Isso significa que está na altura de procurar oportunidades para melhorar as coisas. Mas há uma ressalva: nem todas as melhorias merecem ser perseguidas e nem todos os erros merecem ser corrigidos.

“Não se trata de criar uma longa lista de coisas que estão avariadas,” afirma Chris. “Trata-se de compreender a empresa, o cliente e o contexto — e depois utilizar esse conhecimento para identificar formas significativas de melhorar.”

Eis como Chris e a sua equipa abordam essa mentalidade:

• Pense a montante: Não salte diretamente para as soluções — comece por escrever tarefas claras que descrevam o problema.
• Defina prioridades com discernimento: Aprenda como a sua equipa pondera o impacto, o esforço e a urgência. Um erro trivial na interface de uma página descontinuada? Provavelmente não é uma emergência.
• Uma mentalidade centrada no cliente: Pergunte sempre: “Isto será importante para um utilizador real?” Se não for, arquive-o e avance.

Depois de aprender os sistemas e a cultura, comece a procurar tarefas de maior alavancagem — coisas que reduzam a fricção, melhorem a entrega ou reforcem a experiência do cliente.

“Ao entregar de forma consistente trabalho que faz avançar os objetivos da empresa, será rapidamente reconhecido como alguém que ‘percebe’ — e a quem podem ser confiadas responsabilidades maiores,” afirma Chris.

Dica n.º 8: Entregue algo. Qualquer coisa. Mas assuma a responsabilidade.

Ao 90.º dia, não precisa de ter reescrito um serviço essencial nem de ter lançado uma nova funcionalidade sozinho. Mas deve conseguir apontar para uma coisa, por mais pequena que seja, que tenha entregue e pela qual tenha assumido a responsabilidade de ponta a ponta.

Pode ser:

• Uma correção de um erro que reduziu a fricção para os utilizadores
• Um ajuste no pipeline de CI/CD que acelerou as compilações
• Uma revisão completa do README que ajudou a pessoa recém-contratada seguinte
• Uma otimização da retaguarda que reduziu em 50 ms o tempo de uma consulta comum

Não tem de ser algo apelativo — tem de ser útil. O impacto não depende da aparência; depende da funcionalidade.

Mantra do engenheiro: “Tornei a vida da equipa 1% melhor esta semana?”

Dica n.º 9: Crie uma lista pessoal de aprendizagem pendente

Não vai dominar toda a base de código, a infraestrutura e a lógica empresarial em 90 dias. Não há problema. O que importa é o que fará a seguir.

Crie uma “lista de tarefas pendentes” pessoal com as competências e lacunas de conhecimento. Anote:

• Áreas do sistema que ainda não compreende
• Ferramentas ou estruturas que quer aprender mais a fundo (por exemplo, Kubernetes, gRPC, Terraform)
• Dívida técnica ou particularidades que quer rever

Depois, dê prioridade a uma coisa por sprint e assinale-a como concluída. Não está apenas a aprender o sistema — está a conceber o seu roteiro de crescimento.

Subscreva a newsletter do The CTO Club para receber mais guias práticos para os seus primeiros 90 dias em qualquer função tecnológica!