Carreira: Escreva menos código. Faça mais engenharia.

Arte por José Domingo — https://itsdomingo.com/

Um texto sobre impacto ao invés de quantidade.

Equipes eficazes escrevem menos software, e escrever menos software permite que as equipes sejam mais eficazes. Isso pode parecer contra-intuitivo no começo: não estamos todos aqui como engenheiros para escrever software? Nossa produtividade não é medida em linhas de código? Para dissipar essa ilusão, precisamos parar de confundir o que às vezes fazemos com o porquê.

Como engenheiros, projetamos e construímos soluções para os problemas que nossos negócios enfrentam. Escrever nosso próprio código costuma fazer parte da resposta. Mas, assim como não insistiríamos em que cada ponte fosse construída com vigas e parafusos sob medida, ou que todos os plugues e tomadas elétricas tivessem seus próprios fatores de forma, não devemos insistir na construção personalizada de todas as partes dos projetos que criamos. Ao invés disso, devemos concentrar a energia finita de nossas equipes nos locais em que eles podem oferecer um valor único. Se recompensarmos equipes e indivíduos por reinventar a roda, e não pela reutilização inteligente dos componentes existentes, estamos nos dedicando a esforços artesanais caros, ao invés de plataformas compartilhadas eficientes.

Construa o necessário, compre o que puder e documente tudo

Quando estamos construindo algo novo, nosso trabalho começa com o mapeamento de uma estratégia geral, com o entendimento do contexto e das necessidades do negócio e as partes que devemos criar nós mesmos. À medida que o projeto avança, identificamos vendedores e fornecedores apropriados para peças que consideramos mais eficientes comprar do que construir a partir do zero. O trabalho termina com a integração de todos esses componentes em soluções para nossos clientes. E como a engenharia é um processo contínuo e não único, devemos documentar nossas decisões para manutenção futura e compartilhar o que aprendemos em nossas organizações e comunidades.

Os Mapas de Wardley, por Simon Wardley, demonstram que é importante considerar a disponibilidade comercial do componente de que precisamos e onde ele se encaixa na cadeia de valor entre outros componentes intermediários e o usuário final. Se algo é um commodity com uma interface comum, como armazenamento de arquivos blob ou eletricidade, eles podem ser oferecidos por vários fornecedores com base no preço e na conveniência. Se o componente for padronizado o suficiente para ser montado a partir de produtos existentes, talvez possamos adaptá-los e fazer apenas pequenas modificações ou adicionar nossa própria cola no meio. Somente se um componente não existir no mercado, ou se criá-lo renderia uma vantagem competitiva única, devemos recorrer ao trabalho personalizado.

Para entender quais componentes podemos precisar e como montá-los, o primeiro passo é reunir requisitos sobre o problema que enfrentamos hoje e até que ponto a solução deve ser dimensionada. Isso nos permite identificar quais peças são únicas ao invés de commodities e quais peças devem ser concluídas o mais rápido possível para começar a agregar valor. Para projetos de plataforma e infraestrutura, em particular, é essencial falar com as equipes que irão usar a infraestrutura. Desconexão entre as equipes que projetam ferramentas e as equipes que as utilizam, é um desperdiço de inovação. Plataformas e ferramentas internas precisam de gerentes de produto e developer advocates para garantir que o software atenda às necessidades dos usuários e sejam adotados com entusiasmo, ao invés de serem abandonados na estrada.

A otimização prematura em um conjunto errado de requisitos, artificialmente nos restringe em nossas opções. Obviamente, você concluirá que precisa de seu próprio software se insistir que seu produto precisa suportar trilhões de transações de blockchain, com 10 milissegundos de latência, no espaço interestelar! Aplique restrições de design suficientes para resolver seu problema imediato e também para se preparar para onde você espera estar dentro de um ano. Ao longo do caminho, anote as alternativas que você considerou e por que não as escolheu. Você pode economizar tempo para outra pessoa - ou até para você mesmo - durante uma avaliação futura de quais peças de design revisitar.

Foque no impacto, não na quantidade

Os incentivos são importantes, assim como o tom que a liderança leva. Foque em recompensar sua equipe pelo impacto que eles alcançaram em relação aos recursos, presentes e futuros, que eles gastaram. Ao invés de torcer pelos engenheiros para projetar componentes novos ou para escrever um certo número de linhas de código, diminua o zoom e foque no impacto de seus funcionários.

Quais são as lendas dentro sua equipe? "Antes de eu aparecer, o cliente X precisava gastar 30 minutos por dia inserindo manualmente pedidos de clientes de uma planilha no sistema de pedidos, mas depois de fazer a coleta de requisitos, percebemos que a maioria das planilhas podia ser automaticamente analisada e verificada as exceções. Agora, o cliente X pode se concentrar apenas nos casos mais importantes - precisávamos apenas escrever as regras personalizadas de validação de dados, ao invés de escrever uma análise inteira de CSV que tínhamos que manter!". Formular as realizações da sua equipe para articular o valor comercial e as compensações permitem recompensar mais facilmente os membros da equipe pela engenharia estratégica, ao invés de ataques táticos.

A plataforma de mensagens Intercom transformou um mantra em "Execute menos software", permitindo que eles concentrem suas centenas de engenheiros em locais onde agregam mais valor, ao invés de trabalho pesado indiferenciado. Sua liderança reconheceu que toda linha de código escrita internamente requer cuidados, alimentação e suporte contínuos. Quanto mais as coisas puderem ser terceirizadas para os fornecedores, menos equipes internas terão que fazer elas mesmas.

Quando qualquer equipe decide escrever seu próprio código, é essencial implementar um plano de manutenção de longo prazo para o próprio código, bem como uma estratégia de produto. Richard Bondi e Max Luebbe, do Google, em suas conversas no SREc nas Américas , enfatizam que, sem um objetivo e estratégia claros, as contribuições dispersas dos usuários a uma base de código irão sobrecarregá-lo com dívidas técnicas. Essa dívida geralmente se manifesta em amplos conjuntos de recursos, propriedade obscura ou até bugs assustadores que se manifestam longe do código que os engenheiros estão modificando.

Compartilhe o que você faz e como você o fez

Se você identificou uma lacuna no mercado ou um componente ausente que fez com que você escrevesse algo próprio, há um valor em abrir o código do seu trabalho. E quando você compartilhar sua tecnologia, compartilhe também os padrões e motivações de design, para que outras pessoas possam entender se é adequado para o caso de uso e para que possam contribuir facilmente. A menos que o software que você escreveu seja uma vantagem competitiva crítica, o compartilhamento permite que outros beneficiem e participem de sua manutenção.

E o compartilhamento de código vai além do código aberto tradicional. Em empresas maiores, os esforços de equipes individuais podem duplicar o trabalho já realizado em outras partes da empresa - curadoria de "fornecimento interno" e esforços de engenharia de plataforma centralizados são necessários. A reutilização da tecnologia de outras pessoas é recompensada? Se sua empresa não possui conversas técnicas internas ou documentação e repositórios de soluções compartilhadas, considere em ter. Examine como os funcionários aprendem sobre a inovação que acontece nas outras linhas de negócios da empresa. E contrate mais escritores técnicos para atuar como bibliotecários de seus bens

Seja interno ou externo, o compartilhamento também é uma responsabilidade. A máxima "não recompense complexidade desnecessária" não se aplica apenas às empresas, mas também às nossas comunidades (só porque algo é uma publicação popular no Hacker News não significa que é a coisa certa a ser adotada pela sua equipe ou empresa). Não despeje hacks. E, acima de tudo, não cultive comunidades tóxicas que não possuem códigos de conduta e estão cheias de conflitos.

O desenvolvimento de software sob medida deve ser seu último, e não o primeiro, recurso. Precisamos cultivar nossas equipes e empresas para recompensar o impacto da reutilização de código, ao invés de um desenvolvimento direcionados a currículo. Escreva menos código. Faça mais engenharia.

Créditos

• Code less, engineer more, escrito originalmente por Liz Fong-Jones.