Photo de Sven Brandsma no Unsplash

NOTA: Eu escrevi este post originalmente para o blog da SubMain. Caso lhe interesse, você pode ler o post original no site deles, em inglês. Enquanto estiver por lá, aproveite para dar uma olhada no CodeIt.Right, uma ferramenta para automatizar revisões de código.

Você está familiarizado com a expressão “afiar a serra” no contexto de aprendizagem e melhoria contínua? Se você leu o livro de Stephen Covey chamado “Os Sete Hábitos das Pessoas Altamente Eficazes”, então tenho certeza que você está. Para quem não está familiarizado com o termo, significa basicamente se engajar em práticas que o tornarão melhor em sua profissão ou arte.

O que você como líder técnico, desenvolvedor líder ou arquiteto de software pode fazer para incentivar os desenvolvedores de sua equipe a “afiar suas serra”? Isso é o que vamos responder com este post. Vamos mostrar a você quatro maneiras rápidas e fáceis de sua equipe melhorar suas habilidades e agregar mais valor.

1. Afiando a Serra pela Leitura: Criar um Clube do Livro Técnico

Não seria fantástico ter uma equipe formada por pessoas incrivelmente bem informadas, atualizadas com as novidades relevantes, e com sólidos conhecimentos sobre os fundamentos da nossa indústria? Sim, eu pensei que sim. E não há melhor maneira de conseguir isso do que lendo.

O que eu sugiro aqui é algo muito simples. Todos os meses, você e sua equipe escolhem uma leitura designada para a equipe de desenvolvimento. Sobre que assunto, você pergunta? Padrões de design, concorrência, refatoração, teste unitário - eu diria que praticamente tudo é jogo justo, desde que os próprios desenvolvedores estejam interessados.

Ah, e antes que eu esqueça: isso provavelmente não precisa ser mencionado, mas sua empresa deve comprar aos desenvolvedores cópias dos livros escolhidos. Se você sente que não pode pagar isso, bem, eu não acredito que você vai ter uma empresa por muito tempo, pra ser sincero.

Uma solução menos ideal seria comprar uma cópia do livro para um desenvolvedor. Peça que estudem o livro em seu tempo livre e depois apresentem suas descobertas para o resto da equipe, dando uma ou mais palestras internas. Em seguida, selecione outro livro e outro membro da equipe, e peça a esse desenvolvedor que dê a palestra interna no próximo mês.

Agora, falando em conversas internas…

2. Afiando a Serra Através de Palestras: Apresentações Internas

Fazer com que os desenvolvedores façam palestras internas uns com os outros é uma ótima maneira de disseminar o conhecimento por toda a empresa. Para os desenvolvedores que dão a palestra, é a oportunidade perfeita para praticar várias habilidades, tais como:

  • Aprender um assunto e fazer as pesquisas necessárias.
  • Criar slides bem feitos.
  • Falar em público, o que pode ser uma experiência difícil para muitos de nós.
  • Responder perguntas.

Eu poderia continuar, mas em resumo, eles estarão praticando a habilidade geral de comunicação. Isso simplesmente não tem preço. Dar palestras internas pode ser uma ótima prática para falar em conferências, por exemplo.

E qual a vantagem para quem assiste a palestra? Obviamente, a oportunidade de aprendizado. Mas vou acrescentar que, no caso das conversas internas da empresa, a probabilidade de realmente colocar em uso esse conhecimento que você adquiriu é muito maior. Como os palestrantes são na verdade seus colegas de trabalho - pessoas que compartilham o contexto com você todos os dias e estão cientes dos problemas e desafios que sua empresa está enfrentando - eu diria que é muito provável que eles escolham um tópico que se relacione com a empresa.

3. Afiando a Serra Com a Escrita: Criar e Manter um Blog de Tecnologia

Quando seus desenvolvedores dão palestras internas, eles estão ensinando uns aos outros, o que é fantástico. Mas e se eles pudessem disseminar esse conhecimento para além da sua empersa, ao mesmo tempo em que melhoram a sua capacidade de escrita e de articular um argumento? E se eles pudessem fazer isso enquanto aprendem sobre coisas como marketing de conteúdo e SEO? Melhor ainda, e se eles pudessem demonstrar o know-how técnico de sua empresa, posicionando-a como especialista em sua área de domínio?

Há uma maneira de fazer exatamente isso, e chama-se blogging.

Inicie um blog de engenharia de software. Decida sobre as especificidades, como por exemplo:

  • Quais tópicos devem ser abordados?
  • Com que freqüência você vai publicar?
  • Quem serão os autores?

Faria sentido se, pelo menos no início, os desenvolvedores que são naturalmente melhores escritores fossem os autores do blog. Mas como o objetivo aqui é aprender a afiar a serra - o cenário ideal é aquele em que todo desenvolvedor tem a chance de afiar suas costeletas de escrita.

4. Afiação da Serra por Programação: Coding Dojos Na Empresa

Um coding dojo é uma espécie de sessão de treinamento na qual as pessoas revezam em pares, trabalhando de forma colaborativa sobre o mesmo problema. A inspiração para o nome vem das artes marciais. O objetivo de um dojo não é necessariamente resolver o problema… mas desenvolver tanto habilidades de engenharia, como testes unitários/TDD, quanto habilidades sociais, como programação em pares.

Para realizar um dojo de codificação, você vai precisar do seguinte:

Espaço. Você precisa de um lugar grande o suficiente para acomodar de 5 a 15 pessoas. (Algumas pessoas dizem que 20 pessoas para um dojo codificador é aceitável, mas IMHO, isso é demais). Já que estamos falando em afiar as serras da sua equipe, um escritório ou sala de reuniões na sua empresa provavelmente serve.

  • Um computador**. Pode ser um computador desktop ou laptop; não importa, desde que seja colocado em uma mesa com duas cadeiras, onde duas pessoas possam sentar-se e colaborar confortavelmente juntas.
  • Um projetor ou um monitor grande**. Todos os participantes precisam observar o que está acontecendo em um determinado momento.
  • Lanches! Um dojo codificador deve ser uma experiência de união, e os seres humanos adoram se conectar sobre a comida e a bebida. E os programadores são seres humanos, da última vez que verifiquei. Basta ser atencioso com aqueles com restrições alimentares e tudo vai dar certo.

Então, você resolveu fazer isso. Você montou o equipamento necessário, e as pessoas apareceram no local combinado. E agora?

Bem, começando do começo. Você precisa de um problema! Mas nem todos os desafios de programação são um bom problema de codificação do dojo. Como eu disse anteriormente, resolver o problema não é necessariamente o objetivo, mas sim praticar habilidades de engenharia como TDD e programação em pares. Então, escrever um compilador a partir do zero não rola. Mas implementar um conversor para numerais romanos pode funcionar muito bem.

Quais são as características de um bom problema para um coding dojo?

  • É pequeno, então é viável resolvê-lo em um tempo relativamente curto.
  • Empresta-se bem à TDD.
  • É finito e bem definido. Desafios vagos e em aberto não servem.
  • É baseado em um problema do mundo real, não um problema abstrato.
  • É diferente dos desafios que você resolve no seu trabalho diário.

Você não precisa se preocupar em encontrar bons problemas, no entanto. A web resolve seu problemaEla está cheia de fontes para problemas lá fora.

Com a escolha do problema fora do caminho, é hora de escolher uma linguagem de programação. Você não precisa usar a mesma linguagem que você usa todos os dias em seu trabalho. Na verdade, é bom usar o dojo como uma oportunidade para experimentar diferentes linguagens. Isso pode ajudar a tornar as coisas novas e mais desafiadoras. Só não se esqueça de ter por perto uma pessoa que conheça bem essa linguagem para que ela possa ajudar quando o grupo tiver dúvidas.

Agora, para começar, você vai precisar de dois voluntários: um para ser o motorista e outro para ser o co-piloto. Estes termos vêm da programação em pares. O motorista é a pessoa que está digitando, e o co-piloto dá conselhos e feedback. As demais pessoas são o público, pelo menos por enquanto. O ideal seria que todos em uma sessão de dojo escrevessem código.

Então, com todos em seus lugares, a diversão começa. O motorista começa a codificar, usando o ciclo vermelho-verde-refatorar da TDD:

  • Primeiro, a pessoa que está na posição de motorista escreve um teste que falha.
  • Então, ela escreve apenas a menor quantidade possível de código que vai fazer o teste passar.
  • Quando o teste está passando, é hora de refatorar. Somente nesta fase as pessoas na platéia têm permissão para falar, dando conselhos e feedback para ajudar o motorista a refatorar melhor o código.

Ao final de um período de tempo previamente estabelecido (cinco a dez minutos), o motorista pára de codificar e retorna à audiência. O co-piloto torna-se o motorista, e um novo membro da audiência torna-se o co-piloto.

Este ciclo continua até que todos na sala tenham escrito o código ou até que o tempo previsto para a sessão expire - o que vier primeiro.

Retrospectiva

Assim que a sessão de codificação propriamente dita estiver concluída, dedique algum tempo para fazer uma retrospectiva. Pergunte aos participantes sobre as coisas que eles gostaram e não gostaram da sessão, e escreva tudo isso. Estas duas listas servirão como uma diretriz para o que fazer e não fazer em seus futuros dojos de codificação.

Conclusão

O desenvolvimento de software é uma profissão de prática. Requer aprendizagem contínua - ou melhor, afiação contínua da serra. Além das dicas que acabei de lhe dar, há muitas outras maneiras de afiar sua serra. Na verdade, você está fazendo um deles agora mesmo. Você está lendo um blog técnico!

Desde tutoriais aprofundados sobre ferramentas como CodeIt.Right que podem ajudar sua equipe a escrever melhor código?até insights sobre melhores práticas?até mesmo dicas sobre coisas você pode ter tomado como certo, não faltam tópicos interessantes e úteis que você pode aprender lendo um bom blog sobre tecnologia.

Obrigado pela leitura!

Encontrou algum erro no post? Sugira uma edição