Manifesto da Engenharia

Sobre as lições do passado e os passos para futuro para o time de engenheiros da Quero Educação

O time de Engenharia continua crescendo e é crucial que tenhamos uma compreensão compartilhada para ter controle total sobre a tecnologia que usamos. Para isso, os engenheiros da casa devem saber como tomar decisões e priorizar o trabalho para garantirmos nosso objetivo: levar educação a um preço acessível e auxiliar a jornada do aluno em todo o processo.

Extraímos algumas das lições que aprendemos ao construir a Quero nos últimos anos em um conjunto comum de princípios de Engenharia. Não são regras, mas um guia útil para lançar novos recursos/funcionalidades rapidamente.

Este é o tipo de lista que nunca será concluída. Vamos aprimorá-la enquanto aprendemos e testamos novas ideias.

Seja accountable

Não existe uma tradução perfeita para o português, talvez a melhor seja aquilo que chamamos na Quero de DC (Disciplina Consciente). Seja responsável pelos seus atos, seus códigos e suas entregas. Se identificou algum problema, aja para que ele seja solucionado. Embora nem sempre evidente, a sua equipe, seus líderes e a empresa sofrem um impacto direto de suas ações.

Não se prenda a regras, adapte-se

Queremos engenheiros capazes de enxergar e resolver os problemas concretos que vivenciamos e, para isso, a capacidade de adaptação e a criatividade são fundamentais. Geralmente não existirá uma solução de caixinha ou uma metodologia mágica que se encaixe em todos os casos. O bom senso deve prevalecer sobre regras. Adapte-se.

Comunique-se

Nossos engenheiros têm de se comunicar com clareza e frequência expondo dúvidas, problemas e soluções para seus pares, líderes e liderados. Não tenha medo de questionar. Compartilhe conhecimento e descobertas.

Faça, entregue e itere

Não importa o quão perfeito um design de solução possa parecer. A única maneira de saber se funciona é colocá-lo nas mãos dos usuários e ver como eles o usam. Resista ao impulso de adicionar “mais uma feature” e permita que os usuários mostrem o melhor caminho a seguir.

Faça mudanças pequenas, faça-as com frequência

A base do gerenciamento de mudanças na Quero é que pequenas mudanças incrementais que podemos facilmente desfazer têm um risco menor do que códigos grandes e irreversíveis. Lançamentos controlados e graduais que podem ser facilmente revertidos. Além disso, nos permitem encontrar e corrigir problemas antes que se tornem grandes aborrecimentos para muitas pessoas. Em outras palavras, evite lançamentos do tipo “pacotão de features”.

O débito técnico é uma ferramenta útil

O acúmulo consciente e cuidadoso do débito técnico pode ser uma ferramenta poderosa que nos permite lançar o que estamos construindo mais rapidamente. Assim como com a dívida financeira, sabemos que precisamos recompensá-la ao longo do tempo. Se o débito técnico virou realidade, pague-o o mais rápido possível.

Se você não conseguir mostrar que é um gargalo, não o otimize

A correção é quase sempre mais importante do que o desempenho. Como a otimização geralmente aumenta a complexidade do código, vá atrás apenas do desempenho quando tiver certeza de que um programa funciona corretamente. A telemetria e o uso de profiling (APMs) são as únicas maneiras seguras de saber onde estão os gargalos: a intuição costuma ser enganosa.

Resolver problemas na raiz

Ter uma compreensão coletiva clara do nosso domínio e do nosso código é fundamental para a criação de sistemas de alta qualidade que não quebram e que permanecem tão fáceis de mudar em 10 anos como são hoje. Quebre os problemas em seus menores átomos e entenda-os profundamente.

Não aceite “comportamento estranho” do sistema

Quando um sistema exibe repetidamente um comportamento que não conseguimos explicar, é fácil nos acostumarmos coletivamente a ele e tratá-lo como “normal”. Essa é uma armadilha incrivelmente perigosa que precisamos ajudar uns aos outros a lutar contra. Aproveite o tempo para investigar e entender o problema.

Escreva código para ser lido

O melhor código é aquele que transforma ideias complexas em algo conciso e fácil de entender. Quando você revisa as PRs de seus colegas, lembre-se que, se o código é difícil de entender, provavelmente é muito complexo. Código complexo é um terreno fértil para bugs difíceis de encontrar.

Desbloqueie os outros sempre que puder

Se alguém estiver preso, ajudá-los é um uso incrivelmente valioso do seu tempo. Espalhe conhecimento e habilidades para todos. Se alguém estiver esperando por você para uma revisão de código, priorize-o antes de escrever um novo código.

Invista na documentação

Facilite a comunicação assíncrona do seu time e dos demais times da empresa. Você não pode ser o conhecedor de todas as regras do domínio da aplicação. Não se coloque como um gargalo, seja um multiplicador de conhecimento. Documentar deve ser tão importante quanto a escrita de um bom código.

Melhore o codebase

Qualquer engenheiro pode propor uma alteração em qualquer parte de nossa base de código. É papel da engenharia melhorar o que não está tão claro e óbvio.

Quer saber como nosso time de Engenharia trabalho de perto? Conheça nossas vagas.