Techlead Skyeng Kirill Rogovoy ( flashhhh ) fala em conferências nas quais ele fala sobre as habilidades que todo bom desenvolvedor precisa desenvolver para se tornar o melhor. Pedi a ele que compartilhasse essa história com os leitores de Habra, passo a palavra para Cyril.
O mito sobre um bom desenvolvedor diz que ele:
- Grava código limpo
- Conhece muita tecnologia
- Codificando tarefas mais rapidamente
- Conhece vários algoritmos e padrões de design
- Pode refatorar qualquer código usando o Código Limpo
- Não perde tempo com tarefas não programáticas
- Mestre 100% da sua tecnologia favorita
É assim que os RHs veem os candidatos ideais e as vagas, respectivamente, também se parecem com isso.
Mas minha experiência diz que isso não é muito verdade.
Primeiro, duas isenções de responsabilidade importantes:
1) minha experiência é com equipes de produtos, ou seja, empresas com seus produtos, não terceirizando; a terceirização pode ser muito diferente;
2) se você é júnior, nem todas as dicas serão aplicáveis, e eu ainda me concentraria na programação em seu lugar.
Bom desenvolvedor: realidade
1: Codite é melhor que a média
Um bom desenvolvedor sabe como criar uma arquitetura legal, escrever código legal e não cometer muitos bugs; em geral, tudo é melhor para ele do que a média, mas ele não está no top 1% dos especialistas. A maioria dos desenvolvedores mais legais que eu conheço não são ótimos programadores: eles são bem versados em suas áreas, mas não podem fazer nada super-super.
2: Resolve problemas, não os cria
Imagine que precisamos integrar um serviço externo em um projeto. Nós obtemos o TK, olhamos para as docas, vemos que algo está desatualizado lá, entendemos que precisamos passar parâmetros adicionais, colocar algo, tentar implementar de alguma forma tudo isso e fazer algum tipo de método de curva funcionar corretamente, finalmente, depois de algumas dias entendemos que ainda é impossível. O comportamento padrão do desenvolvedor nessa situação é retornar aos negócios e dizer: "Eu fiz isso e aquilo, este não funciona assim e, de maneira geral, não funciona, em geral, vá descobrir por si mesmo". A empresa tem um problema: você precisa se aprofundar no que aconteceu, se comunicar com alguém, tentar resolvê-lo de alguma forma. O telefone quebrado começa: "você diz a ele, eu escreverei para ela, veja o que eles responderam".
Um bom desenvolvedor, diante de tal situação, encontrará os contatos pessoalmente, anulará, telefonará, discutirá o problema e, se tudo mais falhar, ele reunirá as pessoas certas, explicará tudo e oferecerá alternativas (provavelmente, existe outro serviço externo com melhor suporte). Esse desenvolvedor vê um problema de negócios e o resolve. Sua tarefa foi encerrada quando ele resolveu o problema dos negócios, e não quando encontrou algo.
3: tenta gastar o mínimo de esforço, obtendo o máximo de resultados, mesmo se você precisar escrever muletas
O desenvolvimento de software em empresas de supermercado é quase sempre a maior despesa: os desenvolvedores são caros. E um bom desenvolvedor entende que uma empresa deseja obter a quantidade máxima de dinheiro gastando o mínimo. Para ajudá-lo, um bom desenvolvedor deseja gastar a quantia mínima de seu tempo dispendioso para obter o lucro máximo para o empregador.
Dois extremos surgem aqui. Uma é que é possível resolver todos os problemas em uma muleta, não se preocupar com a arquitetura, não refatorar, etc. Todos sabemos como isso geralmente termina: nada funciona, reescrevemos o projeto do zero. O outro é quando uma pessoa tenta criar uma arquitetura ideal para cada botão, passa uma hora em uma tarefa e quatro em refatoração. O resultado desse trabalho parece ótimo, mas o problema é que leva dez horas para o botão do lado comercial, o que, no primeiro, no segundo caso, simplesmente por vários motivos.
Um bom desenvolvedor pode se equilibrar entre esses extremos. Ele entende o contexto e toma a melhor decisão: nesta tarefa, serei uma muleta, porque esse é um código que é tocado a cada seis meses. Mas neste, estou confuso e farei tudo da maneira mais correta possível, porque cem novos recursos que ainda precisam ser desenvolvidos dependerão do que eu puder fazer.
4. Possui sistema de gerenciamento de negócios próprio, é capaz de elaborar projetos de qualquer complexidade.
Trabalhe nos princípios de Como fazer as coisas - quando você escreve tudo em um sistema de texto, não esquece nenhum acordo, pressiona todos, aparece em todos os lugares no tempo, sabe o que é importante, o que é importante no momento, você nunca perde suas tarefas. A característica geral dessas pessoas é que, quando você chega a um acordo com elas, nunca se preocupa que elas se esqueçam; e você também sabe que todos escrevem e não farão mais mil perguntas, cujas respostas já foram discutidas.
5. Duvida e esclarece quaisquer condições e introdução
Há também dois extremos aqui. Por um lado, você pode ser cético em relação a todos os introdutórios. Antes de você, as pessoas criaram algumas soluções, e você acha que pode fazer melhor e começar a discutir novamente tudo o que vinha antes de você: design, soluções de negócios, arquitetura etc. Isso gasta muito tempo, tanto o desenvolvedor quanto os outros, e afeta negativamente a confiança dentro da empresa: outras pessoas não querem tomar decisões porque sabem que esse cara voltará e quebrará tudo. O outro extremo é quando um desenvolvedor percebe qualquer desejo introdutório de TK e hotel como algo esculpido em pedra, e apenas tendo encontrado um problema insolúvel, ele começa a pensar se está envolvido nele. Um bom desenvolvedor aqui também encontra um meio termo: tentar entender as decisões tomadas com ou sem ele, antes que a tarefa entre em desenvolvimento. O que a empresa quer? Nós resolvemos os problemas dele? O designer do produto apresentou uma solução, mas entendo por que essa solução funcionará? Por que o líder da equipe criou essa arquitetura? Se algo não estiver claro, você precisará perguntar. No processo desse esclarecimento, um bom desenvolvedor pode ver uma solução alternativa que simplesmente não ocorreu a ninguém antes dele.
6. Melhora os processos e as pessoas ao seu redor.
Muitos processos estão acontecendo ao nosso redor - comícios diários, reuniões, scrams, essas revisões, revisões de código etc. Um bom desenvolvedor se levanta e diz: ouça, vamos discutir a mesma coisa toda semana, não entendo por que, com o mesmo sucesso, você pode passar essa hora no "Contra". Ou: na terceira tarefa consecutiva, não consigo inserir o código, nada está claro, a arquitetura está cheia de buracos; talvez nosso código de revisão seja ruim e precisamos refatorar, vamos realizar a refatoração mitap uma vez a cada duas semanas. Ou durante uma revisão de código, uma pessoa vê que um de seus colegas não está usando uma determinada ferramenta com eficácia suficiente, o que significa que você precisa entrar em contato e informar mais tarde. Um bom desenvolvedor tem esse instinto, ele faz essas coisas na máquina.
7. Gerencia perfeitamente os outros, mesmo que não seja um gerente
Essa habilidade está bem ligada ao tema "resolver, não criar problemas". Muitas vezes, nada está escrito sobre gerenciamento no texto da vaga em que chegamos, mas, quando confrontado com um problema fora do seu controle, você ainda precisa gerenciar os outros de uma maneira ou de outra, obter algo deles, se você esqueceu de pressionar, certifique-se que todos eles entenderam. Um bom desenvolvedor sabe quem está interessado no quê, pode reunir-se com essas pessoas, anotar acordos, rejeitá-los, lembrá-los no dia certo, garantir que tudo esteja pronto, mesmo que ele pessoalmente não seja o responsável direto por essa tarefa, mas seu resultado depende desde a sua implementação.
8. Não percebe seu conhecimento como um dogma, constantemente aberto a críticas
Todos podem se lembrar de um colega de um trabalho anterior que é incapaz de se comprometer com sua tecnologia, grita que todos vão queimar no inferno por algumas mutações erradas. Um bom desenvolvedor, se ele trabalha há 5, 10, 20 anos na indústria, entende que metade de seu conhecimento é podre e, na metade restante, ele não sabe dez vezes mais do que sabe. E toda vez que alguém discorda dele e oferece uma alternativa, isso não é um ataque ao seu ego, mas a oportunidade de aprender alguma coisa. Isso permite que ele cresça muito mais rápido que os outros.
Compare minha idéia de um desenvolvedor ideal com o geralmente aceito:
Nesta figura, você pode ver quantos pontos acima estão relacionados ao código e quantos não estão. O desenvolvimento em uma empresa de supermercado é apenas um terço da programação, os 2/3 restantes têm pouco a ver com o código. E, apesar de escrevermos muito código, nossa eficácia depende fortemente desses dois terços "não relacionados".
Especialização, generalismo e a regra "80-20"
Quando uma pessoa aprende a resolver alguns problemas estreitos, ela aprende por muito tempo e muito, mas depois os resolve com facilidade e simplicidade, mas não possui experiência em áreas relacionadas - essa é uma especialização. O generalismo, por outro lado, é quando metade do tempo de treinamento é investido em uma zona de competência própria e outra metade em áreas afins. Por conseguinte, no primeiro caso, faço uma coisa perfeitamente, e o resto - mal e no segundo - faço tudo mais ou menos bem.
A regra 80-20 nos diz que 80% do resultado é alcançado através de 20% do esforço. 80% da receita é gerada por 20% dos clientes, 80% do lucro é gerado por 20% dos funcionários e assim por diante. No treinamento, isso significa que obtemos 80% do conhecimento nos primeiros 20% do tempo gasto.
Existe uma idéia: os codificadores devem apenas codificar, os designers devem projetar, os analistas devem analisar e os gerentes devem gerenciar. Na minha opinião, essa ideia é tóxica e não funciona muito bem. Não é que todos devam ser soldados universais, é uma questão de economizar recursos. Se um desenvolvedor é um pouco versado em gerenciamento, design e análise, ele poderá resolver muitos problemas sem envolver outras pessoas. Se você precisar criar algum recurso e verificar como os usuários trabalham com ele em um determinado contexto, o que exigirá duas consultas SQL, é ótimo poder não distrair a análise. Se você precisar pressionar um botão por analogia com os existentes e entender os princípios gerais, poderá fazê-lo sem envolver um designer, e a empresa agradecerá por isso.
Total: você pode gastar 100% do tempo aprendendo uma certa habilidade até o limite, ou pode gastar o mesmo tempo em cinco áreas, aumentando 80% em cada uma. Seguindo essa matemática ingênua, podemos obter quatro vezes mais habilidades ao mesmo tempo. Isso é um exagero, mas ilustra a ideia.
As habilidades adjacentes podem ser treinadas não em 80%, mas em 30-50%. Depois de passar de 10 a 20 horas, você notará sensivelmente as áreas relacionadas, entenderá bastante os processos que estão ocorrendo nelas e se tornará muito mais autônomo.
No ecossistema moderno de TI, é melhor ter o maior número possível de habilidades e não ser especialista em nenhuma delas. Porque, em primeiro lugar, todas essas habilidades desaparecem rapidamente, principalmente quando se trata de programação e, em segundo lugar, porque 99% do tempo usamos não apenas as habilidades básicas, mas certamente não as mais sofisticadas, e isso é suficiente mesmo na codificação, mesmo em empresas legais.
E, finalmente, o treinamento é um investimento e a diversificação é importante nos investimentos.
O que ensinar
Então, o que ensinar e como? Um desenvolvedor típico de uma empresa forte usa regularmente:
- comunicação
- auto-organização
- planejamento
- design (geralmente código)
- e, às vezes, gerenciamento, liderança, análise de dados, redação, contratação, mentoria e muitas outras habilidades
E praticamente nenhuma dessas habilidades se cruza com o próprio código. Eles precisam ser treinados e bombeados separadamente e, se isso não for feito, permanecerão em um nível muito baixo, o que não permite que sejam utilizados de maneira eficaz.
Que áreas vale a pena desenvolver?
Soft skills - isso é tudo o que não se aplica aos pressionamentos de botão no editor. É assim que escrevemos mensagens, como nos comportamos nas reuniões, como nos comunicamos com os colegas. Parece que todas as coisas óbvias, mas muitas vezes são subestimadas.
Sistema de auto-organização. Para mim, no último ano, isso se tornou um tópico super importante. Entre todos os profissionais legais de TI que conheço, essa é uma das habilidades mais desenvolvidas: elas são superorganizadas, sempre fazem o que dizem, sabem exatamente o que farão amanhã, em uma semana, em um mês. É necessário construir um sistema em torno de si mesmo, no qual todos os assuntos e todas as questões sejam registrados, isso facilita muito o trabalho em si e ajuda muito a interagir com outras pessoas. De acordo com meus sentimentos, ao longo do ano passado, o desenvolvimento nessa direção me impulsionou muito mais do que o aprimoramento de habilidades técnicas, comecei a fazer muito mais trabalho por unidade de tempo.
Proatividade, mente aberta e planejamento. Os tópicos são muito gerais e vitais, não exclusivos da TI, e todos devem desenvolvê-los. Proatividade significa não esperar um sinal para agir. Você é a fonte dos eventos, não as reações a eles. Mente aberta - a capacidade de se relacionar objetivamente com qualquer nova informação, de avaliar a situação isoladamente de sua própria visão de mundo e hábitos antigos. O planejamento é uma visão clara de como a tarefa de hoje resolve o problema por uma semana, mês, ano. Se você vê o futuro além de uma tarefa específica, é muito mais fácil fazer o que precisa e não ter medo de perceber ao longo do tempo que foi desperdiçado. Essa habilidade é especialmente importante para uma carreira: há anos você consegue resultados com sucesso, mas não onde precisa, e eventualmente perde toda a bagagem acumulada quando fica claro que você estava seguindo na direção errada.
Todas as áreas relacionadas ao nível básico. Todo mundo tem suas próprias áreas específicas, mas é importante entender que, passando de 10 a 20 horas dedicando algum tipo de habilidade "estrangeira", você pode descobrir muitas novas oportunidades e pontos em comum no trabalho diário, e essas horas podem ser suficientes para fim de carreira.
O que ler
Existem muitos livros sobre auto-organização, este é um setor inteiro em que alguns caras obscuros escrevem coleções de dicas e colecionam treinamentos. No entanto, não está claro o que eles mesmos alcançaram na vida. Portanto, é importante colocar filtros nos autores, para ver quem eles são e o que eles têm por trás deles. Quatro livros influenciaram meu desenvolvimento e perspectivas, acima de tudo, todos de uma maneira ou de outra, relacionados ao bombeamento das habilidades descritas acima.
1. Dale Carnegie "Como fazer amigos e influenciar pessoas" . Um livro de culto sobre habilidades pessoais, se não estiver claro por onde começar, escolhendo-o é uma opção em que todos saem ganhando. Ele é baseado em exemplos, fáceis de ler, não requer muito esforço para compreender o que foi lido, e as habilidades adquiridas podem ser aplicadas imediatamente. Em geral, o livro revela o tópico da comunicação com as pessoas.
2. Stephen R. Covey, "7 habilidades de pessoas altamente eficazes" . Uma mistura de habilidades diferentes, de proatividade a soft skills, com ênfase na obtenção de sinergia, quando você precisa transformar uma equipe pequena em uma força enorme. Fácil de ler.
3. Princípios de Ray Dalio . Ele revela os tópicos de mente aberta e proatividade, com base na história da empresa criada pelo autor, que ele administrou por 40 anos. Muitos exemplos duramente conquistados da vida, ótimos exemplos de como uma pessoa pode ser preconceituosa e dependente, como se livrar dela.
4. David Allen "Como colocar as coisas em ordem" . Leitura obrigatória para aprender a auto-organização. A leitura não é tão simples, mas fornece um conjunto exaustivo de ferramentas para organizar a vida e o trabalho, examina detalhadamente todos os aspectos e ajuda a decidir o que você precisa. Com sua ajuda, construí meu sistema, o que me permite sempre fazer o mais importante, sem esquecer o resto.
Você precisa entender que apenas ler não é suficiente. Você pode engolir até um livro por semana, mas o efeito permanecerá por vários dias e tudo voltará ao seu lugar. Os livros devem ser usados como uma fonte de aconselhamento que é imediatamente testado na prática. Se isso não for feito, tudo o que eles darão é uma expansão de horizontes.