Dicas para um dev, ao entrar em um novo desafio
07 jan, 2023 · Leitura de 4 minA área de tecnologia nunca foi fácil, e nós desenvolvedores, quando saímos da nossa zona de conforto - se é que existe isso nesta área, rs -, para um novo ambiente, seja trocando de equipe, seja trocando de empresa... Um novo projeto de atuação e todo um ramo de negócio diferente do qual está habituado, é normal nos sentirmos "perdidos", e para complicar um pouco mais, recebermos uma chuva de informações difíceis de serem processadas, logo nos primeiros dias. Já passei bastante por isso, e identifiquei alguns pontos essenciais, que talvez possa ajudar a facilitar um pouco as coisas. Por onde começar? 1. Anote, anote e anote... Bom, lhe garanto que sabendo da enxurrada de informações que serão "jogadas" para você dev, a primeira coisa que eu recomendaria, é você estar sempre com seu papel e caneta em mãos, porque você não vai dar conta de lembrar tudo que ver e ouvir. Anote tudo que achar relevante para você, como por exemplo: o papel de cada um na nova equipe, modo de trabalho, curiosidades relacionadas ao código, sistemas que precisará de acesso e para que serve cada um... E depois? 2. Releia suas anotações Considerando que foi anotado tudo que você achou relevante, é importante que você reserve um tempinho para reler tudo que escreveu, e caso necessário, reescreva de uma forma que fica mais organizado para seu próprio entendimento. Não adianta muito, ter escrito tantas coisas importantes, se você mal se lembrar do que foi escrito, certo? 3. Hora de pensar no código? Ainda não... Antes disso, vem algo que acho fundamental para você ser mais assertivo, entender melhor tudo que está sendo construído, e conseguir absorver reuniões e conversas diárias que talvez ficariam confusas para você, mesmo após meses de trabalho. É o momento de você aprender mais do negócio no qual a empresa e equipe está envolvida. Assim como eu já fiz, percebo muitos desenvolvedores fazendo isso a cada novo ciclo que começa e também nos ciclos em andamento... Pensar somente no código e esquecer de toda a parte negocial que existe em torno do ecosistema. Este erro, te faz criar um código menos assertivo, e pode custar caro para você e para a empresa. Pensa comigo: "Como vou conseguir entregar a melhor solução através de código, se não entendo o negócio? Como vou conseguir propor uma solução, entendendo apenas superficialmente o que a empresa precisa?. Provavelmente você entregará uma solução com falhas. Vai por mim, isso fará toda a diferença. Equipe e Tecnologia 4. Conheça melhor a sua equipe É normal, entrarmos em equipes com muitas pessoas, e você ser mais próximo de 1 ou 2 colegas, principalmente em seus primeiros dias de trabalho. Mas se esforce em saber o papel de cada um da sua equipe, notar as responsabilidades e conhecimentos de cada um, e para quem você vai pedir informações quando precisar. Entenda o dia a dia de trabalho, como atuam, se há um bate papo diário ou não. Tente "sugar" toda a informação possível, sobre o negócio e sobre os sistemas da equipe, com os mais experientes... Eles provavelmente sabem o "caminho das pedras", e darão informações que você vai precisar e muito no ínicio. 5. Entenda os sistemas Somos conhecidos por um certo "vício", o vício de querer sair codando, fazer acontecer e esquecer de pensar e se planejar antes disso. Esse vício, acarreta em códigos de má qualidade, e consequentemente, você terá mais trabalho agora ou mais pra frente, porque certamente seu código será refatorado. Busque antes de tudo, entender onde está pisando, como as coisas funcionam, e se possível, peça para seu líder, um tempo para você entender melhor o sistema. Agende reuniões com os mais experientes, para explicar partes do sistema, sempre que você ficar confuso. Mostre interesse em aprender, e puxe seu time para te auxiliar neste início. Use e abuse do recurso de perguntar. 6. Padrões de projeto Todo software tem seus padrões, busque entender os padrões com o qual a equipe está desenvolvendo esse software, seus patterns, as bibliotecas e tecnologias que estão sendo utilizadas. Entenda como a equipe prefere fazer uma condicional, uma validacão. Qual a arquitetura do projeto em si, pastas e subpastas, onde costumam ficar determinadas coisas... Quando caímos de cara em um projeto que está sendo desenvolvido por outras pessoas, é normal termos um pouco de dificuldade de entender. Para piorar, quando vamos finalmente codar, a tendência é fazer da forma que mais nos agrada, mas esse ponto é necessário cuidado. Como você está entrando agora, não é muito legal, você mudar o padrão de um projeto existente logo de cara (mesmo que o padrão que você esteja aplicando, seja melhor), e acabar "bagunçando" um código no qual deveria existir um só padrão, e agora tem dois (o nativo, e o seu rs). Procure se adaptar a forma na qual seus colegas trabalham e com o tempo, você dar os seus "pitacos", levantar ideias e refatorações que você achar necessário, e assim, evitar até algum descontentamento de algum colega. Considerações finais Se você…