Ser iniciante na carreira em programação não é fácil, são muitos questionamentos, receios e incertezas que podem permear a cabeça, mas uma máxima é certa: todo mundo erra.

Nem a pessoa no cargo de CEO de uma empresa está imune ao erro, e o diferencial está na forma com que você lida com ele, se com medo (tentando ao máximo evitá-lo) ou aceitando a existência da possibilidade de erro, se munindo de ferramentas que ajudem a consertá-lo, quando acontecer.

E se errar é humano, ninguém está sozinho neste barco, então, desistir não é uma opção! No fundo, o erro sempre irá ensinar, você só precisa estar aberto(a) a perceber o que precisa ser desenvolvido, seja uma skill técnica ou comportamental.

Neste texto, trouxemos 7 erros "clássicos" de desenvolvedores no início da carreira, e vamos lhe dar dicas de como lidar da melhor forma com eles, para que a insatisfação de cometê-los se transforme em alavanca de crescimento!

Este texto foi baseado em um epsódio do nosso podcast "Debug is on the table", em que nosso CEO e Founder José Messias Júnior entrevistou Rafael Almeida, desenvolvedor pleno na Méliuz, e ambos compartilharam suas experiências no percurso inicial de suas carreiras.

Esperamos que este texto te dê mais coragem para errar e aprender! :) Confira agora este conteúdo feito com base nas dicas de dois feras da programação!

1 - Deixar de se inscrever em processos seletivos por insegurança

O começo de uma carreira é sempre cheia de incertezas, e uma carreira em programação, por ter uma carga técnica grande, pode gerar ainda mais insegurança. Mas uma coisa é certa: este sentimento só melhora depois que a pessoa vai ganhando experiência, ou seja, a melhor forma de combater esta insegurança é começando a atuar.

E, para isso acontecer, é importante se inscrever em processos seletivos, mesmo que você não cumpra todos os requisitos que a vaga exige. Todo profissional do nível júnior entra em uma empresa para aprender, e isso não é diferente com uma pessoa dev.

Ou seja, se uma empresa está anunciando uma vaga júnior, ela tem consciência de que a pessoa candidata que for aprovada entrará para aprender. Isto é um comportamento comum no mercado.

Então, mesmo que a vaga pareça ter muitos requisitos e que a insegurança apareça, não se inscrever em processos seletivos é ainda pior para o desenvolvimento da carreira! Outro lembrete é que receber um "não" em algum processo seletivo não é de todo ruim - passada a quebra de expectativa, que é normal que ocorra, é importante receber os feedbacks e buscar melhorar para a próxima tentativa. Assim, se inscrever em processos seletivos vai sempre trazer algo de positivo, ao contrário do que o medo podefazer parecer.

E se você quiser saber como se preparar para uma entrevista de emprego em tecnologia e se destacar nela, clique no link e leia o nosso texto!

2 - Inserir bugs no meio do caminho

Nas primeiras semanas de trabalho de um programador júnior, é comum que as tarefas sejam correções de bugs, implementação de novas features, mudanças de layout e outras tasks mais iniciais, mas sempre sob a supervisão de algum(a) desenvolvedor(a) mais sênior que vai auxiliando durante o caminho.

Principalmente durante o período inicial, é normal que o dev insira bugs pelo meio do caminho, esquecendo algum "{" no meio do código ou até deixando informações aparentes que não eram para estar, mas isso ocorre até com devs em estágios mais avançados de carreira.

É possível encontrar certos bugs em sites até de empresas consolidadas no mercado, porque é normal que, mesmo com revisão, alguns erros acabem passando (todo mundo erra, lembra?). Então, é possível e até provável que devs em início de carreira também cometam esse tipo de erro.

Com o auxílio da equipe, qualquer bug será rapidamente consertado, e irá gerar um aprendizado a partir da situação. Então, não desanime!

Code-review

O Code-review é feito antes de o código ir para produção (colocar no ar) - é feito um pedido, que funciona como uma revisão, em que qualquer dev da empresa pode olhar o código e checá-lo. Se houver algum bug, o desenvolvedor sinaliza e faz comentários na linha do código, pontuando o que está errado para que o dev responsável o conserte.

Esse processo de aprovação do código pode variar entre as empresas; em algumas, basta uma pessoa revisar, em outras, é necessário que duas pessoas devs revisem. Independentemente disso, o que importa é que, mesmo que o código apresente algum erro, ele será revisado. E caso o erro passe, ninguém errou sozinho(a). 😉

3 - Ter medo do julgamento do código

Nesse processo de code-review, outras pessoas vão olhar o código, revisá-lo e corrigi-lo, e às vezes mais de um dev participa desse processo.

Neste caso, pode surgir o medo de julgamento do código como ruim ou amador, e isso pode travar a pessoa que é dev júnior na hora do desenvolvimento.

Normalmente, não ocorre esse tipo de julgamento. O que acontece é o contrário: as pessoas que estão revisando normalmente são cordiais e abertas a discutir e ensinar eventuais problemas encontrados no código. Via de regra, a comunidade de programação é muito colaborativa.

É preciso encarar a correção do código como um momento de aprendizagem em conjunto, tanto para quem tem o código revisado, quanto para quem revisa.

Para quem tem o código revisado, é uma oportunidade de crescimento na carreira, afinal, quanto mais comentários, mais dicas de como fazer melhor da próxima vez essa pessoa receberá.

E para quem revisa, é uma oportunidade de ver outras formas de fazer código, ter insights e acabar aprimorando o seu próprio tipo de código.

4 - Não perguntar

Primeiramente, não existe dúvida besta ou dúvida errada, se está com dúvida, pergunte! É muito melhor para a empresa e para o andamento do projeto.

Existe um estigma entre alguns programadores juniores de acharem que "deveriam" saber algo porque já são devs. Se o profissional é Júnior, o próprio nome já diz, está crescendo e se desenvolvendo, e eventualmente cometerá erros, afinal, se já soubesse a maior parte, seria pleno.

Cuidado com a "síndrome do impostor" que te faz questionar seus talentos, duvidar de si mesmo e acabar não executando a tarefa por achar que deveria saber algo que não sabe.

Uma dica excelente é adotar um mentor, alguém mais sênior que consiga auxiliar não só no código, mas também partilhando as dúvidas e angústias. Outra dica é olhar no Google antes de perguntar, checar se a dúvida persiste mesmo depois de ler algo sobre, e se sentir seguro o suficiente para se expor perguntando.

Mas, lembrando: não gaste muito tempo nesse processo, o melhor para o gestor e para empresa é que as dúvidas sejam tiradas assim que acontecerem, para que o prazo de entrega seja cumprido!

Neste sentido, confira o depoimento da estudante Maria Clara Negrão que mostra que as inseguranças são normais, mas ninguém está sozinho(a):

É errando que se aprende, perguntas dificilmente vão "encher a paciência" de alguém e, caso isso aconteça, a sinalização virá. Para evitar atrasos na entrega, o melhor é que se pergunte até entender, a empresa com certeza agradecerá!

5 - Entregar tudo o mais rápido possível

O famoso "júnior correria" é uma fase que quase todo dev em início de carreira passa, mas mostrar serviço e entregar tudo o mais rápido possível é visto com bons olhos até certo ponto; o problema é quando a rapidez se transforma em “afobação”.

Realizar as tarefas com pressa e deixar a qualidade da entrega de lado, por querer terminar logo, pode acabar gerando retrabalho, o que poderia ter sido evitado se a entrega tivesse sido feita com mais cautela.

No entanto, essa fase faz parte do crescimento e do desenvolvimento da carreira, afinal, é só a partir dessas situações que se percebe que, para avançar na carreira, é preciso cuidado, revisão e teste.

Zelar pela saúde e perpetuação do código demanda um pouco mais de tempo até desenvolver o código de fato, então, fazer com mais qualidade e constância é o que conta para o crescimento.

6 - Não reagir bem a feedbacks

Receber feedbacks construtivos não é fácil, independente do nível de senioridade da pessoa, principalmente quando há expectativas de alcançar algo e no momento do feedback percebe-se que aquilo que almeja está um pouco mais longe do que era esperado.

O feedback é uma ferramenta de trabalho, ele tem método e é feito de uma forma específica, planejado e executado para as pessoas crescerem. Encará-lo dessa forma, inclusive, pode ajudar a não levar as críticas para o lado pessoal, porque tudo que é dito durante estes momentos são pensamentos para o desenvolvimento pessoal e profissional de quem está recebendo.

Por isso, é importante anotar os feedbacks para analisar tudo que foi dito, pensar se faz sentido, entender quais mudanças precisam ser feitas e como implementá-las. Uma alternativa é perguntar para a própria pessoa que passou o feedback como você pode melhorar, perguntando se ela mesma não tem algum caminho que possa te ajudar.

Ter uma postura defensiva diante de um feedback (feito da forma correta, claro!) é perder a oportunidade de crescer mais rápido!

O melhor a ser feito é ouvir e, depois que o “calor da emoção” passar, analisar profundamente se o que foi dito realmente não faz sentido, ou se faz, e o orgulho "atrapalhou" a visão da situação.

Todo mundo já passou por um feedback assim, em que teve que dar um passo para trás para conseguir voar depois; a diferença está em quem ouviu e mudou, diferente de quem se defendeu e demorou mais de se desenvolver.

7 - Querer aprender todas as linguagens de programação ao mesmo tempo

É comum que devs iniciantes queiram “abraçar o mundo” quando adquirem as primeiras noções de desenvolvimento.

Contudo, é preferível que você domine uma linguagem, adquirindo maior desenvoltura na sua utilização, do que tenha um baixo nível de domínio em várias linguagens ao mesmo tempo. Inclusive, as características distintas entre as diferentes linguagens de programação podem dificultar o seu processo de aprendizado, caso você decida aprendê-las todas ao mesmo tempo!

JavaScript, por exemplo, é a linguagem mais utilizada no mundo, razão pela qual aprendê-la é um bom primeiro passo para a inserção no mercado de programação.

Se você estuda JavaScript ou já tem um conhecimento razoável ou bom da linguagem, saiba que existe uma forma de otimizar o seu tempo na identificação de erros e construir arquiteturas mais sólidas.

Tudo isso através do Typescript, um super conjunto de JavaScript criado pela Microsoft que incorpora novas funcionalidades à linguagem - e o código final será em JS.

Então, aprender Typescript é o próximo upgrade na sua carreira!
Para conhecer o nosso curso de Typescript e fazer parte da próxima turma, clique aqui: curso Typescript: a evolução do JavaScript.