Gabriel / Ramos

⟨ pintor de pixel ⟩

  • Blog
  • Aquele artigo para novos desenvolvedores

Aquele artigo para novos desenvolvedores

O que meu "eu" de hoje diria para o meu "eu" quando estava começando a desenvolver

8 min. de leitura

Sempre gostei de artigos que ajudam a galera que está iniciando e, ultimamente, tenho pensado muito sobre o que eu diria pra meu "eu" do passado, quando estava começando a desenvolver. Por isso, resolvi colocar em palavras algumas ideias.

#A ferramenta que você aprendeu hoje é a ferramenta obsoleta de amanhã

Ferramentas e computador

Tudo no mundo do desenvolvimento muda muito rápido. Quantas piadas com ferramentas em javascript você já não deve ter visto por aí? Não se atenha somente às ferramentas do momento. Aprenda conceitos, orientação a objetos, programação reativa e funcional, necessidades e boas práticas da linguagem que você vai utilizar... O resto, você consegue estudar conforme necessidade.

#Mantenha sua curiosidade em dia

Curiosidade

Ser curioso é uma habilidade nata para muitos desenvolvedores pelo fato de gostarem de programar.

Escrever código que resolve problemas é muito gratificante e, muitas vezes, a vontade de aprender e se manter atualizado vem naturalmente, mas, assim como essa vontade vem, muitas vezes ela passa.

Seja por problemas pessoais, profissionais ou qualquer outro, é sempre bom ter um espaço para manter sua curiosidade em dia. Criar uma rotina de leitura de alguns artigos, de pesquisar algum assunto novo surgindo na comunidade ou algo do tipo. Mesmo que de algum assunto que, a primeira vista, possa não parecer tão aplicável em algum projeto seu, nunca se sabe quando você vai precisar solucionar algum problema novo.

Seja curioso! É uma atitude sempre bem-vinda, não só no seu cotidiano, mas dentro de uma equipe. Um desenvolvedor que gosta de estudar e de aprender coisas novas com certeza se destaca e possui uma facilidade de se adaptar a novas ferramentas e mudanças com tecnologias do mercado.

#Senioridade não define nível de conhecimento

Gandalf em frente à um notebook

Você vai esbarrar em muitas pessoas de diferentes níveis de senioridade (júnior, pleno, sênior, especialista, jedi, vingador, saiyajin) mas não se atenha a isso.

Já vi estagiário ensinando pleno, júnior dando aula pra sênior e de tudo um pouco. Sem contar a quantidade de estagiário que, em muito pouco tempo, aprendeu tanta coisa nova que se parar pra analisar conhecimento técnico, deixa muito sênior pra trás.

Empresas tendem a "encaixar" profissionais em vagas e, muitas vezes, promover profissionais apenas por tempo de carreira, por isso, experiência não é completamente relacionada com quantidade de anos na carreira.

Sempre gostei de desenvolver projetos pararelos aos meus trabalhos e isso fez com que eu aprendesse diversas coisas novas que, definitivamente, melhoraram minha forma de desenvolver.

Uma pessoa que desenvolve há muito tempo não é, necessariamente, um bom desenvolvedor. Assim como, um desenvolvedor que tem pouco tempo na área não é, necessariamente, um desenvolvedor inexperiente.

Cabe a você saber e demonstrar seu valor como profissional, afinal, o que vale mais: um desenvolvedor sênior com diversos anos de experiência que nunca se preocupou em estudar e desenvolve sem ligar para boas práticas ou um júnior que realmente se preocupa com o código que coloca em produção e em seu tempo livre aproveita para melhorar suas habilidades técnicas?

#Mesmo assim você vai ser julgado pelo seu tempo de experiência

Bebê com um livro de HTML

Não tem jeito. Mesmo a quantidade de anos na área não significando qualidade do profissional, ainda existem muitas empresas no mercado (mas não todas) que ligam pra isso, é normal. Isso não quer dizer que esses paradigmas não possam mudar no futuro e cabe a nós, desenvolvedores, adaptarmos essa cultura e, aos poucos, mudar esse pensamento.

Já perdi a conta de quantas vagas me candidatei, possuindo todos os requisitos técnicos necessários, mas que não levaram minha candidatura adiante porque "não tinha o tempo de experiência necessário".

É a vida, rs.

#Aproveite seu tempo ocioso

Pessoas jogando video-game

Você sempre vai ter algum tempo ocioso. Seja no seu trabalho, no percurso até sua casa ou até sua faculdade... E por quê não aproveitar esse tempo pra ler algum artigo, se inteirar na comunidade, ouvir algum podcast ou até mesmo estudar algo fora da área técnica?

Inclusive coisas não técnicas, que fazem parte da sua vida pessoal e são apenas lazeres.

Aproveite seu tempo ocioso.

#Não deixe sua vida social de lado

Pessoa irritada mordendo telefone

É muito comum ver muitos desenvolvedores deixando de fazer coisas que gostam pela correria do dia-a-dia, quantidade de trabalho ou até mesmo por causa dos projetos paralelos (freelas ou não).

Não deixe seus hobbies e seu lazer de lado. Eu mesmo adoro música (estudar, tocar, ouvir) e tirar algumas fotos. E são assuntos que, sempre que me sobram um tempo extra, gosto de dar estudar.

Pode parecer meio besta mas, acredite, faz bastante falta no cotidiano e, depois de trabalhar um tempo 24x7, você vai ver como seus minutos livres são valiosos.

Aprender a "desligar a chavinha" quando você termina de trabalhar é uma tarefa difícil (acredite) e bem importante pra todo mundo. :)

#Formação não é tudo

Pessoas com chapéu de graduação

Durante meu ensino médio/técnico, éramos muito acostumados a pensar que nosso sucesso profissional estava completamente ligado a uma faculdade renomada, e não é bem assim.

Dentro de QUALQUER profissão a dinâmica é praticamente a mesma: pessoas são contratadas pra resolver problemas. Um médico resolve problemas de saúde. Um advogado resolve problemas legais. Um publicitário resolve problemas com marcas. Um desenvolver resolve um problema com programas.

A questão é que, diferente de outras áreas, você é capaz de aprender a desenvolver sozinho, o que não é possível dentro da grande maioria das outras profissões. Claro que isso também gera alguns problemas, afinal, você também vai ter que aprender a filtrar toda informação disponível na internet para não apenas aprender a desenvolver, mas aprender a desenvolver com qualidade, organização e de forma que você possa facilitar não só a sua vida, mas como a de outros desenvolvedores que podem tocar em seu código.

Pessoa dormindo em cima dos livros

#Isso não quer dizer que você não deve ligar para sua formação

Fazendo uma busca em sites de vagas (como apinfo, trampos, lovemondays, e até mesmo o linkedin) você vai ver que muitas vagas não barram candidatos por nivel de formação, mas não todas.

Ter um superior ou uma pós não define seu sucesso profissional, mas não quer dizer que não seja importante. Algumas qualificações são necessárias na hora de tentar se aplicar a algumas vagas. Principalmente se você pretende deixar de desenvolver e ir para uma área de gestão futuramente.

#Aprenda sobre padronização

Linha de produção de carros

Não importa a área de desenvolvimento, padrões sempre são bem vindos.

Definir e entender padrões faz com que, independente da quantidade de desenvolvedores em um time, o código gerado por toda a equipe siga uma linha de raciocínio e de escrita, facilitando enormemente a manutenção e agilize o processo de integração de um novo membro em sua equipe.

No mercado existem diversos linters de código, que auxiliam na função de padronizar código. Você provavelmente encontrará um linter para qualquer linguagem existente.

No front-end, podemos citar alguns como o eslint para javascript e o stylelint para css.

#O "princípio da responsabilidade única"

Independente da linguagem que você vai utilizar, pensar em responsabilidade única também é muito importante.

Basicamente o "princípio da responsabilidade única" define que um trecho de código deve fazer apenas uma única tarefa, de forma singular e bem feita.

Procurando sobre tutoriais e aprendendo novas coisas na internet (e no mercado) você vai se deparar diversas vezes com códigos como esse:

function somaDobro(a, b) {
  var aDobro = a + a;
  var bDobro = b + b;

  return aDobro + bDobro;
}

var somadeQuadrados = somaDobro(5, 10);

Ok, é uma função simples, que basicamente recebe dois números e soma o quadrado deles. Mas vamos analisar: não poderíamos dividir ela em mais de uma funcionalidade, para facilitar nosso desenvolvimento e futuras manutenções?

Se olharmos a fundo, temos duas funcionalidades em apenas uma função: A funcionalidade de soma e a de de dobrar um número.

Seria muito mais fácil de desenvolver e dar manutenção futuramente, se escrevêssemos um código assim:

function dobraNumero(numero) {
  return numero + numero;
}

function somaNumero(a, b) {
  return a + b;
}

var primeiroQuadrado = dobraNumero(5);
var segundoQuadrado = dobraNumero(10);

var somadeQuadrados = somaNumero(primeiroQuadrado, segundoQuadrado);

Ou até mesmo mudando a chamada das funções para algo como:

var somadeQuadrados = somaNumero(dobraNumero(5), dobraNumero(10));

Dessa forma, isolamos a responsabilidade de dobrar um número em uma função específica, e a de somar dois números em outra função específica.

Caso, futuramente, precisássemos inserir uma funcionalidade de triplicar um número, ou realizar algum outro cálculo, simplesmente escreveríamos uma outra função, sem que o código da função dobraNumero ou somaNumero fosse alterado.

Pode parecer que, ao fim do processo, a gente basicamente tenha "escrito mais código" por separar cada responsabilidade em uma função. Mas lembre-se que estamos lidando com um exemplo prático. Se pegarmos alguns projetos reais com centenas e milhares de linhas, com certeza você se sentiria muito mais confortável em mexer em um código organizado por responsabilidades.

#Ah! E também estude sobre testes

Saber testar seu código é bem importante e não somente testes pontuais. Desenvolver utilizando testes diferencia um profissional no mercado e também facilita demais na hora de corrigir algum bug em produção.

Existem alguns tópicos de destes (unitário, integração, UI/end-2-end) e também tem bastante coisa na internet sobre isso.

Recentemente li dois artigos bem interessantes, um sobre o ecossistema de testes em javascript e outro que detalhava o processo de testar aplicações front-end.

#Por fim: faça o que você realmente se sente confortável

Pessoa triste se autopromovendo

Se você quer estudar: estude. Se você quer dedicar mais tempo aos seus lazeres: dedique. Se você quer escrever um artigo em um blog de vez em quando: escreva.

Faça o que te fizer bem, como pessoa e como profissional. Defina suas metas, objetivos e tente alcançá-los.

Se autopromover apenas para passar uma imagem de pessoa engajada na comunidade ou tentar se promover utilizando o suor de outros desenvolvedores é uma coisa bem chata e, no fim das contas, pega mal pra sua imagem. Além de que você pode acabar tendo problemas em alguns relacionamentos (profissionais e amistosos) ao longo de sua carreira.

Não faça as coisas apenas esperando curtidas e sucesso, faça por que você quer, pode, e se deseja, de fato, ajudar alguém.

Algumas pessoas vão gostar do seu jeito, outras vão detestar, é assim que as coisas funcionam. Faça o que te faz bem.


Compartilhe