Como ser uma pessoa desenvolvedora melhor?

Ser melhor desenvolvedor não é só saber tudo tecnicamente. Cada pessoa tem para si o que é ser melhor, mas para mim é um conjunto de coisas que venho pensando depois de 11 anos trabalhando na área.

“Quem se preocupa demais em ser o melhor, perde tempo não sendo melhor”. Li isso em algum lugar uma vez. Se concentrar demais em algo é prejudicial também. Quando paramos de pensar nisso excessivamente, provavelmente ficamos cada vez melhor.

Vou passar por 13 pontos que acredito serem muito importantes para ser um desenvolvedor completo.

1. Ser humilde (admitir, perguntar a opinião dos outros)

A humildade abrange muitas coisas. O mais importante na minha opinião é admitir. Admitir que não sabe algo e/ou admitir o erro. Você gera confiança entre você e seus pares sendo humilde.

2. Não demorar demais para pedir ajuda

Complementando o ponto anterior sobre humildade, não demore demais para pedir ajuda se não conseguir fazer algo. É importante bater cabeça, mas tudo tem limites. Levantar a mão e pedir ajuda é bom pois às vezes outros podem pensar ou fazer você pensar em algo que não conseguiu sozinho. Confie na experiência das pessoas.

3. Confiança no trabalho dos pares

Esse ponto é difícil. Não confiar cegamente, mas confiar no trabalho dos seus pares. Se não está confiando, dê feedbacks (vamos falar disso também).

4. Compartilhar

Não é só de posts e tech talks que o compartilhamento de conhecimento consiste. No dia a dia é importante falar em conversas, reuniões e cerimônias (daily, retro, etc) para compartilhar experiências. Você vira referência e pode ajudar muito e muitas pessoas assim.

Pair programming é um momento, por exemplo, que os desenvolvedores podem compartilhar conhecimento.

5. Não ser chato

Não seja essas pessoas: piadista, arrogante, cabeça dura, braço curto, e por aí vai. Só não seja a pessoa que ninguém gosta (o chato). Você sabe quando você é assim. Tudo em excesso é prejudicial e às vezes gera um clima ruim, sentimentos indesejáveis, entre outras coisas. Na dúvida, se coloque no lugar do outro e tente ver se você está sendo “chato” ou não.

6. Não ter frescura

As vezes é preciso atuar em sistemas que não estão tão legais. Os famigerados legados. Não pode ter frescura. É legal? Não. Mas você aprende muito (principalmente o que não fazer) quando mexe em sistemas “mal feitos”. E isso também gera confiança no seu trabalho.

“Mexer em sistema legado é igual comer comida ruim, tem que comer rápido..” (Marcio Rodrigues)

7. Não correr o tempo todo atrás do estado da arte

É sempre bom fazer um código maravilhoso. Sem defeitos. Cobertura 100%. Mas na vida real, o importante é ter um mínimo de qualidade e funcionar. É necessário ter equilíbrio. Acredito ser importante fazer um código de fácil manutenção e bem feito, mas não extrair até a última gota de perfeição. Para isso serve o “refactoring”. Se for passar por um código de novo, sempre melhore ele se possível.

8. Feedback

Dar e receber feedbacks nos ajuda a evoluir e cria empatia. Ao invés de ficarmos sempre falando mal do coleguinha para os outros, falar para ele o que nos incomoda, com jeito e educação. Isso é importante para a evolução de ambos.

E, se você não gosta de receber feedbacks (principalmente aqueles críticos), talvez seja hora de procurar ajuda. Quando você não recebe bem feedbacks, vai receber cada vez menos e vai perder ótimas oportunidades de evoluir. Ninguém é perfeito.

9. Ser sincero

Ser sincero na hora de dar o feedback sobre comportamento, código, entre outros. Isso é crucial quando se trabalha em equipe.

10. Estudar

Esse é um ponto importante, mas acredito que seja meio simples. É importante sempre estudar, ler notícias, conversar com as pessoas, ir em eventos, entre outros. A infinidade de linguagens e ferramentas que existem e são lançadas todo ano, seus usos e combinações são tão grandes que é necessário sempre se manter atualizado. Assim como esperamos que um médico esteja atualizado quando o visitamos.

Eu acho que o mais importante dentro desse ponto é saber que existe a linguagem e/ou ferramenta. Você pode voltar naquele assunto se um dia precisar. Sabendo que existe e para o que serve você consegue catalogar isso na sua cabeça e acessar quando for preciso. Não precisa saber tudo (e também não é possível você estudar tudo sobre tudo).

11. Casos reais são melhores

Quando for estudar, tente pegar algo útil e da vida real para criar uma aplicação. Por exemplo, você pode juntar o desejo de estudar Golang e a “necessidade” de pegar todos os repositórios que você segue no Github e fazer um código que liste.

12. Se organizar

Não existe receita para se organizar da melhor maneira. Cada um faz de um jeito e eu mesmo já mudei a minha maneira diversas vezes. Hoje em dia me organizo com a técnica Pomodoro (para foco), Habitica (para organizar tarefas) e o Trello (para todo o resto).

13. Automatizar

Tente automatizar tudo que conseguir. Além de aprender coisas novas, você vai economizar tempo no dia a dia. Criei diversos aliases para utilizar o git, por exemplo. Em vez de digitar git fetch --all --prune && git pull origin master, eu digito gfp master.

Conclusão

Você precisa equilibrar o que é bom para você e o que é bom para a empresa ou o projeto que está participando. Ser melhor para você às vezes não é o melhor para outros (óbvio, mas tem que manter isso em mente).

Um ponto importante é ter uma vida interessante também fora do trabalho. Fazendo qualquer coisa que não seja seu trabalho. No meu caso, é curtir com minha esposa as coisas da vida e fazer um som \m/.

Enfim, acredito que a “lição” mais importante que aprendi na minha vivência é absorver o que for importante e conveniente. Descartar e/ou aprender com as coisas ruins. Por exemplo, depois de ler esse texto, o que vai agregar de fato? Espero que tenha acendido pelo menos uma fagulha na mente. o/

Agradecimentos especiais para quem me ajudou e revisou este texto: Alisson R. Perez, André Maldonado, Camila Dantas, Jota Feldmann, Marcel Viana, Marcio Rodrigues e Priscila Negreiros.