Lately houve muita conversa no twitter sobre o engenheiro 10x que começou um grande debate sobre o que faz um bom engenheiro. Algumas coisas realmente estúpidas foram mencionadas como “10x engineers hate meetings” e “10x engineers come late to the office” e “10x engineers laptop background is usually black”. Em geral, parece que algumas pessoas pensam que se você for esperto o suficiente, não faz mal ser um idiota.
Em Wix tentamos deixar os idiotas do lado de fora da porta. Acreditamos que engenheiros 10x não são apenas pessoas que podem produzir 10x mais rápido do que a maioria das pessoas, ainda mais, são pessoas que podem fazer toda uma equipe 10x melhor, tendo uma influência positiva sobre qualquer pessoa com quem trabalhem.
Muitas pessoas passam uma grande parte da sua carreira em se tornar o que pensamos ser um engenheiro decente. Isso significa que você é um bom programador, que pode resolver problemas e fluente em como usar as ferramentas que estão à sua disposição como IDE, debugger, serviços e frameworks. Este artigo tenta descrever o que nós, na Wix Engineering, acreditamos que torna um engenheiro decente em um engenheiro 10x.
Uma das capacidades mais importantes de um engenheiro é ser capaz de trabalhar de forma independente. Em poucas palavras, isto significa saber sempre o que precisa de fazer e raramente estar numa situação em que se espera que alguém lhe diga o que deve fazer. Isso não significa que você é capaz de fazer tudo sozinho, significa apenas que você sabe como desbloquear a si mesmo e como desbloquear os outros na sua equipe de uma forma limpa que cria uma dívida técnica mínima. Por exemplo, se você for bloqueado por algum problema, você encontrará uma solução para ele, seja obtendo ajuda de seus pares ou resolvendo-o por conta própria. Engenheiros independentes têm a capacidade de levar um projeto da idéia à produção através de todas as suas fases. Eles são capazes de definir quais são as coisas que eles precisam para poder realizar uma tarefa e eles sabem quando levantar uma bandeira se eles precisam de assistência.
Planeamento
A coisa mais difícil que você vê engenheiros menos experientes lutando é ser capaz de pegar uma grande tarefa e dividi-la em passos menores. Isto é importante não só para que possamos estimar quanto tempo algo leva, mas também é uma parte crítica da construção de software de alta qualidade. O planejamento correto significa que o desenvolvedor pode lançar a versão inicial do produto o mais cedo possível e começar a receber feedback mais cedo. Planejar corretamente significa que você tem um projeto do sistema o mais cedo possível e tem uma boa imagem do que você vai fazer antes de pular na água. Planejar corretamente significa que não há grandes surpresas que quebram o seu design enquanto você desenvolve. Um bom engenheiro deve ser capaz de quebrar uma tarefa, definir o design e as fases de lançamento e fornecer documentos de design e estimativas para mostrar seu plano.
Humilidade
Esta é uma tarefa difícil. Mesmo os engenheiros mais fortes muitas vezes têm lugar para crescer quando se trata de humildade. Isso significa não estar apaixonado pelas suas próprias soluções. Ser capaz de ouvir e aceitar as soluções de outras pessoas. Assumir o melhor de seus pares e quando você vê algo que aparece como um erro, tente entender o raciocínio que está por trás disso. Abra as coisas para discussão. Deixe as pessoas sugerirem as suas próprias soluções. Partilhe as suas ideias e nunca se preocupe em obter créditos por elas. É mais importante que todos se sintam à vontade com uma ideia e sintam que foi um esforço de equipa do que todos sabendo que a ideia foi sua. Seja honesto. Dê crédito às pessoas. Nunca tenha medo de dizer que você estava errado ou de reconhecer que outra pessoa está certa. As pessoas respeitam as pessoas que podem mudar de opinião.
Reusar
Pode parecer trivial, mas a maioria das pessoas não entende que a melhor maneira de progredir é construir sobre o trabalho anterior. Engenheiros menos experientes têm sempre o mau hábito de pensar que a melhor maneira de avançar rapidamente é ignorar tudo o que já existe e começar de novo. Bons engenheiros sempre olham para cima, aprendem, perguntam e compreendem todas as soluções existentes já disponíveis. Mesmo que falte uma solução existente, eles vão tentar ver como melhorá-la antes de decidirem substituí-la. Eles nunca irão descartar uma solução existente sem olhar profundamente para ela e sem falar com o proprietário da solução existente.
Mentalidade da infra-estrutura
Como descrito acima, reutilizar trabalho anterior pode ter um enorme impacto nas pessoas. Isso significa que os engenheiros devem estar sempre atentos para ver se eles têm a oportunidade de criar algo reutilizável. A coisa mais fácil de se fazer quando se tem tal oportunidade é ignorá-la. Fazer coisas reutilizáveis custa sempre mais ao “fabricante” do que fazê-las não reutilizáveis, por isso muitas pessoas de vistas curtas ignoram os benefícios que eles e outras equipas irão colher no caminho. Um bom desenvolvedor identificará as oportunidades de criar coisas reutilizáveis, saberá como torná-las reutilizáveis da melhor maneira, e investirá o esforço para fazê-lo.
Masterizar seu domínio
A única maneira de chegar a boas soluções é compreender completamente o produto em que você está trabalhando. Os bons engenheiros não só têm uma compreensão profunda do produto que desenvolvem. Eles também entendem todos os casos de uso, entendem a motivação para o produto e podem facilmente ter uma conversa significativa com o gerente do produto, desafiar decisões e oferecer alternativas. Eles sabem quais são as características importantes e quais são as coisas menos importantes e sabem como priorizar de acordo com isso e oferecer soluções quando necessário. Isto é importante não só para o produto em que você trabalha, mas também para qualquer produto que você integra.
Curiosidade
Os desenvolvedores de produtos devem ter uma curiosidade saudável que se estenda muito além dos limites do seu domínio. Isto é especialmente verdadeiro para aprender como as tecnologias subjacentes realmente funcionam, mas é igualmente importante compreender os produtos em que outras equipes estão trabalhando, sua arquitetura e como eles se conectam como um sistema completo. Ter este contexto mais amplo pode ser inestimável na resolução de problemas complexos e uma fonte de inspiração.
Sem fronteiras
Vemos frequentemente que a fonte das más soluções e da má arquitectura está enraizada no medo de mudar coisas que estão fora dos limites da sua caixa. O desenvolvedor do cliente tende a resolver as coisas no cliente, mesmo que seja melhor resolvê-las no servidor. O desenvolvedor de aplicações tenderá a resolver o problema localmente, mesmo que a solução pertença à plataforma ou à infraestrutura. A razão para isto é simples. É mais fácil não criar discussões com uma equipe diferente, é mais fácil tratar o mundo além do seu alcance como uma caixa preta, é mais fácil lidar com o diabo que você conhece. Mas bons engenheiros devem saber que eles fazem parte de um grande sistema e que nenhuma parte do sistema está realmente fora do seu alcance. Discutir mudanças de arquitetura com uma equipe diferente é saudável e útil e pode acrescentar à sua perspectiva. Oferecer-se para contribuir com a mudança que você precisa é ótimo para construir confiança entre as equipes. Tocar um novo domínio é uma experiência da qual você só pode se beneficiar. Mais importante, quando os seus limites se tornam mais flexíveis, isso significa que o seu impacto cresce. Sempre que você evitar chegar fora dos seus limites, perceba que o que você está realmente fazendo é se impedir de ter um impacto maior.
Responsabilidade / propriedade
Embora não seja imediatamente aparente, muitas vezes se você se aprofundar na causa raiz do porquê de algum projeto ter sido atrasado ou falhado, você vai descobrir que se resume à propriedade e responsabilidade. As pessoas tenderão sempre a culpar o que as rodeia: “Eu precisava esperar por outra equipe para completar algo”, “Eu tinha um problema no sistema e ninguém tinha tempo para me ajudar”, “Eu recebi definições tarde demais”. Um bom engenheiro sabe que essas coisas são quase sempre desculpas. Quando você é o dono da tarefa e a responsabilidade de fazê-la acontecer está em você, sua mentalidade deve ser que cada problema que você encontra é algo que você precisa resolver. Se você estiver bloqueado por outra equipe, vá e fale com eles. Ofereça-se para formar pares sobre o problema e não “jogue” a responsabilidade sobre outra pessoa. Se você ainda não recebeu definições, faça algumas suposições sobre quais serão as definições. É melhor fazer alguns progressos e mais tarde fazer ajustes, do que apenas sentar e esperar. Se algo grande está atrasando você, saiba quando levantar a bandeira e saiba como contornar a questão para que pelo menos você possa fazer progressos em uma frente diferente. Nunca esteja numa situação em que alguém seja responsável por resolver seu problema, é o contrário – você é responsável por chegar à linha de chegada e precisa lidar com obstáculos no caminho.
Comunicação
Esta é uma verdadeira mudança de jogo e muitas vezes a coisa mais crítica a ter para um engenheiro ser capaz de ter um enorme impacto em toda a equipe. Ser capaz de comunicar é a única coisa maior que permitiu à humanidade tornar-se o que é, obviamente a mesma coisa é tão crítica para qualquer aspecto da vida, incluindo a engenharia de software. Bons engenheiros devem ser capazes de explicar suas idéias e opiniões de forma eloquente. Eles devem ser capazes de debater de forma inteligente e respeitosa com seus pares. A comunicação não é apenas falar, é ainda mais importante ser capaz de ouvir. Nem todos na equipe serão capazes de expressar suas idéias também e um bom engenheiro deve ser paciente e fazer as perguntas certas para entender o que as outras pessoas estão pensando e ajudá-las a serem ouvidas. Tudo isso é igualmente importante para a comunicação verbal e escrita e, mais importante ainda, não é apenas conversar – a vida dos desenvolvedores está cheia de toneladas de formas de comunicação: documentos, apresentações, documentação, comentários em código, mensagens de compromisso. Mesmo escrever código legível e escolher bons nomes de variáveis é uma forma de comunicação.
Teamwork
Este é um dos lugares onde até engenheiros experientes falham com muita frequência e nem sequer sabem que isso está acontecendo. Pense em todas as vezes que você disse “é muito complicado, deixe comigo”. Pense nas vezes em que você disse “esta tarefa é um trabalho de uma só pessoa, adicionar mais pessoas não vai facilitar”. Pense em todas as vezes que você não teve tempo de ajudar outra pessoa e nunca deu seguimento, ou você corrigiu/refez o código de alguém sem pedir sua revisão, ou você fez uma grande mudança sem consultar sua equipe. Há toneladas de exemplos. E o problema é que, mesmo para engenheiros experientes, isso parece ser a coisa certa a fazer no momento. Mas isto é um pensamento táctico que só compensa a curto prazo. Se queremos alcançar grandes coisas, temos de nos certificar de que podemos colaborar como uma equipe. Não é coincidência que o trabalho em equipe tenha vindo logo após a comunicação. Essas são as coisas que nos fazem mais eficazes, é a biologia básica. Os grandes engenheiros não só colaboram, consultam, aprendem, ajudam, emparelham e respeitam seus pares, como também orientam, apontam problemas, encontram interesse e aprendem com tudo o que acontece na equipe e proativamente tentam ser úteis mesmo para coisas que não lhes dizem respeito diretamente. Engenheiros incríveis sabem quando e como criar projetos que tornarão mais fácil para muitas pessoas colaborar em coisas onde se espera muito trabalho.
Calma a simplicidade
A complexidade de uma solução pode ser um dos assassinos silenciosos da capacidade da equipe de seguir em frente e se adaptar. É como uma pressão sanguínea alta. Para o olho destreinado parece que tudo está bem e tudo está funcionando como esperado, mas na verdade, lá no fundo, algo que não afeta diretamente nenhuma funcionalidade principal está lentamente matando você. Bons engenheiros criam soluções pragmáticas e códigos legíveis, mesmo que você escreva mais linhas de código. Não mostre quão “inteligente” você é usando todas as capacidades da linguagem, criando níveis redundantes de abstração, ou escrevendo uma função em uma linha que ninguém mais pode entender ou depurar. Não seja um purista, não seja um super-engenheiro de soluções onde não é absolutamente necessário e nunca tenha medo de pegar algo que já é complexo e tentar simplificá-lo.
Prioritizing
Não podemos fazer tudo. Não podemos resolver todos os problemas. Não podemos ganhar todos os debates. Não podemos fazer tudo perfeito. Temos tempo limitado e recursos limitados e devemos usá-los sabiamente. Isso significa que devemos ser capazes de distinguir entre o que precisamos insistir em fazer, o que podemos adiar, e o que devemos ignorar. Os desenvolvedores fazem essas decisões dezenas de vezes todos os dias. Quando consideramos se devemos investigar um bug, quando consideramos fazer algum refactor, quando consideramos lidar com algum caso de uso ou caso de borda, quando consideramos fazer um desvio da nossa tarefa planeada e mesmo quando investimos tempo em convencer alguém na nossa opinião. Bons engenheiros sabem ser implacáveis em consertar, investigar, pesquisar ou insistir em fazer o seu ponto de vista para as coisas que são realmente importantes. Eles sabem tomar uma nota e voltar a algo mais tarde se for importante mas não urgente. E eles sabem deixar algo em paz ou aceitar a opinião de outra pessoa mesmo que estejam descontentes com isso quando não é realmente tão importante.
Gestão do tempo
Como mencionado acima, a triste verdade da nossa existência é que estamos presos pelo tempo. Os produtos que desenvolvemos acabam por precisar de entrar em funcionamento, temos prazos e estimativas e metas a atingir. Os bons desenvolvedores devem desenvolver não apenas uma intuição para estimar quanto tempo suas tarefas levam, mas também precisam ser inteligentes sobre como elas se decompõem e ordenar suas tarefas para partes ainda menores. Eles precisam gerenciar suas interrupções e mudanças de contexto de forma sensata. Esta intuição de estimar o tempo é uma parte inseparável da capacidade de estabelecer prioridades, como descrito acima. Por exemplo, se algo é suficientemente curto, pode valer a pena fazer, mesmo que não seja super importante. E se for muito longo, pode ser melhor adiar um pouco ou consultar seus pares ou gerente.
Conclusion
Como mencionado anteriormente, acreditamos que os engenheiros que são especialistas em todos os itens acima podem tornar a equipe 10x melhor, influenciando e inspirando seus pares. Grandes engenheiros devem sempre lembrar que isso faz parte do seu trabalho diário: influenciar e inspirar. Isso significa que você deve encontrar tempo não só para fazer o seu trabalho, mas também para ajudar os outros a fazer o seu trabalho. Isto vem de muitas formas: mentorar as pessoas da sua equipa, criar recursos para educar as pessoas, certificar-se de que tudo está bem documentado, estar sempre aberto para explicar e formar pares com as pessoas e muito mais. Ser um bom mentor e educador significa que você não só ajuda os membros de sua equipe a crescer, mas também aprofunda sua compreensão de tudo o que você faz e lhe dá uma nova perspectiva sobre a clareza das coisas, a complexidade do sistema e os lugares onde as coisas podem melhorar.
Estas são as criações dos 10x engenheiros, não só em seu impacto individual, mas também em seu impacto sobre todos os outros. Sempre se pergunte o que você pode fazer para aumentar seu impacto, há sempre mais espaço para crescer.