Cinco opiniões que mantive, soltei e peguei como construtor de software e líder

1. Os idiomas digitados são melhores. Na minha vida profissional, escrevi muito código em Python e Java. Eu gostaria de ter obtido tipos mais tarde em todos os projetos que começaram como um pequeno script Python. Os refatores se tornam muito mais fáceis com eles. Você precisa de menos testes. Com centenas de pessoas contribuindo, grandes bases de código são uma bagunça sem tipos. É por isso que o Shopify escreveu Sorbet; A Meta investiu o tempo de engenharia na verificação do tipo de Python, a Microsoft criou o TypeScript, etc. Tudo isso tem algo em comum. À medida que as bases de código crescem, os tipos são uma das ferramentas mais valiosas para a refatoração. Mesmo se você começar com um idioma do tipo pato, você percebe mais tarde.
2. Os gerentes de engenharia devem ser técnicos. Em muitos casos, os brilhantes colaboradores individuais (ICs) são “promovidos” em funções de gerenciamento apenas para falhar espetacularmente. Às vezes, isso se deve a uma carreira de CI inexistente. Em outros casos, outros líderes os pressionam devido a circunstâncias. No entanto, os engenheiros de software anteriores foram os EMs de maior sucesso com quem trabalhei. Também trabalhei com uma quantidade razoável de EMs não técnicos. A maioria eram ótimos gerentes de projeto que mantiveram sua equipe unida ou razoavelmente felizes, pelo menos por um tempo. Se você não entende a tecnologia o suficiente, está à mercê daqueles que o fazem. É que complicado? Minha equipe está seguindo bons padrões do setor? As últimas tendências são verdadeiras ou apenas hype? Às vezes, você pode obter as respostas corretas fazendo boas perguntas de acompanhamento, medindo as coisas certas ou tendo uma lista de verificação. Mas isso não sobrevive ao teste do tempo.
3. A implantação contínua é fundamental para equipes de alto desempenho. Eu escrevi sobre isso há dez anos. Testes, automação e integração continuamente/implantação de software é o caminho a percorrer. Ter boas funções de forçamento para manter suas iterações pequenas, usando sinalizadores de recursos e enviando diariamente. Se você fizer isso de forma consistente, ninguém perguntará, “Quanto será necessário construir X?”. Eles sabem que você enviará a primeira versão em breve porque entrega pequenos pedaços, mede e aprimora. Nenhum grande engenheiro quer esperar horas para que sua construção termine e dois dias antes que seu código possa chegar à produção.
4. Escrever é uma superpotência. Condensando pensamentos em um documento, iterando -o e distribuindo -o com custo marginal zero faz maravilhas para você, sua equipe e sua empresa. Às vezes, escrever é suficiente para eu descartar uma idéia e itera sobre ela. Em algum momento, você pode apenas ligar de volta ao documento. Exemplos:
   1. P: “Como abordamos promoções depois ? “. A:” Você recebeu o documento que nossa equipe de liderança escreveu no ano passado e podemos começar a partir daí “.
   2. P: “Por que você está trabalhando ? “. A:” Porque se relaciona diretamente à nossa estratégia. Aqui está o documento “.
5. A contratação de QAS é disfuncionalcomo eu já expliquei antes. Em geral, você deve investir em bons processos de automação e observabilidade. Contrate engenheiros de software com espírito de produto e entendam seus usuários. Corrija seus problemas organizacionais antes de jogar controle de qualidade neles.

1. Scala é a melhor linguagem JVM. Depois de todo o drama de Scala 2-3, eles até viram a dor de Python, pelo amor de Deus! – e Jetbrains polindo Kotlin, sendo pragmático, fica claro que Scala perdeu o caminho de ser um “melhor java”. Uma grande parte da comunidade se esforça para escrever um “Haskell para a JVM”, o que quer que isso signifique.
2. Os prazos são ruins. Eles criam restrições que permitem que os engenheiros mostrem sua criatividade. Os prazos são ótimos porque atacam excessos e complexidade. Eles dão às equipes um objetivo, criando um ciclo virtuoso de entrega, impacto e felicidade.
3. Invista tempo em tarefas de grão fina para evitar bloqueadores. Embora isso seja frequentemente uma queixa que os desenvolvedores fazem, faz mais mal do que bem. Se você for tarefas de granulação fina antes de aceitar esse trabalho, terá um alvo em movimento: talvez alterações de contexto ou mudança de requisitos. Ao mesmo tempo, se você investir e passar pelo código, modelo de dados e arquitetura para fazer valer a pena, por que não fazê -lo imediatamente? Os melhores desenvolvedores com quem trabalhei preferiram a autonomia para entender o escopo e o por que atrás de uma necessidade. Em seguida, invente um plano e discuta trade-offs para enviar as coisas. Isso cria uma função forçante para resolver o problema certo com a quantidade certa de engenharia.
4. Cobertura de teste, testes de unidade e pirâmide de teste não são negociáveis. Enquanto os testes de unidade fornecem valor, eles geralmente confundem o comportamento com os internos. Portanto, você acaba com uma suíte de teste super grande que, em todos os refatores, também precisa refatorar. Eu ainda os manteria para a lógica principal de negócios. Fora isso, eu favoreceria mais testes de integração – zombando da camada de dados ou usando o Docker – que são rápidos hoje em dia. Eu removeria completamente os testes de ponta a ponta e favoreceria o uso de sinalizadores de recursos, lançamentos progressivos e boa observabilidade.
5. Você deve ter um ambiente de pré -produção, assim como a produção. É preciso uma quantidade não trivial de engenharia para alcançar algo assim. Você deve manter dois sistemas em geral para seus usuários e equipes de desenvolvimento, mesmo quando o faz. Sempre que eu via uma equipe lutando contra a implantação de “todos os microsserviços” em um ambiente de pré-produção (problemas de versão n x m) ou criando processos de ETL para ter dados semelhantes à produção, tornou-se um trabalho em tempo integral mantê-lo. Por favor, verifique minha postagem sobre desastres que já vi nos microsserviços.

1. O suporte é crítico para equipes de plataforma interna. Se sua equipe criar qualquer coisa como um serviço -Um componente de bate-papo, Kubernetes, Kafka como serviço etc.-Dar grande apoio é o seu ingresso para ser considerado amigável e confiável. Essas são duas características principais, se você deseja influenciar como outras equipes criam e enviam software.
2. Dê apoio exatamente onde as pessoas estão. Se as pessoas fazem uma pergunta no Slack, você primeiro perguntar: “Você pode criar um ingresso para mim?” Você está colocando o processo na frente do usuário com as mesmas informações que eles já lhe deram. Faça por eles ou automatize -o para longe. Isso, emparelhado com o número 1, mostra o centrismo do usuário e você recebe usuários felizes. Devo agradecer a Alex Moleiro por esses dois aprendizados.
3. O envio constrói impulso. Reclamar cria desconfiança. Sempre que vi os engenheiros chegarem a uma equipe e começarem a enviar desde o dia zero, ele criou impulso para eles. Após a observação, eles conseguiram a confiança para compartilhar melhorias com o restante da equipe. Freqüentemente, essas melhorias não foram apenas discussões filosóficas, mas implementações reais, com pequenos passos. Por outro lado, quando vi os engenheiros reclamarem de como a dívida tecnológica não era sustentável e como tudo foi quebrado sem o envio a tempo, explorando e apresentando alternativas, a equipe ficou avessa a essa pessoa.
4. As equipes de infraestrutura devem aliviar as migrações o máximo possível. Este pode ser um pouco controverso. Já vi muitas equipes de infraestrutura dizer para mais de 50 equipes de desenvolvimento: “Ei, você precisa migrar de A para B. O prazo está em três meses”. Em seguida, outra equipe de infraestrutura vem com outra migração, linha do tempo etc. Aproveitar as interfaces certas, criar automação e mover equipes sem problemas em toda a infraestrutura é essencial para as migrações bem -sucedidas. Sempre que havia um link para um documento de três páginas e um prazo, a migração levava muito mais tempo e esforço e gerava mais frustração.
5. Documentos de gabar -se são melhores que o seu processo de revisão de desempenho. Os engenheiros são ótimos em fazer as coisas e, mais frequentemente do que gostaríamos de admitir, eles não estão interessados em falar sobre o impacto do que fazem. Então, quando a revisão de desempenho chegar, eles acham que uma promoção acontecerá magicamente. O processo usual de revisão de desempenho é baseado no feedback dos colegas com perguntas genéricas sobre “O que estou fazendo bem? O que posso melhorar?” levando a elogios estéreis e a nenhuma ação nas áreas de desenvolvimento. Por que os documentos do Brag são tão bons?
   1. Eles o forçam a Considere seu impacto e se esse refator teve um ROI positivo. Se você falar sobre economia de custos, quanto você economizou? Você pesou isso em relação ao custo de oportunidade? O que você aproveitou do trabalho de outras pessoas? O que os outros foram aproveitados da sua?
   2. Eles criam uma estrutura para o seu gerente e colegas fornecer feedback preciso sobre uma situação ou impacto específico. Isso leva a melhores negociações de desenvolvimento do que fazer perguntas genéricas.

Quais opiniões resistiram ao teste do tempo para você? Onde você mudou de idéia? E que lições reformularam como você constrói, lidera ou decide? Eu ficaria curioso para ouvir.