Estamos todos os dias buscando alguma forma de nos tornarmos melhores como desenvolvedores, entregar mais resultados para nossos clientes e consequentemente melhorar nossa situação financeira e sucesso em nossa carreira.

Seguem algumas características e regras de ouro que fazem com que um desenvolvedor suba de nível com uma velocidade muito maior do que seus pares que não as seguem.

Antes de tudo: Não existe concorrência

Analise o quanto a nossa área está crescendo e o quanto o mercado está aquecido. Porém, entenda que muitos desenvolvedores tendem a ser preguiçosos e olham apenas para o seu próprio umbigo.

Escrever código é a parte mais fácil do desafio. Entender o que deve ser feito e fazer da melhor maneira possível, com qualidade, entrega de valor contínua e ajudando a empresa a subir de nível tecnicamente faz com que poucos desenvolvedores realmente evoluam em sua carreira.

Para conseguir isso, você deve estar sempre buscando entregar valor a todos a sua volta, de forma consistente e mais rápida possível.

As regras de ouro abaixo farão com que você consiga se destacar muito mais e fazer com que você alcance o próximo nível como desenvolvedor.

Reduza ao máximo a complexidade 

Em uma entrevista, Elon Musk (dono da Tesla e da SpaceX) explica que o maior erro de um engenheiro é gastar tempo otimizando algo que não deveria existir.

Muito provavelmente, em algum momento da sua carreira você vai querer montar um super framework que vai cobrir todas as possibilidades para ajudar na criação e resolução de um determinado problema.

Apesar de ser algo bacana de ser feito, e parecer um lego onde todas as peças se encaixam, muito provavelmente você estará generalizando demais o problema e tentando criar soluções para situações que nunca vão acontecer.

Este processo cria uma complexidade enorme e faz com que você perca o foco no que realmente importa. 

Sendo assim, vamos para a nossa primeira regra de ouro:

Regra de ouro 1: Reduza a complexidade ao máximo, não reinvente a roda e esteja sempre focado na entrega de valor contínua para os seus clientes. Somente desta forma os objetivos vão ser alcançados sem dores de cabeça de longo prazo.

Eficácia vem antes de eficiência

Se existe algo que a metodologia ágil foca muito é na eficácia, é entregar o máximo de valor aos nossos clientes de forma iterativa e sempre validando se o problema está sendo efetivamente atacado.

Eficácia: Fazer a coisa certa (maior valor ao cliente)

Eficiência: Fazer do jeito certo (menor custo, tempo)

Nosso cérebro como desenvolvedor está treinado para sempre buscar a maior eficiência em tudo, deixar o mais otimizado, genérico, bonitinho e com a última tecnologia disponível. 

Mas muitas vezes nos esquecemos que o que o cliente quer é apenas que o relatório saia da forma que ele deseja no menor tempo possível, ele não se importa como isso foi feito.

Isso não significa que não devemos sempre buscar sermos eficientes, mas antes de tudo é importante buscar entender o que o cliente deseja e validar se a expectativa realmente bate com o que você está entregando.

Regra de ouro 2: Aprenda a entender o que seu cliente realmente quer antes de sair codificando. Mas não esqueça que aprender a usar bem suas ferramentas, se tornando mais eficiente é obrigação de qualquer desenvolvedor.

Esteja realmente presente nas cerimônias

Por exemplo, em reuniões em pé diárias: Todo o time se reúne e informa a todos os interessados como foi o dia anterior e o que pretende resolver no dia de hoje. Se houver algum impedimento ou dificuldade, ele irá sinalizar e combinar com outros para eliminar o problema o quanto antes.

O que dificulta é que os devs só se preocupam com o que vão falar, não prestam atenção ao que os outros dizem e ainda quando falam não passam contexto nem nada. 

Em suma, é criado um ambiente em que boa parte das pessoas estão apenas "fazendo o que mandaram" e não estão realmente entregando valor ao time ou extraindo informações valiosas que podem ajudar a resolver problemas futuros.

Reuniões de grooming, planejamento e retrospectiva: Todos os envolvidos no projeto se reúnem para falar como foi a última iteração, ver o que deu certo e o que não deu, para fazer o planejamento da próxima semana.

Nestas reuniões, tem grandes chances de termos pessoas de fora do time normal de desenvolvimento. Ex.: Cliente, gerentes, diretores etc.

Neste caso, o dev fica mudo, fala o mínimo possível com medo de se expor e contribui muito pouco ou nada para a resolução dos problemas.

Outro fator é quando, na reunião de retrospectiva, o dev traz apenas problemas sem uma proposta de solução para eles e bons argumentos do motivo de serem importantes, além de muitas vezes ficar ofendido quando não é ouvido.

Regra de ouro 3: Vá nestas reuniões com o máximo de preparação possível, preste atenção ao que vem acontecendo dentro do time de modo que você se torne mais atento e veja sinais que indicam pontos de melhoria e dificuldades. Estes sinais são as oportunidades que você pode usar para deixar sua marca. Seja construtivo nas suas críticas e esteja preparado para ser ignorado ou voltar atrás quando provado que elas não são reais. Aprenda com o feedback, sempre.

Não negocie qualidade

Imagine que você esteja com uma dor e descobre que deve ser feita uma cirurgia. Quando você questiona quanto irá custar e quanto tempo de recuperação, o médico dá a seguinte resposta:

Depende, se eu tiver que esterilizar os equipamentos deverá sair mais caro, pois eu gasto mais material e tempo. Com relação ao tempo de recuperação, talvez leve cerca de 1 mês se não houver nenhuma infecção com os equipamentos não esterilizados.

Isso é sinal de pouco profissionalismo e, sendo o cliente, deveria ter medo do que vem a seguir. Bons desenvolvedores e grandes empresas de software recebem a responsabilidade de criar sistemas críticos que podem trazer efeitos negativos se não houver um cuidado e qualidade no que é feito.

Então, porque é que você ainda faz um código com baixa qualidade? Um código sem bons Unit Tests e sempre que alguém que pergunta se ele está pronto diz:

Tá pronto, só falta testar.

Isso não faz nenhum sentido e só mostra a incapacidade de entender a importância do que está sendo feito, ou estará condenado a fazer só sistemas que nem deveriam existir, pois se houver alguma falha ninguém será impactado negativamente.

Regra de ouro 4: Nunca, nunca e nunca deixe a qualidade do seu código em segundo plano. Crie sempre bons Unit Tests, corrija os bugs com algo automatizado que garanta que ele está resolvido e sempre crie novos códigos com o melhor padrão possível.

Esteja sempre programando

Uma excelente forma de aprender a andar de bicicleta é ir praticando, as vezes até colocando umas rodinhas e tentando andar sem precisar delas ao longo do tempo. Quando você tem um pouco mais de coragem, fique sem as rodinhas e saia andando por ai. Cair algumas vezes é inevitável, mas é o risco que se corre em aprender.

Agora, imagine se no processo de aprender a andar de bicicleta, você compre um livro que ensina o processo, veja uns vídeos no YouTube sobre isso, mas não gasta tempo suficiente na prática de andar de bicicleta sem rodinhas.

Qual seria o resultado? Não existe nenhuma possibilidade de você ser bom em andar de bicicleta e nem de participar de campeonatos e ser um ciclista de sucesso.

Então por que você resolve fazer isso com programação? Porque compra livros e mais livros de aprenda a programar em 21 dias e nunca gasta tempo suficiente para programar?

Busque sempre fazer algo diariamente, quer aprender algoritmos? Resolva, mesmo que no início seja muito difícil, ao menos um algoritmo por dia. (LeetCode, AlgoMania etc).

Quer aprender frontend? Busque criar clones de sites bacanas e entender alguma técnica diferente, todos os dias... Sempre.

A melhor forma de aprender a programar é sempre programando, não existe atalho para isso.

Regra de ouro 5: Uma tendência humana é subestimar o que pode ser feito em um ano e superestimar o que pode ser feito dentro de um mês. Se todos os dias você dedicar uma hora para aprender determinada área (algoritmos, bancos de dados, frontend, backend etc) quantas horas você terá no final do ano? Esteja sempre praticando, é a prática que fará com que você se diferencie no mercado e aprenda os padrões em todas as áreas que trabalhar.

Saia da trincheira (busque sempre ajudar o seu time e aprenda a visualizar o todo)

É comum todos os desenvolvedores simplesmente colocarem o fone de ouvido, programar o dia inteiro e achar que este é o caminho para se destacar.

A verdade é que programar é apenas um meio para entregar valor aos seus clientes, identifique pontos de dor dentro do time e traga propostas do que pode ser melhorado, converse com pessoas de outros times e entenda mais o todo.

Tem um artigo muito bom chamado "Simple Ways to Make an Impact" que enumera alguns pontos que você pode estar atendo pra se destacar e melhorar seu time:

  • Pontos de dor
  • Frustrações
  • Ineficiências
  • Lacunas de conhecimentos ou de processos
  • Barreiras de comunicação ou falhas na comunicação
  • Falta de direcionamento para cumprir determinada tarefa
  • Falta de transferência de conhecimentoNo artigo o a pergunta "como eu posso tornar isso mais fácil" sempre pode ser usado para identificar pontos de melhoria na equipe e entrega de mais valor ao cliente, de modo que todos os processos, documentação e etapas no desenvolvimento tinham pontos que não necessariamente estavam relacionadas a código.
  • Regra de ouro 6: Esteja com o radar ligado e sempre busque formas de melhorar a eficiência do seu time e não apenas a sua. Esta é a melhor forma de se destacar, ensinar e aprender ao longo da sua carreira. Faça a pergunta "como posso simplificar isso, sempre que possível".