7 hábitos simples dos engenheiros do 1% do topo

• "Como os programadores de elite conseguem desempenhar muito melhor do que os demais"

Seja um engenheiro, não apenas um programador (Be an engineer, not a coder)

• Engenharia é resolver problemas
• Os melhores engenheiros veem o código como um meio para alcançar um objetivo
• Existe prazer em escrever código, mas escrever código sem propósito não faz sentido. Em vez disso, o código é usado para projetar soluções para os usuários
• Programar busca criatividade! A criatividade costuma surgir sob restrições. Ao adicionar a "restrição" de um problema claro a ser resolvido, o engenheiro ganha liberdade para explorar e construir soluções da forma que considerar mais adequada
• Os melhores engenheiros têm foco no produto e, acima de tudo, priorizam resolver problemas para as pessoas, o que nos leva ao próximo ponto

Código para humanos, não para o computador (Code for the human, not the computer)

"Qualquer idiota consegue escrever código que um computador entenda. Bons programadores escrevem código que humanos entendem." - Martin Fowler

• O código não é só para o computador, mas também para humanos
• O código é para os engenheiros do mesmo time que vão lê-lo, mantê-lo e construir em cima dele
• O código é para os usuários, seja uma criança usando um celular, um desenvolvedor chamando uma API ou você mesmo
• Os melhores engenheiros sempre avaliavam o valor do código para todos os usuários
• Se ele não satisfizesse nem um desses públicos, esse código não ia para produção

Desapegue do código em si (Detach from the code itself)

• Engenheiros excelentes não ficam apegados ao código em si
• Eles não têm medo de apagar e recomeçar mesmo um código 90% pronto, se isso significar um resultado final melhor no geral
• Como código não é algo pessoal, eles acolhem feedback de forma ativa
• Código não é perfeito. Ninguém se importa com código perfeito. As pessoas se importam com código que gera impacto
• A melhor forma de treinar esse desapego é "perceber que, daqui a 20 anos, a maior parte do seu código provavelmente terá virado dívida técnica, deixado de ser usada ou sido reescrita"

Use padrões consistentes (Use consistent standards)

• Ao escrever código, siga padrões consistentes e um estilo de codificação uniforme
• Manter consistência ajuda tanto você no futuro quanto seus colegas a ler e entender o código com mais facilidade
• Usar um guia de estilo consistente facilita escalar tanto o time quanto a base de código
  • É assim que empresas como Meta e Google conseguem entregar muito código rapidamente sem que, com o tempo, a base de código se torne ilegível ou impossível de manter
• Toda empresa de alto desempenho internalizou guias de estilo, conhece seus benefícios e procura segui-los ao máximo
  • O Google publicou parte de seus guias de estilo como open source
  • A Meta tem um guia de estilo de C++ em alguns de seus projetos open source
• Dica: vale muito a pena investir tempo em configurar linter e formatação para o seu time

Escreva código simples (Write simple code)

• Todos os engenheiros de elite que conheci talvez tenham passado por um processo complexo para criar algo, mas no fim produziam código fácil de ler e entender
• A melhor forma que encontrei de descrever isso é que o código deles era "esteticamente satisfatório"
• O código deles era limpo, organizado e lógico (clean, organized, and logical)
• Cada decisão tomada no código fazia sentido e, quando não fazia, isso estava bem documentado no próprio código
• Uma boa forma de escrever código limpo é seguir princípios como SOLID. Embora tenham sido pensados inicialmente com OOP (programação orientada a objetos) em mente, eles também podem ser estendidos à programação em geral
  • Single Responsibility: uma classe deve ter apenas uma responsabilidade
  • Open-Closed: objetos de software (classes, módulos etc.) devem ser abertos para extensão, mas fechados para modificação, a fim de criar código previsível e de fácil manutenção
  • Liskov Substitution: subtipos devem poder substituir tipos base sem afetar a correção do programa
  • Interface Segregation: o código não deve depender de uma interface gigantesca que não usa por completo. Em vez disso, os pacotes devem poder incluir e importar interfaces menores e específicas
  • Dependency Inversion: módulos de alto nível não devem depender de módulos de baixo nível; ambos devem depender de abstrações, promovendo um design de sistema mais flexível e desacoplado
• Um exemplo disso é naming: bons nomes evitam valores mágicos, deixam distinções claras e expressam nomes de funções descritivos e variáveis fáceis de entender

Não permita surpresas (Don’t allow surprises)

• O código não deve produzir resultados inesperados. Isso é possível seguindo princípios de código e escrevendo testes adequados
• Código bom é previsível
• Testes reforçam a clareza e a previsibilidade do código, além de trazer confiança. Com bons testes automatizados, o time pode alterar o código sem medo de quebrar partes que não estão visíveis
• Alguns tipos de teste
  • Testes unitários para componentes individuais e funções isoladas
  • Testes de integração para a interação entre vários componentes
  • Testes end-to-end para avaliar o funcionamento do sistema inteiro pela perspectiva do usuário
• Os testes devem ser simples. Ao ler um teste que falhou, deve ser fácil identificar o que deu errado
• Também é importante saber o que não deve ser testado
  • Por exemplo, se o esforço de testes end-to-end for maior do que o benefício real para o programa, os testes podem ser substituídos por documentação cuidadosa, monitoramento e alertas para as pessoas certas (por exemplo, o responsável pelo código)
  • Além disso, testes não devem verificar detalhes de implementação no código, como testar seletores específicos de CSS em código frontend ou usar apenas atributos de dados ou testes por screenshot

Comunique-se com frequência (Communicate often)

• Grandes sistemas não são construídos sozinhos. Grandes engenheiros passam por revisões de design, pedem feedback e continuam iterando sobre o desenho inicial do código
• Todo mundo tem lacunas no próprio conhecimento que outra pessoa pode preencher. Novas perspectivas muitas vezes ajudam a tornar o código mais claro ou oferecem novas abordagens que antes não tinham sido consideradas
• Os melhores engenheiros valorizam comunicação e colaboração e não têm medo de investir tempo em trabalhar junto para chegar a um resultado final melhor
• Isso pode ser tão simples quanto mandar uma mensagem para um colega fazer uma revisão rápida de um documento ou adicionar revisores em um pull request importante

Programe rápido... e devagar (Code fast… and slow)

• Os melhores engenheiros que conheço concluem projetos rapidamente, mas codificam devagar
• Parece estranho, não?
  • Todos os princípios e hábitos acima adicionam mais tempo à primeira etapa da codificação. Mas é justamente por meio deles que o engenheiro consegue avançar o projeto passo a passo
  • Ao dedicar tempo para usar padrões, testar direito, aplicar princípios e se comunicar com frequência, é possível economizar muito mais tempo no longo prazo
• Eu vivi isso em primeira mão quando era estagiário e engenheiro júnior, e muitos outros engenheiros também: ao tentar correr para avançar 3 passos, você pode bater em um obstáculo e acabar recuando 5

Não siga regras cegamente (Don’t follow rules blindly)

• As "regras" e "princípios" acima são apenas diretrizes. Nem tudo se encaixa perfeitamente nelas
• Às vezes, o código que você está escrevendo pode ser um quadrado tentando entrar em um círculo, e tudo bem
  • Nesse caso, documente por que o código foi escrito daquela forma
  • Caso contrário, alguém como você no futuro pode olhar para o código e pensar: "Nossa, eu era muito burro naquela época. Por que isso não segue nossos padrões?"
  • Então essa pessoa vai gastar 20 horas recodificando para se adequar ao padrão e chegar exatamente à mesma conclusão de antes
• A realidade do desenvolvimento de software é que nem todo código pode ser limpo ou seguir perfeitamente as regras
• Mas é possível existir código consistente, limpo, fácil de entender, testável e valioso
• Outros padrões que encontrei nos melhores engenheiros
  • Têm conhecimento profundo de domínio em pelo menos uma área. Todos os engenheiros que observei se tornaram especialistas ao focar em um campo específico, como infraestrutura de frontend, sistemas distribuídos ou UI limpa, e por isso chegaram ao topo em suas áreas
  • Sabem se promover com frequência e da forma certa. Esses engenheiros não ficavam escondidos em lugares pouco visíveis. Todas as pessoas com quem trabalhavam no time conheciam seu valor e sua especialidade, resultado de uma boa divulgação do próprio trabalho e de projetos de alto impacto

[greety]

Obtive bons insights. Obrigado :)

[geekbini]

Que bom texto!

[nina514]

A tecnologia também é importante, mas isso realmente me faz pensar mais uma vez que o mais importante é criar produtos que beneficiem as pessoas!!!

[functor]

Obrigado pelo ótimo texto!

[functor]

Pensando bem, são 7 hábitos, mas o conteúdo na verdade tem 9 kkk

[xguru]

Eu também contei... acho que o último e o primeiro são só o título mesmo! haha

[saalome]

Uau, um texto excelente com o qual dá para concordar quase totalmente rs

[saalome]

De todos os textos desse tipo que vi até agora, este é um conteúdo fora de série.

[rsm0503]

Generalizando um pouco, é um ótimo texto que pode ajudar todo mundo.

[kuroneko]

A essa altura, isso parece mais uma tradução do que um resumo... Muito obrigado pelo resumo.
É um texto que vale a pena reler de vez em quando.

[piriri11]

Realmente é isso mesmo kkk eu também vou reler isso de vez em quando.