Porque o seu primeiro emprego será o mais difícil

Existem muitas mudanças na transição de um ambiente acadêmico para o profissional. Mudam a maneira de se portar, a maneira que você gerencia seu tempo e lida com prazos, a maneira que você se relaciona com as pessoas. E se você também pensava que para estar numa empresa que desenvolve softwares basta apenas saber programar, todas essas mudanças podem ser assustadoras e vir a te sobrecarregar.

Se eu conseguisse reunir todas as esferas do dragão, meu desejo seria voltar no tempo e passar todo o conhecimento, percepções e hábitos que adquiri até hoje como desenvolvedor para o “eu” mais jovem e assim possivelmente evitar alguns momentos de estresse. Como isso ainda não é possível, ofereço um pouco do que aprendi para pessoas que, assim como eu, começaram a carreira de desenvolvedor recentemente e são junior devs.

Durante esse tempo, contraí alguns hábitos através de bastante observação, e que na minha opinião todo junior dev deveria ter pelo menos alguns deles. A versão resumida é:

• Sempre faça perguntas. Pergunte até entender!
• Revise seu próprio código
• Jogue junto com seu time!
• Não implemente a primeira solução que vier na sua cabeça
• Revise o código de outras pessoas mesmo sem elas pedirem
• Não questione o que pessoas com mais experiência falam
• Sempre questione o que pessoas com mais experiência falam
• Encontre um balanço entre sua vida profissional e pessoal
• Tenha orgulho do ser junior dev e aproveite a jornada de aprendizado

Sempre faça perguntas. Pergunte até entender!

No medo de fazermos perguntas bobas ou de parecermos estúpidos ou com pouco conhecimento, acabamos não perguntando. A verdade é que é bastante desconcertante fingir que entendeu, gastar horas executando uma solução e no final perceber que está tudo errado. Ser honesto sobre sua falta de entendimento dá chance para as pessoas lhe ajudarem, em vez de elas terem que consertar algo de errado que você fez. Portanto, sempre pergunte! Nunca guarde uma pergunta pra você.

Revise seu próprio código

Como juniors temos uma ansiedade gritante para resolver problemas, uma vontade enorme de mostrar serviço e resolver tudo num dia só. Mas tenha calma! Dê um passo para trás, verifique o que você fez e veja se aquilo faz sentido. Seu código traduz suas intenções? Sua solução está de acordo com os padrões do projeto? Ela está ferindo boas práticas arquiteturais? Se sim, há uma boa razão pra isso? Há mensagens de debug esquecidas no código? Responder essas perguntas podem fazer com que você note alguns erros que passariam despercebidos, facilitando assim o trabalho de quem irá revisar seu código. Não há nada mais irritante para um revisor do que pegar erros pequenos.

Jogue junto com seu time!

Um time de desenvolvimento é mais efetivo quando os valores do grupo superam o do indivíduo. Todo mundo tem suas preferências na maneira de trabalhar e no jeito que escreve código. Porém, colocar essas preferências acima das necessidades do time é algo bastante egoísta porque é natural que nem todo mundo se adeque ao que você acha bom. Trabalhando de maneira cooperativa, seus colegas sentirão mais confiança de que você está ali pra ajudá-los. Pra isso, procure ser regular em alguns horários determinados do expediente (dessa maneira sua disponibilidade se torna previsível) e procure saber as virtudes e fraquezas de cada membro do seu time (de forma que você possa suprir as lacunas dos demais quando necessário). Outro hábito muito importante (e às vezes pouco valorizado) é o Pair Programming. "Parear" traz bastantes benefícios dentro de um time, como a possibilidade de ter um code review imediato e uma maior distribuição do conhecimento, sejam regras de negócio, arquitetura do projeto, code style, entre outros. Eu sei que as vezes você pode achar que não conseguirá explicar sua idéia de maneira clara, que não vai entender o que o colega vai falar ou mesmo você se sente mais produtivo codando sozinho, tornando o pair programming algo penoso. Mas o conceito crítico aqui é que o time deve estar em constante estado de colaboração de uma maneira ou de outra, ou seja, quanto mais eventos desse tipo houver, melhor será a troca de conhecimentos.

Não implemente a primeira solução que vier na sua cabeça

Um dos meus principais erros nos meus primeiros dias era correr pra implementar a primeira solução que eu pensava. De maneira errônea, achava que tinha entendido muito bem o problema em sua completude e, nos primeiros minutos, já começava a escrever algumas linhas de código. Além disso, meu código era cheio de oneliners obscuros e features da linguagem, que serviam apenas para dizer: “Olhem como eu manjo dessa linguagem!”, e não contribuíam em nada para dar clareza à intenção do meu código. Como já li em alguns lugares, escrever código é, para além de dar instruções a um computador, sobre se comunicar com outros seres humanos. Deixe que o compilador cuide da tradução do seu código para a linguagem de máquina! Para outros seres humanos, o seu código tem que mostrar claramente o que, o quem, o quando, o como e a razão daquela tarefa estar sendo executada. Portanto, quando for implementar uma solução, avalie o que já existe na sua base de código, seja claro nas suas intenções, pense em outras alternativas e suas vantagens ou desvantagens, consulte um colega sobre sua ideia e pergunte se ele por acaso tem outro ponto de vista acerca do problema.

Revise o código de outras pessoas mesmo sem ser requisitado

Aproveitar a oportunidade de ver como outros integrantes da sua equipe imaginam e implementam suas soluções com certeza te trará uma intimidade maior com a base de código e com as práticas utilizadas no projeto, facilitando a execução do seu trabalho, reduzindo o tempo gasto com retrabalho e te fará depender menos dos colegas pra saber o que algum trecho de código faz. Além disso, este processo servirá pra você ficar atualizado de tudo o que está acontecendo no projeto. Porém, não vá perder noites de sono fazendo isso! Faça apenas de maneira esporádica, de forma que não atrapalhe a entrega das suas atividades e dê prioridade a revisões que contenham algo de especial, como uma nova funcionalidade ou um refactor interessante. Para junior devs, essa é a melhor maneira de aprender práticas comuns e novas técnicas.

Não questione o que pessoas com mais experiência falam

As pessoas que estão a um cargo acima de você estão ali por algum motivo (no shit, Sherlock!). Não é uma questão do nome que os seus cargos levam, mas as pessoas que ocupam estas posições devem ter mais experiência na área ou, no mínimo, dentro da empresa. Portanto, se houve um problema e uma reunião para discuti-lo, na qual todo mundo teve a oportunidade de fazer suas ponderações e devs plenos e sênior recomendaram uma certa solução, provavelmente esse será o melhor caminho a ser seguido. Essas pessoas tendem a ter mais clareza sobre a visão geral do projeto e talvez já tenham vivenciado situações muito semelhantes e já conhecem seus detalhes e suas pegadinhas.

Sempre questione o que pessoas com mais experiência falam

No parágrafo anterior eu não quis dizer que era pra você seguir cegamente o que os outros falam. E esse parágrafo não deve ser visto como um contraponto ao tópico anterior mas sim como uma adição a ele. Reavaliar como as coisas foram feitas é um hábito saudável e pode trazer benefícios para uma equipe com muitas pessoas experientes que provavelmente adquiriam certos vícios ao longo do tempo. Agora… se você está num local em que as pessoas não estão abertas a rever seu próprio trabalho, talvez isso possa ser um sinal que você deve procurar por mudanças.

Encontre um balanço entre sua vida profissional e pessoal

Apesar de você estar no início da sua carreira e querer demonstrar utilidade e serviço, encontrar um balanço entre sua vida pessoal e profissional é muito importante. Quando me sinto frustrado ou cansado de escrever código, vou pro meu piano e tento tocar alguma coisa leve ou treinar com algum exercício. Em geral, me sinto com muito mais vontade de voltar ao trabalho após descansar a mente.

Tenha orgulho de ser um desenvolvedor junior e aproveite a jornada de aprendizado

Muito de nós que estamos iniciando nossa jornada no mundo profissional temos medo de sermos julgados e acabamos não aproveitando o momento como deveríamos. Esquecemos que uma das maiores e melhores vantagens de ser um junior é que as pessoas não tem muita expectativas sobre nós. Muitas pessoas relatam que quando estão em cargos mais altos, a pressão sobre elas é muito maior e elas acabam não podendo cometer muitos erros ou fazer "perguntas bobas". Perca um pouco da sua ânsia de querer subir de cargo rapidamente, aproveite para aprender e solidificar seus conhecimentos, aproveite para trabalhar lado a lado e perceber como pessoas mais experientes atingem seus objetivos.

Se você chegou até aqui, muito obrigado pela leitura. Espero que você tenha aprendido algo! Sinta-se a vontade para comentar ou até mesmo contar um pouco da sua experiência!