BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Artigos Como melhorar suas habilidades para se tornar um desenvolvedor melhor

Como melhorar suas habilidades para se tornar um desenvolvedor melhor

Pontos principais

  • Entender porque katas não são suficientes.
  • Aprender as quatro habilidades principais necessárias para ser um ótimo desenvolvedor.
  • Adicionar intensidade à sua capacitação, para aprimorar suas habilidades.
  • Descobrir ferramentas úteis para suas sessões de estudos.
  • Usar métricas como ferramentas para entender o nível de suas habilidades.

Desenvolvedores de software usam katas para aprender novas habilidades em desenvolvimento. A maneira como os katas são usados hoje é ótima para aprender novas habilidades e aprimorar outras já existentes, mas não retrata a intensidade encontrada no trabalho quando há um momento de forte estresse como um prazo de entrega, data de lançamento, ter que lidar com um bug em um código legado gigantesco, etc.

Este artigo cobre as habilidades de bons desenvolvedores e destaca a importância de mudar seu método de aprendizagem, para aprimorar suas habilidades em ambientes de alta intensidade e com muitos desafios.

Habilidades de um bom desenvolvedor

Quais habilidades são importantes para desenvolvedores? Cada desenvolvedor tem uma resposta diferente para a pergunta, engana-se quem acha que são apenas habilidades técnicas.

Um bom conhecimento técnico é importante, mas não é o suficiente. Alguns desenvolvedores focam mais em habilidades técnicas, outros darão destaque a habilidades agile, e assim por diante. Depende de como se vê o trabalho de desenvolvimento. Tente responder essas perguntas:

  • Por que sou um desenvolvedor de software?
  • Por que estou desenvolvendo esse produto?
  • Por qual motivo eu estou aprendendo essa linguagem/framework?
  • Quais são os valores/impactos do meu produto?

Se você não mencionou os usuários finais e as necessidades deles nas suas respostas, significa que está perdendo alguma coisa.

As quatro principais habilidades

Ter o usuário final em mente é a primeira habilidade de um bom desenvolvedor. Procure saber os problemas dos seus usuários finais, e as necessidades deles. Então desenvolva o produto que resolve esses problemas e supre essas necessidades. É disso que se trata o desenvolvimento de software.

A segunda habilidade se trata da qualidade do que você entrega. Entregar com zero defeitos é uma habilidade, que é difícil de conseguir, mas não impossível. Adoramos aquele tweet do Ed Weissman. Essa habilidade deve ser estável, o que significa ser capaz de entregar uma funcionalidade com zero defeitos sob quaisquer circunstâncias. É claro, isso também significa que você não quebra funcionalidades já existentes.

A terceira habilidade é ter simplicidade e não temer complexidade inerente ou acidental. Trata-se de decomposição e abstração: a habilidade de quebrar sistemas/problemas complexos em partes menores, contrapor essas partes menores para torná-las independentes, e organizar essas partes para torná-las compreensíveis no nível correto de abstração.

Ao longo desses passos, será preciso ignorar os detalhes que não são essenciais, para manter o seu foco na abstração certa. Recomendamos o livro do John Maeda, The Laws of Simplicity, que é uma bela fonte de inspiração.

A quarta habilidade é unir todas as habilidades anteriores e adicionar agilidade sem comprometer nada, especialmente a qualidade. Ser ágil sem ter as primeiras três habilidades não é o propósito. Não se está buscando unicamente por efeitos rápidos, mas por efeitos rápidos, positivos e de alta qualidade. Esse é o ponto mais importante nessa abordagem: adotar qualidade e intensidade ao mesmo tempo.

Descanse

Para se recuperar, se renovar e se regenerar, seu corpo precisa de descanso. Desenvolvedores constantemente não dão a importância necessária a esse fator. Muitos de nós se orgulham em passar noites sem dormir, até mesmo os mais experientes e talentosos. Pense sobre isso quando ler o artigo da Emily Beers sobre atletas e descanso.

Achamos que podemos substituir "atletas" por "desenvolvedores". "Retrospective bias" é um termo usado em psicologia para explicar o motivo pelo qual pessoas tendem a lembrar do passado de maneira diferente da qual realmente aconteceu, constantemente romantizando ele. Isso pode explicar a razão pela qual esquecemos da falta de produtividade e outras consequências negativas do dia após uma noite sem dormir. Tenha em mente que seu corpo precisa de uma pausa e que colocar os seus pés para cima de vez em quando, vai ajudá-lo a melhorar. O mesmo se aplica a dormir. Uma boa noite de sono (pelo menos sete horas por noite) e um bom descanso não são opcionais quando se trata de produtividade e trabalho de alta qualidade.

Dois valores para reforçar suas habilidades

Além desses talentos, queremos dar enfatizar dois valores: "sem culpa mas sem piedade"; e "ser inclusivo".

"Sem culpa" significa que você deve parar de procurar a parte culpada toda vez que encontrar um bug ou defeito. Com "sem culpa", você deve sempre ter um contraponto "sem piedade", para evitar um problema de negligência. Ao invés de culpar, as equipes devem se empenhar para entender as razões por trás de um defeito, o que pode estar errado com as práticas da equipe e como prevenir que aquele defeito aconteça novamente.

Aprendemos o valor da inclusão nas desconferências SoCraTes. Desde a primeira, nunca nos sentimos como estranhos. Todo mundo nos recebia com um sorriso, até aqueles que nunca havíamos encontrado antes. Nós e outros participantes novos nos sentimos imediatamente como parte dessa comunidade. Foi uma ótima experiência.

Aplique esse valor a novos colegas. Preste atenção para integrá-los o mais rápido possível. Os ajude a ajustar seus espaços de trabalho. Não hesite em ser par deles. O objetivo é de que eles nunca sintam-se como estranhos, desde o primeiro dia. Isso se aplica não unicamente ao aspecto humano de trazer a bordo mas também aos pontos de vista técnicos e profissionais. Significa que o time deve construir um ambiente inclusivo que permite que novas pessoas tomem parte de discussões e decisões já no seu primeiro dia. O mesmo valor deve ser aplicado a interações com outros stakeholders. Não se esqueça de habilidades locais relativas ao seu projeto. Nossa empresa, por exemplo, usa um framework caseiro, e ser bom na nossa equipe implica maestria nesse framework.

Esse tipo de atitude é importante e pode ter um impacto impressionante no seu trabalho. Se você tem a chance de ser parte de uma equipe altamente motivada e de grande moral, há uma grande chance de você se divertir com seus colegas conforme apresenta ótimas ideias e faz alguns dos seus melhores trabalhos.

Habilidades não são unicamente técnicas

O escopo de habilidades definido abaixo é amplo. Há muito o que aprender das metodologias agile, práticas XP, comunidades de software-craftsmanship, e muitas outras influências não necessariamente relacionadas com desenvolvimento de software. Por exemplo, jogos sérios como Ugg-Tect, Derdian Game ou o excellent Keep Talking and Nobody explodes podem ser uma ótima prática para a sua equipe.

As próximas seções focam unicamente no lado técnico de treinamento. Mais especificamente, elas irão olhar para como katas são usados e o que você pode fazer para que o treinamento seja o mais parecido possível com a vida real.

Adicione intensidade ao seu treinamento

Katas são atualmente o mais amplo exercício técnico usado por coaches/desenvolvedores para aprender/ensinar os básicos do desenvolvimento de software (clean code, TDD, etc.). Katas podem ser valiosos para dar uma base de conhecimento, mas raramente são o suficiente para enfrentar situações desafiadoras que podem ser urgentes (lidar com um prazo de entrega, uma data de lançamento, etc.) ou críticas (consertar um bug em uma gigantesca base de código legado sem testes ou que está coberta unicamente por testes legados).

Infelizmente, a primeira reação da maioria dos desenvolvedores quando enfrentam desafios intensos é tentar trabalhar mais rápido - mas adicionar rapidez sem se preparar para isso afeta negativamente a qualidade do trabalho. Alguns desenvolvedores veem seu trabalho como arte e não performance. Na verdade, desenvolvimento de software são ambos. Quando você adiciona intensidade no seu treinamento, você consegue adaptar do começo de um desafio e você será capaz de entregar soluções de alta qualidade independente deles.

Vejamos como alcançar isso.

Existem três fases para que possamos aprender uma nova habilidade:

  1. Aprender o básico,
  2. Consistência, e
  3. Intensidade

Faz-se necessário se certificar que cada nível será concluído antes de começar o outro.

Refatoração como um exemplo

Vamos pegar refatoração como um exemplo e aplicar um plano de treinamento nisso.

Aprenda o básico

A princípio, você deve saber o que refatoração significa. Quais são os code smells? Como limpar esses smells usando o catálogo de refatoração?

O livro Refatoração escrito por Martin Fowler: Improving the Design of Existing Code é algo que deve ser lido. Outra leitura interessante é o artigo do Uncle Bob, "The Transformation Priority Premise". Você pode achar interessante artigos na comunidade software-craftsmanship também. Adrian Bolboaca oferece alguns artigos bons sobre as regras básicas de refatoração e a refactoring rule of three.

Você deve dominar o catálogo de refatoração do seu IDE e aprender os atalhos pois isto salva tempo, salva processamento do cérebro e ajuda a evitar bugs. O objetivo nesse estágio não é velocidade. O objetivo é aprender como refatorar corretamente e quais ferramentas podem eficientemente te ajudar a fazer isso. Nesse nível, você deve ser capaz de identificar code smells, de limpá-los usando o catálogo de refatoração e saber as capacidades do seu IDE para isso. Para esse treinamento, você pode usar katas. The Coding Dojo Handbook da Emily Bach soma muitos katas interessantes como Gilded Rose, Yahtzee, Tennis Kata e Racing Car.

Remember, refactoring is a process for improving your code/architecture while maintaining application behaviour by doing small, "automatic" transformations. When you are in a refactoring session, always keep in mind the big picture.

Lembre-se, refatoração é um processo para aprimorar seu código e arquitetura enquanto mantém hábitos de aplicação fazendo pequenas e "automáticas" transformações. Quando você está em refatoramento, sempre tenha em mente a figura toda.

Consistência

A segunda fase de aprendizado é pegar o que você aprendeu na primeira fase e consistentemente aplicar isso em um novo kata ou no seu próprio projeto. Você pode, por exemplo, tentar o kata Trip Service estabelecido pelo Sandro Mancuso or o kata Trivia estabelecido por J.B. Rainsberger ou o método mikado. Nesse nível, você está familiarizado com todos os features de refatoramento do seu próprio IDE. Você se sente confiante quando transforma crud code em clean code e você pode aplicar isso a um novo kata assim como ao seu projeto no trabalho.

Intensidade

A terceira fase é sobre intensidade. Antes de começar essa fase, você deve se sentir confortável com o exercício. Você precisa ser capaz de completá-lo com um resultado de alta-qualidade. Você deve ter algum tipo de sentimento de domínio. Tendo alcançado essa etapa, você pode começar a trabalhar o aprimoramento da sua rapidez.

Pode-se obter intensidade refatorando código complexo. Outra forma de adicionar intensidade é aprimorar o tempo que você precisa para finalizar seus katas. Nesse caso, não hesite em comparar o seu trabalho com o de outros desenvolvedores. BeFaster parece ser uma forma interessante de comparar performance e aprender o que faz alguém mais rápido. Outra dica é assistir a desenvolvedores famosos em ação. O canal Condurance do Youtube contém muitos screencasts interessantes que todo desenvolvedor deve assistir. Lembre-se, não há razão em aprimorar sua rapidez se isso introduz erros: sempre escolha qualidade antes de velocidade.

Ferramentas para praticar desenvolvimento de software

Uma das formas principais de aprimorar seu desenvolvimento de software é conhecer, compartilhar e trocar com seus colegas. Eles são uma ótima fonte de conselhos, ideias e feedback. Claro, depende de você ingerir quaisquer descobertas.

Encontros e eventos locais

O Global Day of Coderetreat que acontece todo mê de outubro é um encontro anual de desenvolvedores do mundo todo. Você pode conferir o website para saber mais sobre esse evento e para checar se haverá uma reunião organizada perto de você. Se não, não hesite em organizar uma. É incrível! Tem muito material disponível no website para te ajudar.

Você pode procurar por encontros na sua cidade. Encontros são uma ótima oportunidade de encontrar outros desenvolvedores talentosos, de aprender novas coisas e de se divertir.

Organizar sessões com a sua empresa

Você pode também organizar uma reunião de 60 ou 90 minutos com seus colegas durante o horário de almoço ou depois do horário de trabalho. Katas são uma ótima forma de apresentar discussões interessantes em uma atmosfera segura.

Finalmente, nós recomendamos fortemente que você organize sessões de programação em mutirão com a sua equipe pelo menos uma vez por semana. Não use katas para isso. Seu código de produção é perfeito para compartilhar ideias e incentiva a coesão entre os membros da equipe.

Treinamento individual

Treinamento individual começa praticando, e é para isso que katas são feitos. Esse artigo já mencionou diversas fontes. Lembre-se, para adquirir conhecimento, você deve repetir até que se torne um hábito (e melhor ainda, um reflexo subconsciente). Não hesite em repetir katas diversas vezes.

Se você quer aprender uma nova linguagem, o que você deveria tentar pelo menos uma vez por ano, o site Exercicsm.io é um bom começo. Ele provém diversos exercícios ordenados por complexidade, com as unidades de testes apropriadas.

Se você quer se divertir enquanto pratica codificação, você deveria tentar o CodinGame. Ele adiciona intensidade que se aproxima de prazos de entrega de projetos reais: o jogo Clashes of Code é um bom exemplo. Vou pode se divertir resolvendo puzzles, cujos desafios vem não de pressão por tempo mas da inerente complexidade dos problemas a solucionar. CodinGame também organiza concursos para os quais ele mantém em segredo os problemas a trabalhar até que os concursos comecem. É tipo uma competição com uma leaderboard. Para fazer o máximo do CodinGame, você tem que escrever código eficiente e limpo.

Faça uso de métricas para aprimorar suas talentos de programação

Desenvolvedores tem um relacionamento complexo com métricas. Eles já as usam, especialmente quando estão trabalhando em questões relacionadas a performance. Nesse caso, é reconhecido que trabalhar sem algum tipo de medição é praticamente como jogar na loteria. Você pode ganhar, mas só por acaso.

Por outro lado, há um monte de medições e KPIs que desenvolvedores odeiam, como timesheets e gráficos de Gantt. Desenvolvedores veem eles como uma ferramenta usada para policiar e controlar ou como um preciosismo. Como resultado, quando se discute o uso de medições com desenvolvedores, há sempre suspeitas.

Métricas como uma ferramenta

Fundamentalmente, métricas deveriam ser uma ferramenta diária que ajuda a guiar suas decisões. Desenvolvedores são engenheiros, então é comum usar uma abordagem rigorosa e científica. Se você não entende profundamente o seu ponto inicial e o seu destino, você não conseguirá agir efetiva e consistentemente. Métricas são ferramentas muito boas para ajudá-lo a entender sua situação.

Um exemplo de utilização de métricas

Para aprimorar suas habilidades em IDEs, por exemplo, uma maneira é maximizar o uso de atalhos do teclado. Você pode seguir um processo:

  1. O primeiro passo é, obviamente, aprender estes atalhos. Mas isso não é o suficiente, porque se você não os utilizar, sua habilidade não vai melhorar. Para medir essa habilidade, você precisa acompanhar a sua evolução.
  2. Então o segundo passo é configurar uma métrica. Para esse exemplo, pode ser a proporção entre o número de usos diretos versus o uso de atalhos.
  3. Usando essa métrica, você pode definir um objetivo e observar o seu progresso.

Com esse método, você será capaz de notar, baseado em fatos objetivos, que sua habilidade no uso de IDEs foi realmente aprimorada. Você sentirá uma satisfação pessoal maior de atingir objetivos do que você sentiria se você confia-se em um método por "impressão". Como sugestão, se você usa o IntelliJ, o plugin Key Promoter e o guia de produtividade são muito úteis para tal experimento.

Convencer os gerentes a te dar tempo para se aprimorar

Não é fácil convencer gerentes a te dar tempo. Quase todos os gerentes sabem, até certo ponto, que treinamento é uma boa prática, mas pressão acumulada geralmente os levam a reagir com pensamentos de curto prazo. Aprender uma nova habilidade se torna o tipo de tarefa que gerentes constantemente deixam de priorizar. Outro aspecto do problema, é o dilema da corporação, o que pode ser simplesmente apresentado como uma diálogo entre um CFO e um CEO:

CFO: "O que acontece se treinarmos e eles saírem?"

CEO: "O que acontece se não treinarmos e eles permanecerem?"

Como podemos quebrar esse fenômeno? Não há uma solução genérica. Há muitos fatores envolvidos (gerente, filosofia da empresa, etc.), dependendo da situação. Então, o que você deveria fazer?

Compartilhe um raciocínio comum

Uma parte inicial da solução é lembrar seu gerente de que o produto é um reflexo da equipe. O produto é resultado direto da equipe e, consequentemente, quanto mais pessoas habilidosas você tem, melhor é o produto que você terá. Treinamento se torna uma situação onde ambas as partes ganham. Você pode achar argumentos convincentes em uma busca na internet usando a frase "The team is the product" (o time é o produto).

Construa o seu caso

Conforme você busca o apoio do seu gerente, construa o seu caso falando linguagem gerencial. Deixe mais fácil para seu gerente entender a exatidão do seu pedido. Seu gerente vai provavelmente ter que usar os seus argumentos para defender seu caso para o gerente dele.

Há uma ferramenta genérica útil que pode te ajudar com o seu pedido: o processo "lean problem-solving". Pode ser descrito em um processo de quatro passos:

  1. Descreva um problema - qual é o problema?
  2. Traga à tona as consequências de não lidar com o problema - por que isso é importante?
  3. Encontre uma hipótese de causa - qual é a causa principal?
  4. Confirme experimentando soluções - qual é a solução?

No nosso contexto, você tem que primeiro voltar ao início e pensar sobre a habilidade: Por que ela é importante e o que está como problema subjacente para os negócios. Você pode organizar o primeiro passo da sua demonstração do problema descrevendo o impacto dele no cliente, no time e em você. Se você possuir métricas, é realmente uma vantagem. Gerentes adoram fatos.

Here is a sample request that follows the four steps outlined above: "We had X bugs raised by the client over the last Y weeks related to the database, so the team had to spend Z days to fix them. The cause is that our stored procedures do not support the actual and future growth of our client. We do not have enough knowledge to produce a robust stored procedure. I suggest that we invest time in training on this topic."

Descrevemos aqui um pedido simples que segue os quatro passos descritos acima:

Nós tínhamos X bugs criados pelo cliente nas últimas Y semanas relacionados ao banco de dados, então o time precisou gastar Z dias para consertá-los. A causa é que nossas stored procedures não suportam o crescimento atual e futuro de nosso cliente. Nós não temos conhecimento suficiente para desenvolver uma stored procedure mais robusta. E por este motivo, sugiro investirmos tempo em treinamento nesse tema.

Com essa ferramenta em suas mãos, deverá ser mais fácil convencer seu gerente.

Faça o treinamento valer a pena

Quando você conseguir tempo para treinar, é só o começo. Você terá que se organizar para tirar o melhor disso. Quão melhor o resultado que seu gerente enxergar, mais provável será você conseguir tempo para seus próximos treinamentos.

Conclusão

Este artigo discute como atingir rapidez e qualidade no desenvolvimento de software. Alguns desenvolvedores veem desenvolvimento de software como uma arte e não como performance, mas acreditamos que o desenvolvimento de software é formado por ambos. O problema de desempenho é raramente tão discutido como o de arte. Isso sempre foi um assunto tabu. A maioria dos desenvolvedores odeia falar sobre performance ou métricas. Estamos tentando quebrar este tabu. Esperamos que este artigo e nossas apresentações sobre este tema ajudem a promover uma discussão eficiente sobre este tópico controverso.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT