Coisas que você não deve fazer como um Engenheiro de Software

Tenho trabalhado como engenheiro de software por mais de 8 anos. Isso não me torna um expert, mas tenho certeza de que cometi erros suficientes para compartilhar com você. Aqui estão as 10 coisas que você nunca deve fazer como engenheiro de software!

Ser Perfeccionista

Nada é perfeito, e tenho certeza de que não existe algo como “código perfeito” também.

O desenvolvimento de software é um processo iterativo. Você escreve código, testa, recebe feedback, refatora e repete. Algo que funciona hoje pode não funcionar amanhã. Portanto, o software deve ser flexível e fácil de mudar (é por isso que é chamado de software).

Não estou dizendo que você deve abandonar a busca pela perfeição. Estou apenas dizendo que você deve estar ciente de escrever um código que seja muito rígido e complexo.

Ser profissional é diferente de ser perfeccionista – é mais como ser otimamente bom na maior parte do tempo.

“Por favor, me dê algum tempo para refatorar!”

Refatoração de código é o processo de reestruturar o código existente sem alterar seu comportamento externo. O código sem refatoração começará a “cheirar mal”, o que significa que será difícil de ser entendido ou utilizado por outros desenvolvedores.

Nós, desenvolvedores, sabemos que devemos sempre refatorar o código após implementar funcionalidades. O problema é que membros não técnicos não se importam com esses detalhes. Eles frequentemente pedirão “Somos uma empresa em rápido crescimento, então quero que você se concentre em adicionar funcionalidades primeiro.”. Mas logo o código se torna impossível de manter e você estará implorando “Por favor, nos dê um tempo para refatorar!”.

Não implore por horas ou dias extras para refatorar. Faça da refatoração parte da sua implementação de funcionalidades.

Entender errado o que significa “código legado”

O ecossistema de desenvolvimento web é famoso por mudar rapidamente. Lembro-me de um dos meus projetos web anteriores que usava a versão 10 do Next.js ou algo assim. Quando comecei a trabalhar nele, a versão 11 do Next.js foi lançada, repleta de novos recursos e melhorias. De repente, meu projeto da versão 10 parecia um projeto legado.

Muitas pessoas entendem mal o que significa “código legado” como “código antigo”, mas não é. Segundo Michael Feathers, autor de “Working Effectively with Legacy Code”, código legado é código sem testes. Se você não pode testar seu código, não pode refatorá-lo. Se não pode refatorá-lo, não pode mantê-lo.

O “antigo” projeto Next.js, na verdade, tinha uma boa cobertura de testes e tudo funcionava bem. Era um “código bem mantido”, não “código legado”. Por favor, não perca tempo correndo atrás de ferramentas só porque são novas e brilhantes. Lembre-se de que o Github ainda funciona em Ruby on Rails, que tem 17 anos.

“Programação funcional é a melhor!”

Sim, programação funcional é uma novidade – todos os “jovens legais” estão fazendo isso. Mas isso não significa que você deve usá-la em todos os lugares.

Por exemplo, se você está trabalhando em um projeto Flutter, pode não ser uma boa ideia usar programação funcional na camada de interface do usuário. Muitas vezes, usar muito código “puramente funcional” na camada de interface do usuário pode causar problemas de desempenho, devido a renderizações desnecessárias. O Flutter é projetado para ser usado em estilo de programação orientada a objetos, então você deve usá-lo dessa forma.

Isso não significa que você deve evitar a programação funcional – ou qualquer outra coisa legal – completamente. No mesmo exemplo, você pode usar programação funcional na camada de lógica de negócios, onde é mais adequada. Apenas esteja ciente do contexto em que está trabalhando e escolha a ferramenta certa para o trabalho.

Seguir as “melhores práticas” cegamente

Arquitetura limpa, princípios SOLID, DRY, KISS, YAGNI, TDD, BDD, CI/CD, etc. Existem muitas melhores práticas no desenvolvimento de software. Elas foram inventadas com boas intenções, mas você não deve segui-las cegamente.

Por exemplo, TDD (Desenvolvimento Orientado por Testes) é uma ótima prática para garantir que seu código esteja funcionando conforme o esperado. Mas se você está trabalhando com linguagens amigáveis ao REPL como Clojure ou Python, pode não precisar fazer TDD para tudo.

O único propósito do TDD é obter feedback o mais rápido possível. Se você pode obter o feedback sem escrever testes, então não precisa fazer TDD (embora, você deva escrever um teste!).

Lutar sozinho

Vi muitos desenvolvedores jrs que estão ansiosos para mostrar suas chamadas “habilidades de resolução de problemas”. Eles frequentemente lutam para resolver um problema que já foi resolvido por outros. Por favor, não seja essa pessoa. Não reinvente a roda.

As maiores mentes do mundo são aquelas que se apoiam nos ombros de gigantes.

Quando você começa a trabalhar em equipe, percebe que pode aprender muito com seus colegas que têm mais experiência que você. Eles são seus “gigantes”. Suba nos ombros deles e não perca tempo pulando de volta ao chão. Seu objetivo agora é mirar em gigantes ainda mais altos.

Cair no “FLOW” sem autoconhecimento

Você já experimentou o “FLOW”? É um estado mental em que você está totalmente imerso em uma tarefa, sentindo-se energizado e focado. Como programador, cair no “FLOW” parece que o código está se escrevendo sozinho, e você é apenas um meio. Você está na zona.

Mas cuidado – você pode acabar escrevendo “demasiado” código. Muitas vezes me pego "penteando" coisas quando estou no “FLOW”. Não só eu, mas Robert C. Martin – autor de “Clean Code” – também já experimentou contraprodutividade enquanto estava no flow.

Para intencionalmente quebrar o flow, recomendo usar a “técnica Pomodoro”. É um método de gerenciamento de tempo em que você trabalha por 25 minutos e faz uma pausa de 5 minutos. Isso ajuda você a manter o foco e evitar o burnout.

Não mover o corpo

Trabalhar como engenheiro de software não é fácil. Você estará sentado em frente ao computador por horas, digitando no teclado e olhando para a tela. É fácil esquecer sua saúde quando você está no “flow”. Mas lembre-se, sua saúde é a coisa mais importante. Seu cérebro não serve se seu corpo não está funcionando corretamente.

Tente mover seu corpo a cada 30 minutos (ou 25 minutos se você estiver usando a técnica Pomodoro). Levante-se, alongue-se, caminhe um pouco e beba água. Isso ajudará você a manter o foco e evitar o burnout.

Esquecer como é divertido ser programador

Quando comecei a programar, estava muito empolgado. Estava construindo coisas, resolvendo problemas e aprendendo coisas novas todos os dias.

Mas com o tempo, comecei a esquecer como é divertido programar. Estava muito focado em escrever “código limpo”, seguir “melhores práticas” e resolver “problemas difíceis”. Muitas vezes, eu não conseguia realmente escrever meu próprio código, porque estava muito ocupado seguindo o código de outros e da empresa. Onde foi parar minha criatividade?

Você deve sempre lembrar como é divertido ser programador. Sei que é difícil, mas tente encontrar tempo para trabalhar em seus próprios projetos, aprender coisas novas e construir algo legal. No seu local de trabalho, tente se comunicar com seus colegas sobre novas tecnologias empolgantes, mesmo que você não as use no seu projeto. Isso ajudará a manter a motivação e a inspiração.

Ser um “codificador”, não um engenheiro de software

Há uma diferença entre ser um “codificador” e um “engenheiro de software”. Um codificador é alguém que escreve código, enquanto um engenheiro de software é alguém que resolve problemas usando código. Tenho 2 fortes razões pelas quais você não deve ser um codificador:

Os chamados “codificadores” serão substituídos por IA no futuro (na verdade, já estão sendo substituídos). Sei que é um pouco controverso dizer, mas é infelizmente verdade.
As pessoas não se importam com seu código, elas se importam com o quão bem você resolve os problemas delas.

Seja um “resolvedor de problemas” que usa o código como uma ferramenta. Entenda o problema, encontre a melhor solução e implemente-a usando código. É isso que um engenheiro de software faz.

Enfim..

Estas são as 10 coisas que, pessoalmente, acho que você nunca deve fazer como engenheiro de software. Elas são baseadas na minha própria experiência pessoal, então não espero que todos concordem comigo. Mas espero que você as ache úteis.

Se tiver outras coisas para adicionar, por favor, me avise nos comentários. Obrigado por ler!