Líder técnico Skyeng Kirill Rogovoy () faz apresentações em conferências nas quais fala sobre as habilidades que todo bom desenvolvedor deve desenvolver para se tornar o melhor. Pedi a ele que compartilhasse essa história com os leitores do Habra, passo a palavra ao Kirill.
O mito sobre um bom desenvolvedor é que ele:
- Escreve código limpo
- Conhece muitas tecnologias
- Tarefas de codificação mais rápidas
- Conhece vários algoritmos e padrões de design
- Pode refatorar qualquer código usando Clean Code
- Não perde tempo com tarefas que não sejam de programação
- 100% mestre em sua tecnologia favorita
É assim que o RH vê os candidatos ideais e, portanto, as vagas também são assim.
Mas minha experiência diz que isso não é muito verdade.
Primeiro, duas isenções de responsabilidade importantes:
1) minha experiência são equipes de produto, ou seja, empresas com produto próprio, não terceirizando; na terceirização tudo pode ser bem diferente;
2) se você for júnior, nem todos os conselhos serão aplicáveis e, se eu fosse você, me concentraria na programação por enquanto.
Bom desenvolvedor: realidade
1: Código melhor que a média
Um bom desenvolvedor sabe como criar uma arquitetura legal, escrever códigos legais e não criar muitos bugs; Em geral, ele se sai melhor que a média, mas não está entre os 1% melhores especialistas. A maioria dos desenvolvedores mais legais que conheço não são tão bons programadores: eles são ótimos no que fazem, mas não conseguem fazer nada superextraordinário.
2: Resolve problemas em vez de criá-los
Vamos imaginar que precisamos integrar um serviço externo ao projeto. Recebemos as especificações técnicas, olhamos a documentação, vemos que algo está desatualizado ali, entendemos que precisamos passar parâmetros adicionais, fazer alguns ajustes, tentar implementar tudo de alguma forma e fazer algum método torto funcionar corretamente, enfim, depois de alguns de dias entendemos que não podemos continuar assim. O comportamento padrão de um desenvolvedor nesta situação é voltar ao trabalho e dizer: “Eu fiz isso e aquilo, este não funciona assim e aquele não funciona de jeito nenhum, então descubra você mesmo. ” Uma empresa tem um problema: você precisa se aprofundar no ocorrido, comunicar-se com alguém e tentar de alguma forma resolvê-lo. O telefone quebrado começa: “você fala para ele, vou mandar uma mensagem para ela, olha o que eles responderam”.
Um bom desenvolvedor, diante de tal situação, encontrará ele mesmo os contatos, entrará em contato por telefone, discutirá o problema e, se nada der certo, 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 é encerrada quando ele resolve um problema de negócios, e não quando se depara com algo.
3: Tenta despender o mínimo de esforço para obter o máximo de resultados, mesmo que isso signifique escrever muletas
O desenvolvimento de software em empresas de produtos é quase sempre o maior item de despesa: os desenvolvedores são caros. E um bom desenvolvedor entende que uma empresa deseja obter o máximo de dinheiro gastando o mínimo. Para ajudá-lo, um bom desenvolvedor deseja gastar o mínimo de seu caro tempo para obter o lucro máximo para o empregador.
Existem dois extremos aqui. Uma é que geralmente você pode resolver todos os problemas com uma muleta, sem se preocupar com arquitetura, sem refatorar, etc. Todos nós sabemos como isso geralmente termina: nada funciona, reescrevemos o projeto do zero. Outra é quando uma pessoa tenta criar uma arquitetura ideal para cada botão, gastando uma hora na tarefa e quatro na refatoração. O resultado desse trabalho parece ótimo, mas o problema é que do lado comercial são necessárias dez horas para preencher um botão, tanto no primeiro quanto no segundo caso, simplesmente por motivos diferentes.
Um bom desenvolvedor sabe equilibrar esses extremos. Ele entende o contexto e toma a decisão ideal: nesse problema vou usar uma muleta, porque esse é um código que é tocado uma vez a cada seis meses. Mas neste vou me preocupar e fazer tudo da maneira mais correta possível, pois uma centena de novas funcionalidades que ainda precisam ser desenvolvidas dependerão do meu sucesso.
4. Possui sistema de gestão empresarial próprio e está apto a atuar em projetos de qualquer complexidade.
Trabalhando com princípios – quando você anota todas as suas tarefas em algum tipo de sistema de texto, não se esqueça de nenhum acordo, pressione todo mundo, chegue em todos os lugares na hora certa, saiba o que é importante e o que não é importante no momento, você nunca perde tarefas. A característica geral dessas pessoas é que quando você concorda em algo com elas, você nunca se preocupa com a possibilidade de elas esquecerem; e você também sabe que eles anotam tudo e depois não vão fazer mil perguntas, cujas respostas já foram discutidas.
5. Questiona e esclarece quaisquer condições e apresentações
Também aqui existem dois extremos. Por um lado, você pode ser cético em relação a todas as informações introdutórias. Pessoas antes de você apresentaram algumas soluções, mas você acha que pode fazer melhor e começa a rediscutir tudo o que veio antes de você: design, soluções de negócios, arquitetura, etc. Isso desperdiça muito tempo tanto para o desenvolvedor quanto para quem está ao seu redor, além de impactar negativamente na confiança dentro da empresa: outras pessoas não querem tomar decisões porque sabem que aquele cara vai voltar e quebrar tudo. O outro extremo é quando o desenvolvedor percebe quaisquer especificações técnicas introdutórias e desejos de negócios como algo gravado em pedra, e somente quando se depara com um problema insolúvel ele começa a pensar se está fazendo o que está fazendo. Um bom desenvolvedor também encontra aqui um meio-termo: ele tenta entender as decisões tomadas antes ou sem ele, antes da tarefa entrar em desenvolvimento. O que as empresas querem? Estamos resolvendo seus problemas? O designer do produto encontrou uma solução, mas entendo por que a solução funcionará? Por que o líder da equipe criou essa arquitetura específica? Se algo não estiver claro, você precisa perguntar. No processo desse esclarecimento, um bom desenvolvedor pode ver uma solução alternativa que simplesmente não havia ocorrido a ninguém antes.
6. Melhora os processos e as pessoas ao seu redor
Existem muitos processos acontecendo ao nosso redor – reuniões diárias, encontros, scrums, análises técnicas, revisões de código, etc. Um bom desenvolvedor vai se levantar e dizer: olha, a gente se reúne e discute a mesma coisa toda semana, não entendo porque, podemos muito bem passar essa hora no Contra. Ou: para a terceira tarefa consecutiva não consigo entrar no código, nada está claro, a arquitetura está cheia de buracos; Talvez nosso código de revisão seja ruim e precisemos refatorar, vamos refatorar o encontro 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 eficiência suficiente, o que significa que ele precisa aparecer mais tarde e dar alguns conselhos. Um bom desenvolvedor tem esse instinto; ele faz essas coisas automaticamente.
7. Excelente em gerenciar outras pessoas, mesmo que não seja um gerente
Esta habilidade combina bem com o tema “resolver em vez de criar problemas”. Muitas vezes, no texto da vaga a que nos candidatamos, não está escrito nada sobre gestão, mas depois, diante de um problema que foge ao seu controle, você ainda tem que gerenciar outros de uma forma ou de outra, conseguir algo deles, se você esqueci - empurre, certifique-se de que eles entenderam tudo. Um bom desenvolvedor sabe quem está interessado no quê, pode convocar uma reunião com essas pessoas, anotar acordos, mandá-las para folga, lembrá-las no dia certo, certificar-se de que está tudo pronto, mesmo que ele não seja pessoalmente responsável direto por esta tarefa, mas seu resultado depende de sua implementação.
8. Não percebe seu conhecimento como dogma, está constantemente aberto a críticas
Todos se lembram de um colega de trabalho anterior que não consegue comprometer sua tecnologia e grita que todos vão queimar no inferno por causa de algumas mutações erradas. Um bom desenvolvedor, se trabalhar 5, 10, 20 anos na indústria, entende que metade do seu conhecimento está podre, e na outra metade ele não sabe dez vezes mais do que sabe. E cada vez que alguém discorda dele e oferece uma alternativa, não é um ataque ao seu ego, mas uma oportunidade de aprender algo. Isso permite que ele cresça muito mais rápido do que aqueles ao seu redor.
Vamos comparar minha ideia de desenvolvedor ideal com a geralmente aceita:
Esta imagem mostra quantos dos pontos descritos acima estão relacionados ao código e quantos não estão. O desenvolvimento em uma empresa de produtos é apenas um terço da programação, os 2/3 restantes têm pouco a ver com código. E embora escrevamos muito código, nossa eficácia depende muito desses dois terços “irrelevantes”.
Especialização, generalismo e a regra 80-20
Quando uma pessoa aprende a resolver alguns problemas estreitos, estuda muito e muito, mas depois os resolve de maneira fácil e simples, mas não tem experiência em áreas afins, isso é especialização. Generalismo é quando metade do tempo de formação é investido na área de sua competência e outra metade em áreas afins. Assim, 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 vem de 20% do esforço. 80% da receita vem de 20% dos clientes, 80% do lucro vem de 20% dos funcionários e assim por diante. No ensino, isso significa que 80% do conhecimento adquirimos nos primeiros 20% do tempo gasto.
Existe uma ideia: os codificadores devem apenas codificar, os designers devem apenas projetar, os analistas devem analisar e os gerentes devem apenas gerenciar. Na minha opinião, esta ideia é tóxica e não funciona muito bem. Não se trata de todos terem de ser soldados universais, trata-se de poupar recursos. Se um desenvolvedor entender pelo menos um pouco de gerenciamento, design e análise, ele conseguirá resolver muitos problemas sem envolver outras pessoas. Se você precisar fazer algum tipo de recurso e depois verificar como os usuários trabalham com ele em um determinado contexto, o que exigirá duas consultas SQL, então é ótimo poder não distrair o analista com isso. Se você precisar incorporar 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 seu tempo estudando uma habilidade até o limite, ou pode gastar o mesmo tempo em cinco áreas, nivelando até 80% em cada uma. Seguindo essa matemática ingênua, podemos adquirir quatro vezes mais habilidades no mesmo período de tempo. Isso é um exagero, mas ilustra a ideia.
Habilidades relacionadas podem ser treinadas não em 80%, mas em 30-50%. Depois de passar de 10 a 20 horas, você melhorará visivelmente em áreas relacionadas, ganhará bastante compreensão dos processos que ocorrem nelas e se tornará muito mais autônomo.
No ecossistema de TI atual, é melhor ter o máximo de habilidades possível 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 habilidades básicas, mas certamente não as mais sofisticadas, e isso é suficiente até na codificação, mesmo em empresas legais.
E, finalmente, a formação é um investimento e a diversificação é importante nos investimentos.
O que ensinar
Então, o que ensinar e como? Um desenvolvedor típico em uma empresa forte usa regularmente:
- comunicação
- auto-organização
- planejamento
- design (geralmente código)
- e às vezes gestão, liderança, análise de dados, redação, recrutamento, mentoria e muitas outras habilidades
E praticamente nenhuma dessas habilidades se cruza com o código em si. Eles precisam ser ensinados e atualizados 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 forma eficaz.
Em quais áreas vale a pena desenvolver?
-
Soft skills são tudo o que não diz respeito a apertar botões no editor. É assim que escrevemos mensagens, como nos comportamos nas reuniões, como nos comunicamos com os colegas. Todas essas coisas parecem óbvias, mas muitas vezes são subestimadas.
-
Sistema de auto-organização. Para mim, pessoalmente, este se tornou um tópico superimportante no ano passado. Entre todos os profissionais de TI bacanas que conheço, essa é uma das habilidades mais desenvolvidas: eles são superorganizados, sempre fazem o que mandam, sabem exatamente o que farão amanhã, daqui a uma semana, daqui a um mês. É necessário construir ao seu redor um sistema no qual todos os assuntos e todas as dúvidas sejam registradas, isso facilita muito o trabalho em si e ajuda muito a interagir com outras pessoas. Sinto que durante o ano passado, o desenvolvimento nesta direção melhorou-me muito mais do que melhorar as minhas competências técnicas; comecei a fazer significativamente mais trabalho por unidade de tempo.
-
Proativo, mente aberta e planejamento. Os tópicos são muito gerais e vitais, não exclusivos da TI, e todos deveriam desenvolvê-los. Proatividade significa não esperar por um sinal para agir. Você é a fonte dos eventos, não das reações a eles. A mente aberta é a capacidade de tratar qualquer informação nova de forma objetiva, de avaliar a situação isoladamente da própria visão de mundo e dos velhos hábitos. O planejamento é uma visão clara de como a tarefa de hoje resolve o problema da semana, do mês, do ano. Se você enxerga o futuro além de uma tarefa específica, fica muito mais fácil fazer o que precisa, e não ter medo depois de um tempo perceber que foi desperdiçado. Essa habilidade é especialmente importante para uma carreira: você pode alcançar resultados com sucesso durante anos, mas no lugar errado, e eventualmente perder toda a bagagem acumulada quando ficar claro que você estava indo na direção errada.
-
Todas as áreas relacionadas ao nível básico. Cada um tem suas áreas específicas, mas é importante entender que ao gastar de 10 a 20 horas aprimorando alguma habilidade “estrangeira”, você pode descobrir muitas novas oportunidades e pontos de contato em seu trabalho diário, e essas horas podem ser suficiente até o final da carreira.
O que ler
Existem muitos livros sobre auto-organização; é toda uma indústria onde alguns caras estranhos escrevem coleções de conselhos e coletam treinamentos. Ao mesmo tempo, não está claro o que eles próprios alcançaram na vida. Por isso, é importante colocar filtros nos autores, olhar quem eles são e o que têm por trás. Meu desenvolvimento e perspectiva foram mais influenciados por quatro livros, todos eles de uma forma ou de outra relacionados ao aprimoramento das habilidades descritas acima.
1. Dale Carnegie “Como fazer amigos e influenciar pessoas”. Um livro de culto sobre soft skills, se você não sabe por onde começar, escolhê-lo é uma opção ganha-ganha. É baseado em exemplos, é fácil de ler, não requer muito esforço para compreender o que você lê e as habilidades adquiridas podem ser aplicadas imediatamente. No geral, o livro cobre o tema da comunicação com as pessoas.
2. Stephen R. Covey “7 Hábitos de Pessoas Altamente Eficazes”. Uma mistura de diferentes competências, desde proatividade até soft skills, com ênfase na obtenção de sinergia quando é necessário transformar uma pequena equipe em uma grande força. Também é fácil de ler.
3. Ray Dalio "Princípios". Revela temas de abertura e proatividade, a partir da história da empresa que o autor construiu e que administrou durante 40 anos. Muitos exemplos da vida duramente conquistados mostram como uma pessoa pode ser preconceituosa e dependente e como se livrar disso.
4. David Allen, “Fazendo as coisas”. Leitura obrigatória para aprender auto-organização. Não é tão fácil de ler, mas fornece um conjunto abrangente de ferramentas para organizar a vida e os assuntos, examina todos os aspectos detalhadamente e ajuda você a decidir exatamente o que precisa. Com a ajuda dela, construí meu próprio sistema que me permite fazer sempre as coisas mais importantes sem esquecer do resto.
Você deve entender que apenas ler não é suficiente. Você pode engolir pelo menos um livro por semana, mas o efeito durará vários dias e depois tudo voltará ao seu lugar. Os livros devem ser usados como fonte de conselhos que são imediatamente testados na prática. Se você não fizer isso, tudo o que eles darão é uma ampliação de seus horizontes.
Fonte: habr.com