Deploy na Sexta #24: Iniciando em uma nova empresa
Como organizo minha entrada em um novo time?
Em 2012, dei meu primeiro passo no mercado da tecnologia e conquistei uma vaga de estágio. Lembro do mix de emoções que sentia na época: uma mistura de ansiedade e empolgação. Eu vinha estudando a bastante tempo e estava ansiosa para finalmente colocar tudo que aprendi na teoria em prática. Apesar de todo o entusiasmo, também tinha medo e dúvidas: será que realmente conseguiria atender às expectativas colocadas sobre mim nessa experiência profissional?
Mesmo depois de alguns anos na área, começar em uma empresa continua me causando o mesmo mix de sensações. Esse período inicial, conhecido como onboarding, é fundamental para a adaptação em um novo ambiente. Algumas empresas possuem um processo de integração muito bem estruturado, com roteiros detalhados e recursos para nos auxiliar. Estes programas são projetados para minimizar a incerteza e acelerar a eficácia. Por outro lado, há organizações onde o onboarding é menos definido, ou até mesmo inexistente, deixando a gente navegar por si nos processos, pessoas e políticas. Nesses casos, a experiência pode ser desafiadora, mas tenho meu próprio jeitinho de me adaptar a um novo trabalho.
Iniciando com autonomia em um novo projeto ✌
O primeiro passo é sempre entender as expectativas e objetivos da minha contratação. Procuro entender claramente o que é esperado em termos de entregas, prazos e qualidade do trabalho. Tenho claro o meu papel no novo lugar.. Faço isso marcando uma call com o novo time, me apresentando, contando minha história, mostrando áreas de interesse, tecnologias que domino ou que tenho dificuldade e que preciso de apoio. Gosto de construir relacionamentos positivos, gosto de mostrar que estou disposta a aprender e me adaptar, além de estar interessada em contribuir para a equipe desde o início.
Outro aspecto fundamental é conhecer outros departamentos com os quaisvou me relacionar. Peço reuniões de introdução com times que podem se relacionar com o meu. Me aproximo dos demais times de backend, times de arquitetura, infraestrutura e principalmente analistas para deixar um canal aberto de comunicação e construir relacionamentos importantes desde o começo. Nestas reuniões tento observar e perguntar sobre a cultura da empresa, como as decisões são tomadas, como as equipes colaboram e quais são os valores da empresa.
Enquanto rolam essas reuniões, sempre pergunto sobre ferramentas e tecnologias que a empresa usa, desde os sistemas de versionamento, ferramentas de comunicação interna, frameworks, como Scrum ou Kanban é utilizado (se é utilizado) e como as tarefas são geralmente atribuídas e gerenciadas. Também vou preparando o meu ambiente de desenvolvimento, instalando IDEs, ferramentas de gerenciamento de banco de dados e buscando acessos e permissões para leitura de repositórios de código.
Ah, e falando em código, com fontes na mão começo a estudar o que já existe desenvolvido. Dando atenção a alguns tópicos:
Estrutura e Arquitetura do Projeto: Começo pegando uma visão geral da estrutura do projeto, os principais diretórios e arquivos e entendendo para que servem. Busco por diagramas de arquitetura e documentações, se houverem, para visualizar como os componentes do sistema estão interligados.
Caminho dos Dados: Tento debugar as principais funcionalidades do projeto traçando o caminho que os dados percorrem através do sistema. Entendo como os dados são inseridos, processados e armazenados. Analiso integrações com serviços externos ou APIs e como elas são gerenciadas no código.
Padrões de Codificação e Convenções: Cada empresa é um universo, nem sempre encontraremos as convenções comuns de código da nossa linguagem de programação. Para contribuir da melhor maneira possível, me familiarizo com o estilo de codificação adotado pela equipe. Isso vai desde o idioma, convenções de nomenclatura, comentários e formatação e até requisitos para a aprovação de um novo código que entregarei no futuro.
Refatoração: Eu sei, é tentador sugerir imediatamente mudanças ou refatorações quando identificamos problemas em um projeto. Mas resista a essa impulsividade inicial. Antes de propor qualquer alteração, é essencial compreender as razões pelas quais o código foi estruturado dessa maneira. Frequentemente encontro sistemas mais antigos que dependem de bibliotecas que já não são mais atualizadas ou que operam com versões de linguagens de programação obsoletas. Esses fatores podem ter influenciado decisões de design e implementação que, à primeira vista, podem não parecer ideais. Entender o contexto é fundamental para avaliar se uma refatoração é viável ou mesmo necessária. Além disso, é importante considerar o impacto nas pessoas com nossas sugestões. Criticar o código de colegas que têm uma longa trajetória no projeto pode causar desconforto e até ressentimento. Refatorações devem ser propostas com respeito e sensibilidade, valorizando a experiência de cada um.
Em resumo, adoto essas iniciativas para facilitar minha integração na nova equipe, mas também destacar meu valor e minhas habilidades de adaptação em um ambiente que talvez não possua um sistema formal de suporte para novos membros. Ao colocar em prática algumas dessas estratégias, me posiciono para ser reconhecida como uma colaboradora valiosa. Afinal, na tecnologia, a capacidade de aprender de forma rápida e se adaptar às mudanças é valorizada e essencial para o sucesso.
Esse guia foi útil pra ti? Me conta nos comentários, por aí já rolou tua primeira oportunidade no mercado? Como foi teu primeiro onboarding? Inclusive se faltou alguma dica, não deixa de compartilhar com a gente.
🧠 Exercício da Semana
Com uma vasta gama de linguagens, ferramentas e práticas a serem dominadas, é legal saber por onde começar. Uma dica para te preparar para as exigências de um ambiente de trabalho é a interação direta com projetos reais. Por isso, se tu ainda não teve tua primeira experiência prática, sugiro que inicie explorando um repositório no GitHub. Este passo não apenas aprofunda teu entendimento teórico, mas também te dá uma visão concreta de como as soluções são implementadas no mundo real. Vamos lá?
Escolha um Projeto: Selecione um projeto alinhado com as tecnologias ou as áreas que tu espera trabalhar. Isso pode incluir linguagens de programação, frameworks ou tipos de aplicativos específicos. Opte por um projeto ativo, com commits recentes e uma comunidade ativa.
Exploração Inicial: Comece lendo toda a documentação disponível, incluindo README, wiki e quaisquer guias ou tutoriais. Isso lhe dará uma visão geral rápida do propósito e da funcionalidade do projeto. Examine as issues abertas e fechadas, bem como os pull requests para te ajudar a entender os tipos de problemas que o projeto enfrenta e como a comunidade contribui para resolvê-los.
Análise Profunda do Código: Familiarize-se com a estrutura de diretórios e arquivos. Tente entender a organização lógica do projeto. Dedique tempo para ler o código fonte. Procure entender as funções principais e como os diferentes componentes interagem entre si.
Ambiente de Desenvolvimento: Configure o ambiente de desenvolvimento conforme as instruções do projeto. Isso pode incluir a instalação de dependências, configuração de bancos de dados e outras ferramentas necessárias. Tente rodar o projeto localmente.
Contribuição: Começar a contribuir para um projeto não precisa ser uma tarefa monumental. Recomendo iniciar com contribuições menores, que podem incluir correções de bugs simples ou melhorias na documentação. Essas pequenas ações são excelentes maneiras de se familiarizar com o processo de contribuição e interagir com a comunidade do projeto. Se tu ainda não te sente confiante com suas habilidades técnicas, considere fazer experimentações locais primeiro. Por exemplo, tu podes tentar reescrever uma função existente de uma maneira que tu consideres mais eficiente ou clara, ou até mesmo adicionar novas funcionalidades que tu achas que seriam úteis. Mesmo que tu decida não enviar essas alterações para o projeto original, este exercício pode ser valioso para desenvolver tua compreensão do código.
Lembre-se, o objetivo é aprender e crescer. Com o tempo, à medida que tu ganha mais confiança e experiência, poderá começar a fazer contribuições mais significativas que podem ser compartilhadas com toda a comunidade. 🖖
💡 Indicações da semana
💼 Vagas de Trabalho: A Strider te ajuda a encontrar as melhores vagas e também oferece treinamento e benefícios para te deixar preparado para oportunidades. Tudo de graça para quem tá buscando vaga. Vai lá criar teu perfil!
🆘 SOS Rio Grande do Sul: Em meio a amigos e familiares lutando em meio a catástrofe, não consegui pensar em coisas além de me envolver com ações de suporte. Nesta simulação do The Weather Channel conseguimos visualizar as dimensões da catástrofe em unidade de medida americana. Vale lembrar que no sul tivemos lugares que alcançaram a altura de 17,3 ft a simulação mostra até 9 ft. A população precisa da tua ajuda da forma que puderes contribuir. Se tu sentes que doar "pouco" não faz diferença para a escala do problema, ou fica com pé atrás sobre doar para o PIX do governo, considere ajudar diretamente grupos de suporte menores. Colaborar com iniciativas independentes talvez te ajude a visualizar a proporção do impacto que tu podes gerar.
Forças para superarmos esse momento difícil 🖖
Nos encontramos no próximo deploy, sexta às 6:00.
Eii gostei muito das dicas. Atualmente eu estou atuando como software engineer no time de sustentação da minha empresa e lá basicamente a gente mexe com todo tipo de aplicação, desde do front, back, configuração de bancos. Uma das situações que eu tou gostando é que nada é repetitivo nesse trabalho, todo dia chega algo novo pra gente arrumar, então pode chegar uma API ou algum problema que ta rolando em algum microserviço e a gente tem que descobrir e arrumar, então assim o que me ajuda muito no dia a dia é saber debugar, acho que é uma skill que não é tão falada porém para certas situações e até pra entender alguma aplicação. No mercado de tech raramente são as vezes que a gente pega algo do 0, sempre vai ser alguma aplicação que foi desenvolvido por outros e também raras são as vezes que tem documentação. Outra coisa que eu estou fazendo também para melhorar minha produtividade e tentar entregar as coisas mais rápidos é pedir para o gemini interpretar um pedaço do código, alguma regra em especifico, não o código inteiro por questões de segurança mas ajuda bastante a entender rapidamente o problema.
Encontrei a tua newsletter ontem e estou lendo e gostando bastante, parabéns!