⚠️🚨 SPOILER: não, você provavelmente não se tornará sênior em 2 anos. Além do mais, "júnior", “pleno" e “sênior” são apenas labels que as empresas utilizam para contratar as pessoas certas para as vagas disponíveis, de acordo com a complexidade e o nível de conhecimento exigidos pelo trabalho a ser realizado, e claro, o salário a ser pago. Porém, há uma longa estrada de estudos pela frente. A evolução do seu nível é apenas uma consequência do seu progresso contínuo. Dito isso, darei umas dicas pra você, que está em busca da primeira oportunidade ou que, assim como eu, está no início da carreira, de como acelerar seu desenvolvimento profissional:

🧠 A tecnologia é apenas um meio, e não o fim

Um erro que alguns iniciantes cometem é focar muito na tecnologia que está utilizando, seja uma linguagem ou um framework, e se esquecer qual é o objetivo de um programador: resolver problemas. O código que escrevemos é apenas o meio pelo qual nós conversamos com o computador, abstraindo um problema do mundo real em uma solução de software que atenda a esse problema — e esse processo de abstração exige foco e um pensamento voltado às necessidades do usuário desse software. De nada adianta criar um sistema com o framework do “hype", com um código perfeito ou utilizando mais de 8 mil design patterns¹, ou com alta performance e escalabilidade se ele não soluciona o problema para o qual foi criado.

🎯 Não pule etapas, e aprenda conceitos, não frameworks

Outro erro comum que iniciantes em programação cometem é tentar pular etapas no aprendizado. Tentar aprender um framework JavaScript (React.js, por exemplo) antes de estudar a base da linguagem, ou querer avançar no aprendizado de uma linguagem sem antes consolidar bem a lógica de programação não é nem um pouco efetivo. Tenha calma e curta o processo. Após aprender bem lógica, será mais fácil aprender uma linguagem. Após aprender uma linguagem, será mais fácil aprender um framework dessa linguagem para facilitar a sua vida. Temos muitas tecnologias para escolher, o importante é não pular etapas, pois os conceitos-chave são comuns a todas elas. Quanto mais se aprende, mais fácil se torna o processo constante de aprender novas tecnologias e se aprofundar em alguma delas.²

🤝 Faça parte da comunidade

Uma das maravilhas da nossa área é a quantidade de material gratuito disponível na internet, possibilitando que mais pessoas tenham acesso às grandes oportunidades que o mundo da tecnologia oferece sem a necessidade de formação acadêmica. Também é fato que, juntos, crescemos mais rápido, e participar da comunidade dev pode te ajudar a conquistar a primeira oportunidade e a progredir ainda mais. Seja ativo, poste nas redes sociais o que você está estudando, participe de discussões, responda dúvidas no StackOverflow³, mantenha uma rede de contato com seus colegas de curso/faculdade, publique conteúdos sem cobrar nada em troca para trazer mais pessoas ao ecossistema de programadores brasileiros. Difunda conhecimento.

🧹 Deixe os códigos mais limpos que quando você os encontrou

Conquistou o seu primeiro emprego como dev? Além dos usuários do software que você mantém, você tem que se preocupar com outro tipo de “usuário”: seus colegas de trabalho. Um código mal escrito pode dificultar o trabalho de outros devs, e até o seu próprio futuramente, fazendo com que a adição de novas features ou a resolução de bugs fique mais demorada devido à má legibilidade ou à baixa coesão do que foi implementado anteriormente. Portanto, ao escrever seu código é super importante levar em conta os conceitos de Clean Code, DRY⁴ (Don’t Repeat Yourself), KISS (Keep It Simple, Stupid), YAGNI (You aren’t gonna need it) e princípios SOLID (5), para que você desenvolva um produto realmente "soft”, que seja fácil de realizar alterações — pois se um software não muda, então significa que ninguém o utiliza.

😱 Não tenha medo de código

Uma boa mentalidade para se ter é a de programador comunista. Não estou falando de programação funcional(6), mas sim do fato de que você é responsável pela qualidade de todo código ao qual você tem acesso. Claro que não podemos levar isso ao pé da letra, pois imagine a quantidade de código desenvolvido com GoHorse(7) existente no open-source… mas uma boa dica é fazer code review das merge requests/pull requests dos seus colegas de equipe, prezando pela qualidade não só do código que você escreve, mas do código que você potencialmente utilizará no futuro. A cultura de code-review é um fator importantíssimo para que o nível técnico do software se mantenha elevado e seus mantenedores evoluam suas habilidades. Além disso, contribuir com repositórios de código aberto que você ache interessante é uma ótima forma de ganhar notabilidade e engajar em discussões enriquecedoras. Software se constrói em equipe.

💣 Miscelânea do caos

Existem certas habilidades que separam um sênior de um júnior. Algumas são: a habilidade de dizer “depende”, o conhecimento da própria falta de conhecimento(8) e a capacidade de pesquisar por soluções na internet de forma inteligente. Elas se aprimoram com o tempo, conforme nós sofremos com as dores que vão surgindo— o caminho para aprender a desenvolver software de forma profissional é longo, e sempre teremos bugs no nosso caminho; porém, cada bug gera um novo aprendizado, e os desafios, 8)cada vez mais complexos, nos fazem crescer. A persistência é o segredo do sucesso.

Conclusão

Espero que essas dicas tenham te ajudado a entender como é o trabalho de um desenvolvedor de software e a pensar em maneiras de acelerar seu crescimento profissional. Alguma dica ficou faltando? Discordou de algo? Deixe nos comentários, vamos debater! Até a próxima =P

¹ É comum alguns exagerarem no uso de design patterns. Esses patterns — não defaults ou standards — são soluções gerais para problemas que ocorrem com frequência em certos contextos em um projeto de software. Eles foram criados por programadores antes de nós, que enfrentaram estes problemas e chegaram a estas soluções. Se você utiliza um design pattern para resolver um problema que você não tem, você está utilizando-o apenas por utilizar, sem um objetivo, e isso é fazer over-engineering.

² Você pode ser um desenvolvedor Full-Stack, Back-End ou Front-End, e se aprofundar em alguma(s) tecnologia(s) específica(s), porém é importante ter uma noção do todo, construíndo uma carreira em T. Dando meu exemplo: sou um Full-Stack, focado em desenvolvimento back-end com .NET, mas tenho conhecimentos de front-end, de fundamentos de dev-ops e qualidade de software, entre outros essenciais para qualquer programador saber (ao menos o básico, para conseguir se virar no dia-a-dia e ser mais independente, sendo capaz de fazer entregas de ponta-a-ponta, da análise de requisitos ao deploy em produção). São tantos termos utilizados que podemos nos confundir, mas em geral, um dito “Full-Stack” ou “Full-Cycle” acaba desempenhando um papel T-shaped.

³ Reza a lenda que quando o StackOverflow está fora do ar, nenhum programador trabalha.

⁴ O DRY deve ser utilizado com moderação. Abstrações precoces para evitar repetições no código podem torná-lo mais difícil de modificar. É seu papel como desenvolvedor pensar, em cada caso, se uma abstração é necessária e qual a melhor forma de criá-la, considerando o princípio KISS.

5 Os princípios SOLID são controversos: alguns dizem que seu uso é essencial em qualquer software orientado a objetos; na realidade, depende bastante da complexidade do negócio. Sistemas CRUD muito simples, por exemplo, dificilmente precisariam usar algum desses cinco princípios — quando muito, o SRP (Single-Responsability Principle) e o OCP (Open-Closed Principle) seriam o suficiente; é bom ter cuidado com o over-engineering. Além disso, são princípios que devemos utilizar da forma que for mais inteligente em cada contexto — o uso de um não implica no uso dos outros quatro.

6 Programação funcional é o paradigma de programação comunista: ele prega a não existência de estado e de classes, e as funções — a “classe” trabalhadora — são de primeira ordem. 🤪

7 https://gohorseprocess.com.br/extreme-go-horse-xgh/amp/

8 Como dizia Sócrates, "Só sei que nada sei".