7,734 leituras

Como me tornei um desenvolvedor 100x - como júnior

por picocreator9m2023/01/03

Muito longo; Para ler

O desenvolvedor 10x/rockstar é um mito. Viva o desenvolvedor situacional 100x! Aprenda como aumentar suas chances de se tornar um desenvolvedor situacional 100x.

featured image - Como me tornei um desenvolvedor 100x - como júnior

A ideia de um desenvolvedor 10x, ou um desenvolvedor rockstar, ser melhor do que qualquer outro desenvolvedor em tudo, é um mito.

Em vez disso, você deve se esforçar para ser um desenvolvedor 100x em situações muito específicas, um desenvolvedor 10x em algumas e um desenvolvedor 1x no maior número possível. É importante estar ciente das áreas em que você se destaca e das áreas nas quais você pode precisar trabalhar.

A menos que você trabalhe para uma grande empresa de tecnologia, é provável que você esteja usando vários chapéus. Diariamente, você precisará alternar entre front-end, back-end e desenvolvimento de linguagem específica, como Java ou TypeScript. Isso se deve à natureza em constante mudança de nossa indústria e ao grande número de maneiras de realizar as mesmas tarefas - como imprimir “Hello World” em mais de 400 linguagens de programação diferentes.

É impossível ser bom em tudo, mas é possível ser ótimo em alguma coisa.

Para elaborar, gostaria de compartilhar uma história de mais de uma década atrás, que foi um momento de mudança de vida que teve um grande impacto em minha carreira.

Como me tornei um desenvolvedor 100x - como um júnior

Trabalhei com uma grande multinacional e fazia parte de uma equipe que lutava para atender à demanda.

Eles criaram um aplicativo da Web Java personalizado que milhares de funcionários usavam diariamente, mas à medida que o número de registros entrava e saía dos servidores SQL aumentava. As coisas estavam ficando mais lentas. Eles já haviam atualizado o servidor SQL até seus limites e precisavam de novas soluções. Uma óbvia era usar o memcache para armazenar em cache alguns dos resultados.

Infelizmente, o memcache foi banido devido a alguns incidentes de segurança no passado e à falta de HA. Os gerentes tentaram obter aprovação para o memcache por mais de um ano, mas não conseguiram. Enquanto isso, os desenvolvedores travaram uma batalha difícil, pois cada melhoria de 10% era negada pelo dobro do crescimento do usuário.

Foi aqui que entrei e entrei.

Eu não tinha ideia sobre o último ano de luta deles e fui contratado como desenvolvedor júnior para ajudar a fazer algumas pequenas melhorias na interface do usuário, enquanto os seniores se concentravam no desempenho.

No entanto, fiquei muito irritado com o desempenho lento do servidor de desenvolvimento. E eu estava jogando com o Hazelcast - uma nova biblioteca de clustering e cache de servidor baseada em Java.

Usei-o como uma alternativa ao memcache. E conseguiu executá-lo no aplicativo, que não tinha restrições especiais ou requisitos especiais de aprovação, que matou todas as soluções anteriores.

E tinha um protótipo funcional com uma demonstração pronta na mesma semana. Para uma página na plataforma, as chamadas de API passaram de mais de 10 segundos para menos de um segundo. Foi uma virada de jogo.

Toda a equipe aderiu e, em um mês, tínhamos uma "solução de clustering que definitivamente não é memcache" em produção.

Enquanto meu gerente de equipe e seu chefe ofereciam um banquete a todos, meu gerente me disse que, quando ele me trouxe a bordo como um garoto inteligente, nunca esperou que eu fosse um programador 10x ou 100x que poderia resolver seus problemas da noite para o dia.

E essa afirmação me atingiu profundamente.

Porque eu era um impostor – nada além de um impostor sortudo.

The Lucky Impostor – Quem era um desenvolvedor 0.1x

Tecnicamente, eu não era um desenvolvedor 1x ou mesmo 10x. Eu sabia menos do que meus colegas de equipe e estava aprendendo no trabalho.

Meus colegas podiam fazer o front-end melhor do que eu e a equipe sabia como otimizar o SQL (e me ensinou, obrigado!). Meu maior crédito foi conseguir fazer o equivalente a “npm install milagre” e ler seu manual sobre como configurá-lo.

Em retrospectiva, houve muitos problemas dos quais me esquivei por sorte.

Política (que bloqueou o memcache em primeiro lugar)
Caso de uso (não tínhamos segurança de contenção de gravação, o que significa que se 2 edições acontecerem no mesmo ms, o cache será mal atualizado. Felizmente, isso raramente acontece)
Estabilidade (v1 do hazelcast trava como um louco, felizmente o servidor API foi projetado para ser implantado no modo HA, então isso foi um aborrecimento para a equipe infra)
Segurança (ter uma porta aberta para todos os dados no servidor API em um cluster foi uma má ideia da minha parte e um erro muito jovem até que outro sênior tenha lido os documentos sobre como protegê-lo)
Pilha de linguagem (se o servidor fosse em Python, .NET, C# ou Ruby, eu não teria ideia de como incluir um cache de cluster local)

Tive a sorte de ter um punhado de pôneis de um truque, o que me rendeu 100 vezes nas situações certas. O que só foi possível devido ao trabalho fundamental realizado pelo restante da equipe.

Também tive sorte de meus gerentes e chefes permitirem que eu escolhesse os problemas que queria resolver, pois eles me acompanharam rapidamente e me colocaram em várias equipes para "resolver seus problemas". Enquanto me permite maximizar minha relação sorte-impacto e repetir os “milagres”.

Com a experiência, também percebi o contrário – sou lento no desenvolvimento de front-end. Isso era o que eu deveria fazer originalmente antes de ser acelerado como engenheiro 10x e isso me fez refletir muito ao longo dos anos. Como poderia ter sido o caminho em que eu estaria preso.

Também me ocorreu isso, em retrospectiva, tendo "dominado" o hazelcast e várias outras tecnologias. Quanto teria falhado para outras equipas, mesmo na mesma organização, não fosse a situação única, e salvaguardas, que deveriam ter sido creditadas ao resto da equipa.

Tive sorte, como um júnior, se qualquer outra coisa.

É por isso que os desenvolvedores seniores tendem a ser 10x desenvolvedores juniores

Quando olhamos além das generalizações da engenharia, fica claro que todos têm suas habilidades, que podem variar de 100x a 0,1x.

Ao longo dos anos, conforme passei por muitas equipes e projetos, acabei me tornando um desenvolvedor “sênior”. Durante esse tempo, percebi que os idosos geralmente têm mais habilidades e sabem no que são bons e ruins. Eles podem informar proativamente seus gerentes e priorizar as tarefas de acordo. Isso não significa que eles saibam fazer tudo, mas significa que eles sabem o que não fazer.

Os juniores, por outro lado, lutam com isso, pois não têm experiência para saber no que são bons ou ruins. Não há uma maneira fácil de descobrir isso além de apenas “tentar”.

Uma vez que isso seja compreendido, torna-se evidente que tudo se trata de maximizar o número de coisas que você sabe que pode fazer bem e de forma confiável. Trata-se também de maximizar seu fator de sorte quando se trata de tarefas atribuídas e garantir que você não fique preso a coisas nas quais é ruim.

De certa forma, para os juniores, seu progresso dependerá muito do alinhamento de sua sorte e conjunto de habilidades. Os idosos tinham mais (mas não total) controle sobre como conduzir seu progresso.

Neste caso: A sorte não é binária. Você pode aumentar o número de situações que se alinham com você.

Como maximizar sua sorte de situação em 100x e 10x

Para todos, mas especialmente para os juniores e aqueles que estão começando, a melhor coisa a fazer é continuar tentando coisas novas em tecnologia e explorando. Isso o ajudará a descobrir no que você é bom e no que é ruim.

Para quem tem uma ideia melhor do que é bom, o próximo passo é ampliar o número de situações em que pode dar o seu melhor. Isso envolve alguma prática e pesquisa em tecnologias adjacentes àquelas que eles já conhecem. Depois de se tornar ótimo em algo, certifique-se de possuí-lo para que seus gerentes e chefes saibam que é isso que eles devem lhe dar. Isso aumentará as chances de acertar essas situações 10x ou 100x com mais frequência.

Encontre pelo menos uma coisa em que você seja bom, mesmo que seja uma coisa muito pequena e estreita. Construa a partir daí. (Alguns exemplos notáveis incluem regex e configuração de webpack.)

Para os idosos, se você ainda não o fez, comece a olhar além dos aspectos técnicos do desenvolvimento. Isso não significa que você tenha que passar para a gestão. Mas com seu conhecimento técnico exclusivo, você pode desempenhar um papel mais ativo na compreensão do caso de uso do usuário ou do negócio. Isso permitirá que você otimize com seus gerentes para garantir taxas de sucesso de 10x ou 100x para você e sua equipe.

Para aqueles que estão procurando emprego, se você sabe que é bom em alguma coisa, mesmo que seja 10x, faça algumas pesquisas e se aprofunde em sua busca por emprego. Tente encontrar uma startup ou MNC bem financiada que esteja enfrentando dificuldades exatamente no que você é bom. Embora isso possa ser difícil de realizar e envolva algum networking, se você se colocar no lugar e na hora certa, isso maximizará o impacto para você e para a empresa envolvida.

Estas são todas as coisas que você pode fazer lentamente ao longo do tempo, para melhorar o fator sorte. E proporcione essa experiência 10x mais consistente.

Grito especial para ler o artigo swyx sobre como criar sorte: swyx.io/create-luck

Como CTO e líder de equipe hoje, isso ainda vale - 10x é um mito - todos são 100x e 0,1x

Alguns podem pensar que o CTO de uma ferramenta de teste de interface do usuário, como Uilicious.com , seria bom com tecnologias de front-end. No entanto, isso está longe de ser verdade. Nosso novo contratado médio ou júnior na empresa é normalmente mais rápido do que eu, o CTO, quando se trata de escrever componentes de front-end com estruturas de front-end modernas, como Vue.js ou React.

Isso mudou minha perspectiva como líder/gerente de equipe. Isso me mostrou o quão tóxico e ruim é o mito do engenheiro 10x. É uma simplificação exagerada de rótulos e generalização de situações únicas. É um equívoco tóxico que precisa ser consertado.

Quase todo mito de engenheiro 10x de startup, quando analisado mais profundamente, acaba por ter um indivíduo com conhecimento único no lugar e na hora certa. E foi capaz de evitar as tarefas em que estavam 0,1x.

No meu caso, estava focando na infraestrutura ao invés do desenvolvimento front-end. Em vez disso, tenho outros membros da equipe que são 1000 vezes melhores no desenvolvimento de front-end.

Esta é uma realização importante para um gerente porque, para cada indivíduo que é 100x em uma tarefa, há uma tarefa que os torna 0,1x quando ficam presos em uma perda de tempo. Trata-se de entender e reconhecer em que cada indivíduo é 100x e em que é 0,1x.

Embora isso pareça muito simples, na prática é significativamente mais difícil.

Há muitas coisas que um líder de equipe ou desenvolvedor não saberá até que tenham tentado antes. Ou recebem tempo e oportunidade para aprimorar e dominar as habilidades envolvidas nessas situações específicas. Há também muitas coisas, especialmente novas tecnologias, nas quais ninguém é bom, e tudo se resume a correr riscos e chances.

É função do líder da equipe organizar as tarefas de acordo com as necessidades de todos. E se isso não for possível, trata-se também de entender que, mesmo que alguém não possa ser 100 vezes maior na sua situação agora, ele pode estar em outro lugar em outras equipes.

E cabe a cada desenvolvedor individual, descobrir no que eles são bons e ruins e comunicar isso à sua equipe de acordo.

Até a morte com o mito do engenheiro 10x, viva o engenheiro 100x em situações específicas

PS: Se você ainda não fez nenhuma resolução de ano novo. Talvez aumentar sua área de superfície de sorte possa ser isso!

~ 🖖 vida longa e próspera

Eugene Cheah: CTO da uilicious.com

Postado originalmente em: https://substack.tech-talk-cto.com/p/dev-to-cto-how-do-i-become-a-10x

Créditos da imagem