03-02-2020
Como ser um bom developer? Não é apenas sobre código
Por Diamantino Campos, Head of Development @Xray
Permite-me a ousadia de te falar da minha visão profissional sobre como podemos ser realmente bons naquilo que fazemos na nossa área. Sou a pessoa indicada para o fazer? Bem, vou tentar partilhar contigo a minha experiência e os passos essenciais para ser um bom developer, ao longo do teu percurso profissional.
Todos nós queremos ser os melhores naquilo que fazemos seja por razões económicas, realização pessoal, para crescer profissionalmente, entre muitas outras razões.
Para um software engineer não é diferente, ainda para mais porque pertencemos a uma área que está em constante transformação e evolução. Também podemos dizer que existem algumas particularidades nas áreas de programação como:
- o facto de haver diversas abordagens para resolver um desafio;
- A solução que agora é a mais adequada pode deixar de o ser quando as circunstâncias mudam;
- E o facto de que numa grande parte do tempo, o nosso trabalho é analisado por profissionais não tão experts no tema e que tomam decisões a partir da sua perceção de como as coisas funcionam. Por exemplo, um website ou app criados por uma equipa vs. a unidade de código criada por um developer.
Neste artigo vou partilhar a minha visão e abordagem pessoal que me têm ajudado a evoluir e a tornar-me num bom developer.
E já agora é bastante simples até. Não precisamos de ter a precisão de um cirurgião ou de utilizar a força física. Tem tudo a ver com utilizarmos o nosso cérebro!
1 – O que é ser bom developer?
Responsabilidades de um developer
Acredito que um bom developer deve ser capaz de desempenhar pelo menos metade destas tarefas:
- Escrever código (Captain Obvious está aqui)
- Compreender o projeto que vai desenvolver
- Encontrar soluções para os problemas que aparecem
- Estar integrado com a equipa e os objetivos do projeto
- Identificar oportunidades para ser melhor e fazer evoluir a equipa e a organização
2 – Nos primeiros anos da tua carreira
Tem coragem para fazer perguntas
Não olhes unicamente para o dinheiro quando optares por uma empresa. As primeiras entrevistas são difíceis, não sabemos bem o que perguntar. Então acabamos por ouvir o recrutador a falar sobre o projeto, as expectativas da empresa, o salário que oferecem ou os benefícios desta oportunidade para o desenvolvimento da nossa carreira.
Tenta compreender como a empresa funciona e mais precisamente a equipa que vais integrar.
Faz algumas destas questões:
- Têm uma política de revisão de código? (Vamos a este tema mais à frente)
- Utilizam as ferramentas e linguagens mais atuais? E as mesmas têm tração?
- Como está a equipa organizada?
Os primeiros projetos em que participares vão influenciar decisivamente o teu percurso, acredita. Seja pela metodologia que utilizares, as linguagens ou tecnologias que aprenderes e nas quais te vais tornar expert.
Escolhi o meu estágio e primeiro contrato influenciado pelo dinheiro. Tive sorte porque, apesar de não ter sido a empresa perfeita, encontrei alguns bons developers com os quais aprendi coisas relevantes. Era uma empresa focada em Java e Adobe Flex 3 (tinha tração na altura, mas já não tem graças à Apple que “matou” o Flash) e 12 anos depois, aqui estou eu, ainda a trabalhar em Java.
Cheguei a ir a algumas entrevistas em que os recrutadores explicavam o quão bem tratavam os Colaboradores e o quão competitivo era o salário, sem que tivessem abordado os projetos ou as responsabilidades específicas da função. Houve uma vez que regressei da entrevista a pensar “Para além da componente salarial, que mais sei eu sobre esta oportunidade e sobre a experiência que terei nesta empresa, para poder aceitar o desafio?
A partir daí, obriguei-me a nunca mais sair de uma entrevista sem ter a resposta para estas perguntas:
- Quantas pessoas existem na equipa?
- Como está estruturada?
- Quais sãos as tecnologias e versões?
- Qual o estado de desenvolvimento do projeto/produto?
3 – Durante a tua carreira
Aprende com alguém
Ao trabalharmos numa equipa são constantes os incentivos para podermos melhorar. O mais importante aqui é ter pelo menos um mentor (um bom developer) que é melhor do que tu e que está disposto a partilhar. Pode ser o teu manager ou colega. Observa a forma como ele resolve os desafios. Aprende, estuda, e segue os seus passos.
Se estás nos teus primeiros anos de carreira e a dada altura pensares que és o melhor, das duas uma: ou deves ser mais humilde ou está na altura de procurares um novo desafio à tua altura.
Abraça a crítica
Outro bónus extra é a política de revisão de código. Não o vejas como um sinal de que o teu trabalho está a ser julgado pelos teus colegas de equipa. Olha para a revisão de código como o melhor atalho para melhorares as tuas competências técnicas. É como se fossem aulas pessoais grátis com exemplos reais.
Pensa e pensa de novo
Encontraste uma forma rápida de corrigir um bug? Pensaste sobre essa solução 2, 3 vezes? “é apenas um novo requisito de um componente e funciona”, pensas. Garante que o teu código não afeta outras funcionalidades e respeita os princípios básicos da programação. Não queres ficar preso na revisão de código.
Lembras-te do meu primeiro trabalho? Nessa experiência não tínhamos procedimentos de revisão de código. Tive um excelente team leader com quem aprendi imenso sobre questões técnicas e skills de comunicação, mas ele saiu da empresa logo no meu primeiro ano. Fiquei com a sensação de que estava parado, sem evoluir. O que me levou a mudar de empresa onde achei que podia aprender mais.
Olhando para trás, o conselho que te dou é: não te precipites por haver períodos em que não estás a aprender coisas novas, mas não te demores quando já não estiveres a aprender com ninguém.
4 – Queres exceder as tuas capacidades?
Se és inteligente e dedicado o suficiente e seguires estas dicas serás no mínimo um developer profissional.
Sê disciplinado, focado e curioso
O dia normal de um developer tem 8 horas de trabalho que não são 100% dedicadas às nossas tarefas recorrentes. Para além das pausas para o teu cérebro respirar, se por algum motivo não tiveres uma tarefa durante algumas horas, aí está uma excelente oportunidade para aprenderes mais.
Compreende o projeto em que estás a trabalhar
Sabes a base do projeto em que estás a trabalhar?
- Como é que o teu trabalho se integra com o resto?
- Estás apenas a resolver bugs? O que estão os bugs a impedir que os utilizadores façam?
- Estás a construir uma REST API? Como e com que objetivo é que vai ser utilizada?
- Estás a criar uma nova componente UI? Onde é que vai ser utilizada e por que motivo o projeto precisa dela?
Lembra-te que só tens algumas horas no máximo, sê o mais pragmático que conseguires. Percebe o essencial e não o projeto no seu todo de uma vez.
Investe em ti
Queres ser excelente, certo? Vamos a isto! Se fores como a maioria de nós, tens de ir mais além e tirar algum do teu tempo livre para aprender mais. Deves descansar e vais precisar de o fazer, mas se queres realmente ser um bom developer não há um comprimido mágico. Confia em mim: o dinheiro é mais barato que o tempo. Tira algum do teu tempo livre para conheceres novas abordagens ao código, lê exemplos, aprende a partir de conteúdos em blogs fiáveis e até mesmo de livros com foco na tecnologia em que estás ou queres vir a trabalhar.
Ainda sobre a minha experiência, depois de mudar de empresa, conheci uma pessoa que investia em certificações de JAVA (não sabia sequer que isso existia).
Isso fez-me pensar que para ser melhor teria de investir mais em mim. Então comecei a estudar mais sempre que podia. Os primeiros 2 livros que li foram “Spring in Action” e “EJB 3”. Mais do que ter aprendido sobre estas frameworks, aprendi sobre a estrutura de código bem como as melhores práticas.
Não há problema em errar
Como dica bónus: aceita o erro. Mesmo que tenhas desenvolvido algo com sucesso, vais errar pelo caminho e está tudo bem, desde que aprendas com isso. É aquilo a que se chama experiência. Experiência não é o somatório de anos a trabalhar. É resultado final de situações com as quais tiveste de lidar.
Uma vez estava num projeto ambicioso que tinha como objetivo otimizar a alocação de recursos de um hospital privado tais como: camas, horas de enfermagem, salas de operações, ect. Este projeto tinha equipas multidisciplinares independentes. O input para a minha equipa dependia do output de outra equipa sendo que uma terceira precisava do nosso input. Todo o trabalho estava organizado a partir de “critérios de aceitação” e de uma check-list. Tinha tudo preparado, mas havia uma interpretação diferente sobre um AC em particular entre mim e um outro developer de outra equipa. Nesta fase, não houve qualquer impacto nos testes nem na pré-produção, mas num determinado domingo de agosto recebi uma chamada do meu manager porque o cliente não estava a conseguir utilizar a ferramenta. O problema podia ter sido evitado se eu tivesse tido uma conversa de 30 minutos com o meu colega para uma revisão final.
Não gosto nada de errar, mas essas foram as melhores lições que tive. Mesmo numa pequena tarefa ou num projeto, sê o mais rigoroso possível, aceita e aprende com o resultado disso.
5 – É suficiente para ser um bom developer?
Após algum tempo a evoluir enquanto developer e tendo-me tornado num team Leader na Xpand IT, estas dicas são as questões que considero centrais para se ser um bom developer.
Nem todos os seres humanos têm exatamente as mesmas capacidades. Uns aprendem mais depressa, outros pensam mais rapidamente. Alguns são mais teóricos e outros mais práticos. Aceita a tua forma de fazer coisas, corrige aquilo que podes estar a fazer mal e segue o caminho que queres para a tua carreira.
Ser um bom profissional é a primeira coisa a fazer para te tornares num bom developer. Tal como em todos os outros trabalhos. Só que no nosso caso termos uma imensidão de gatos voadores num mundo obscuro à espera de serem libertados.
*Este artigo é uma versão PT do conteúdo original que pode ser lido aqui.
Leave a comment
Comments are closed.