Como ser um bom profissional — e não apenas um escritor de código
Numa área cheia de profissionais e amadores, um amigo e eu começamos a matutar sobre boas e más práticas no nosso universo — o de desenvolvedores profissionais de software e os padrões sobre bons e maus profissionais. Esses são nossos pensamentos…
Disclaimer: em nenhum momento queremos nos provar melhores do que alguém, apenas estamos expondo pontos de vista que nos incomodam e que certamente podem ser melhorados, inclusive por "cachorro velho" da área.
Siga boas práticas
Ninguém com uma índole decente quer fazer um trabalho mal feito. Não há desculpa para isso. Se você vê algum artigo sobre dicas para utilizar "ferramenta x" de maneira melhor, leia e, principalmente, ponha em prática. Boas práticas existem por um motivo — no caso, você não repetir erros de outras pessoas. Errar é humano, persistir no erro é burrice. Exemplos de boas práticas. As boas práticas mudam com o tempo, então mantenha-se atualizado com elas. O que era uma boa prática há 5 anos, hoje pode ser desencorajado.
Não se repita
Se você escreveu algum código e, mais tarde, viu que escreveu um código parecido, trabalhe numa abstração. Ter mais de um ponto em que a funcionalidade é duplicada significa mais de um ponto de manutenção, que por sua vez quer dizer dor de cabeça para o desenvolvedor e um sistema propenso a bugs. No desenvolvimento para a web, em que o tamanho do arquivo geralmente é crítico, quer dizer mais código entregue para o cliente. Mais código é ruim. Don't repeat yourself, mas, as vezes, sim.
Não reinvente a roda
Estamos em 2019. Não reescreva código. Utilize o que já existe (e o que você quer provavelmente já existe, a menos que você procure por algo extremamente específico). Existem vários benefícios em utilizar código de terceiros, mas vou citar os dois que considero mais fortes: ter a garantia de que funciona e poupar tempo.
Quando você integra uma biblioteca no seu sistema, você está utilizando algo que provavelmente já é maduro, ou seja, já foi utilizado por outras pessoas, que apontaram falhas que já foram corrigidas pelos mantenedores da biblioteca. Além disso, existem casos de uso que provavelmente não passam pela sua cabeça enquanto você codifica uma solução nova. Esses casos de uso, na maioria das vezes, já foram cobertos, então é meio como usar cheat, mas um cheat do bem.
O Github está aí. Faça bom uso — é de graça!
Porém, não seja extremista a ponto de não desenvolver nada, de só querer as coisas prontas e é isso aí: você é um desenvolvedor. Desenvolva. Na maioria das vezes você trabalhará "colando" coisas que já existem, como se fossem peças de lego, então entenda os motivos das ferramentas que usa. Mas nem tudo está desenvolvido, se não a profissão nem existiria, então mantenha seus dedos bem ativos.
Uma vez ou outra procure ler os códigos-fonte das bibliotecas para entender as implementações delas. Um bom desenvolvedor, geralmente, quando lê uma biblioteca, gosta de imaginar como teria implementado ela e olha o codigo para ver como fizeram.
O único motivo válido para reinventar a roda é com a intenção de entendê-la. Aí sim é interessante porque você vai entender como a abstração que você está utilizando funciona. Mas não use a roda reinventada em produção. Use algo bem testado.
Não deixe a performance de lado
Apesar de termos a cada dia computadores mais poderosos, fazer um código performático é importante. Tenha noções de estruturas de dados e qual é a mais adequada para cada tipo de situação. Por exemplo, se eu tenho um id e vários registros e preciso acessá-los, não faz sentido iterar sobre uma lista sendo que já sei exatamente o que quero achar: para esse caso, armazene seus registros num key-value pair (objeto ou Map) para que o acesso seja em velocidade constante.
Mas claro, não se preocupe com a performance antes de ao menos fazer seu algoritmo funcionar. É melhor um algoritmo lento funcionando do que um algoritmo rápido que não funciona direito. Vá incrementando aos poucos.
Para esse tópico, recomendo que procure aprender e masterize os fundamentos da ciência da computação, principalmente a análise Big(O) e as mais famosas estruturas de dados, tais como os melhores algoritmos para ordenar listas.
Evite a otimização prematura
Talvez você não precise de um framework web que sirva trocentos milhões de requests por segundo se tudo que você está desenvolvendo é um protótipo. Não mate uma mosca com um canhão! Em suma: é necessário saber o momento certo de evoluir seu projeto.
Uma arquitetura fodástica que demorará 1 ano pra ficar pronta e atenderá 10 clientes ou um projetinho mais modesto, que servirá como MVP para buscar feedbacks dos mesmos 10 clientes que, se utilizando o software e conseguindo dar a opinião imediata, podem te ajudar a melhorá-lo enquanto você incrementa. O que mais vale?
Porém, é preciso tomar cuidado para saber quando tem que evitar tais otimizações prematuras, e também não se pode exagerar usando essa argumentação como justificativa por não ter pensado em uma maneira melhor de resolver o problema. Muitos códigos podem ser melhorados tanto em termos performance quanto legibilidade ao mesmo tempo, esses casos podem não ser exatamente otimização prematura: só está mudando o código para usar as estruturas de dados e algoritmos corretos… Se isso for algo fácil ou válido de se fazer, porque não aplicar essa melhoria?
Desenvolva a capacidade de se antecipar aos problemas e pense antes de agir
Um bom profissional consegue olhar para o macro, para uma visão fora da caixa em relação ao que está trabalhando. Isso o ajuda a saber dos possíveis problemas que podem aparecer com o sistema que está sendo desenvolvido e, possivelmente, relatar para os superiores ou colegas de equipe, assim eles vão saber quais atitudes tomar para prevenir uma situação caótica no futuro.
Tambem acho que vale a menção ao YAGNI: é necessário tomar cuidado entre o “antecipar problemas” e o “fazer algo para o futuro que nunca pode ser utilizado ou necessitado”. Essa distinção é complicada de ser feita, por isso trabalhamos em equipe! Quando tentamos prever cenários, sempre pergunte-se: "faz sentido? É algo válido dar atenção para isso agora? Estou supondo demais e preciso de mais dados para analisar a situação?"
Esqueça a ideia da bala de prata
Uma coisa que incomoda muito na área é o fato de termos programadores que só trabalham com X ou com Y. É claro, ninguém vai saber tudo, mas se especialize na área, e não numa ferramenta apenas. Não existem soluções que lidam com absolutamente todos os casos de maneira magistral. Existem ferramentas X para problemas X e ferramentas Y para problemas Y. Saiba diferenciar e não adote um framework de estimação, pois você será enterrado junto.
Por exemplo: eu sou um desenvolvedor front-end. Não faz sentido eu ser muito bom apenas em React. Eu preciso ter todos os fundamentos de HTML, CSS, JavaScript, ter conhecimento de no mínimo mais um framework e, esticando um pouco, manjar um pouco de design, dar uma pincelada no mobile, saber ao menos brincar no back-end para não depender de desenvolvedores para construir mocks, por exemplo, e a lista vai… Seja independente, e a independência só vem se você botar a cara para aprender coisas novas.
Seja comunicativo (a) e saiba trabalhar em equipe
Pode parecer chocante, mas você não está sozinho nesse mundo — há uma grande chance de você trabalhar com um time, que é composto por humanos que ainda não sabem ler mentes. Eles não conseguem adivinhar o que você está pensando ou no que você está trabalhando a menos que você saia da sua caverna e fale. Desenvolva as famosas soft skills, que ajudarão a melhorar sua produtividade de maneira indireta.
Mantenha-se atualizado
Você está na área que mais evoluiu nos últimos 20 anos. Sabia que há duas décadas mal existiam computadores pessoais? Hoje qualquer pessoa tem um no bolso. A área muda drasticamente a praticamente cada ano. Acate a ideia de não ser ultrapassado, garanta conhecimento e o mais importante: um salário.
A melhor maneira de ficar no loop é contribuindo para a comunidade open-source, que, ainda por cima, te dará muita experiência. É uma das melhores maneiras de ter boa vivência de código pois você estará vendo código de outras pessoas e estará expondo o que você faz de bom para ajudar os outros, o que torna essa uma situação win-win.
Além disso, aprenda a aprender: entenda como fazer curadoria do material que você estuda, buscar pelas pessoas que são referências do assunto, organizar esse material de forma que você possa acessar ele facilmente, buscar otimizar o tempo de estudos, etc. Isso conta muito para que você consiga desenvolver o autodidatismo e aprender novas habilidades de maneira mais rápida e, ao mesmo tempo, sozinho.
Saiba ler
É bizarro ter que falar isso, mas as vezes parece que as pessoas não sabem ler. Tenha calma quando estiver lendo um README; pesquise a documentação de uma biblioteca antes de abrir issues idiotas no Github que serão fechadas e ignoradas pelos contribuidores; procure por recursos ou apenas jogue o erro no Google — na maioria das vezes funciona. Não seja ignorante!
Não seja preguiçoso
Complementando o último ponto: você tem dois olhos e um cérebro funcional. Aja de acordo com ele lendo as mensagens de erro — que na maioria das vezes jogam na tua cara o que está errado — , e pensando em como resolver antes de procurar na internet. Evite a preguiça: ao menos tente fazer seu código funcionar antes de tacar o erro no StackOverflow ou pedir para os outros algo que pode ser relativamente simples.
Não seja um idiota
NÃO SEJA o sabe-tudo. Ser arrogante a ponto de pensar que é o melhor do mundo e que ninguém merece sua ajuda ou sua mentoria, ou pensar que você não pode aprender nada e já sabe de tudo é um erro crasso. Tenha os pés no chão. Todos têm a mesma capacidade que você!
Não tenha vergonha
Se você for iniciante, não hesite em pedir ajuda, perguntar, ter vontade de aprender e coisas desse tipo. Ninguém nasceu sabendo e mesmo você, iniciante, pode contribuir ensinando o que sabe para pessoas ainda mais novas na área. Tente fazer pair programming com colegas de trabalho com mais experiência para pegar bem os conceitos e fundamentos do que você trabalha.
Tenha ética
Os sistemas que desenvolvemos vão fazer parte da vida das pessoas, então eles podem ser a solução ou a causa dos problemas delas — trabalhe com responsabilidade. Eis um ótimo artigo sobre ética na nossa área.
Conheça bem sua ferramenta primária de trabalho
Seja um especialista no que faz diariamente. Entenda o que sua ferramenta favorita procura resolver; como ela faz isso (i.e. olhando o código-fonte); porquê ela faz isso de um jeito e não de outro; suas qualidades, defeitos e as soluções para tais defeitos. Se possível, contribua para a melhoria da ferramenta a aprenda tudo sobre o seu ecossistema: melhores pacotes, melhores práticas, padrões de design e otras cositas más.
Não surfe no hype e tenha calma
Aquela biblioteca hipster acabou de entrar no estágio alpha. Hora de implementar isso no projeto oficial, certo?
Errado, pô! Espere. Espere ao menos a biblioteca ficar estável, e testada, com os principais bugs resolvidos para evitar que você os descubra e comprometa a confiança do seu sistema. Se a nova biblioteca for crítica, crie um protótipo explorando o que pode dar errado e apresente para o time. Se for aprovado, aí sim você pensa em implementar.
Se o caso for você aprendendo uma linguagem nova ou uma ferramenta, não vá implementando no projeto oficial logo "de cara". Dê um tempo, aprenda todos os casos de uso, ponha a mão na massa para ter a ideia real da solução e veja como aquilo pode te ajudar.
Conheça ao menos um framework de gerenciamento de projeto
É muito difícil de ter um projeto sério sem um framework para organizá-lo. Ainda mais tendo em mente que você não trabalha sozinho e todo mundo precisa estar na mesma página. Aprenda sobre metodologias ágeis, aprenda no mínimo como funciona o framework SCRUM para que tenha um projeto e um processo bem definido. Os benefícios são tremendos, como um aumento de produtividade enorme e a diminuição dos enganos e erros bobos. Ser um desenvolvedor é muito mais do que sentar a bunda numa cadeira e digitar uma coisas num editor de texto. Esteja envolvido no maior número de passos possíveis!
Aprenda a se organizar
É crucial ser uma pessoa organizada. Não apenas no ambiente de trabalho, mas também na vida. Você está no controle das suas ações, então nada mais justo de que todas as suas ações, o modo em que elas fluem, estejam claros na sua cabeça. Anote os passos, crie um kanban com lanes específicas para o estado das suas tarefas (ex.: "A fazer", "em andamento", "concluído").
A dica de ouro dessa seção é: divida uma tarefa muito grande em micro-tarefas. Com problemas menores, você terá a impressão de que o problema não é tão grande assim pois estará dividido em etapas e, além disso, terá um controle maior sobre o andamento. Use e abuse da divisão e conquista.
Não ignore os testes
Evite que o usuário final seja o tester. Testes não são perda de tempo! Eles te salvam tempo checando se tudo funciona. Os clientes que entram no seu sistema o fazem para executar uma tarefa. Tenha certeza de que eles conseguem, senão eles não voltam e a empresa em que você trabalha perde dinheiro, o que significa que você não terá aumento e terá o dobro de estresse pegando erros em produção. Leia mais sobre testes.
Ainda sobre esse ponto: não tenha medo da sua aplicação. Teste-a. Teste-a extensivamente. Testes unitários, de integração, end-to-end, de carga. Exponha-a ao seu limite, assim você terá confiança de que aquilo que você está desenvolvendo funciona.
Automatize processos
Invista em CI e CD. Por quê gastar tempo fazendo tarefas repetitivas sendo que as máquinas existem exatamente para isso? Você não precisa ficar se preocupando em lembrar de testar seu código localmente, ou pode automatizar o deploy da sua aplicação para que nenhum passo seja esquecido ou para que apenas seja mais rápido, mesmo.
Seja um bom profissional
Não adianta nada ler até aqui e não seguir nada do que foi dito. Seja referência no que faz. Tente não cometer erros amadores — afinal, você é um profissional e profissionais sabem o que estão fazendo!
E como você é um profissional, aplique todos os pontos aqui listados utilizando do bom senso: analise cada situação e veja se vale a pena aplicar, caso a caso. Esteja atento aos edge cases, que são difíceis de encontrar no dia-a-dia, mas quando acontecem, se você se apegar demais nessas argumentações, as coisas podem dar errado.
Saber identificar edge cases para esses cenários inclusive é uma habilidade que a gente tem que evoluir. É dificil, algo que acontece com o tempo e experiência. Você vai errar, e muito, mas é com seus erros que você se tornará um melhor profissional.
Tenha tesão pelo que você faz, seja autodidata e tenha iniciativa; se valorize quando achar que mereça ganhar mais (tenha argumentos para sustentar sua tese, é claro), mas não deixe o dinheiro subir à sua cabeça, porque é sua reputação que está em jogo. Dê seu melhor.
O mundo lá fora é seu, vá ganhá-lo!
Agradecimento especial à Natan Lotério, Gabriel Takashi Katakura, Raffael Tancman, Alesson Bernardo e Sibelius Seraphini por contribuições ao texto!
