Eu sempre fui o tipo de desenvolvedor que gosta de resolver desafios. Fortemente acredito que foi isso que me levou a me aprofundar na resolução de problemas. Assim como eu, o universo tech está cheio de desenvolvedores que nem sabem que tem esse mesmo prazer em superar problemas aleatórios.

Dito isso, é desnecessário dizer que para manter nossa sanidade em dia nós precisamos saciar esses desejos resolvendo problemas. O que acontece é que, na prática, 70% do nosso trabalho não é literalmente programar, então não solucionamos tantos casos assim. E quanto mais tempo as partes estratégicas consomem do nosso dia-a-dia, mais frustrados vamos ficando por não termos esse momento de superação presente. Se você se identificou com isso, você precisa urgentemente participar de um coding dojo!

Mas o que é isso?

Coding dojo é um evento onde uma pessoa elabora um desafio para outros desenvolvedores resolverem tendo a única intenção de compartilhar conhecimento. E esse Know-How não se limita a habilidades técnicas: depois de participar de muitos dojos você acaba compartilhando o seu raciocínio lógico. Não tem forma melhor de aprender lógica sem ser na prática com quem já sabe, concorda?

Portanto, é em eventos assim que muitos iniciantes conseguem evoluir rapidamente e serem engajados a continuar crescendo no ramo. Além disso, ambientes com muitos coding dojos de linguagens diferentes também contribui para que os desenvolvedores conheçam outras áreas de trabalho, ajudando a entender se está onde realmente se sente bem, por exemplo.

Ok, entendi, mas como funciona?

É bem simples! Antes de partir para a explicação de como é o evento em si, vamos dar uns passos para trás e falar "quem é quem" nessa história.

Há pouco escrevi que alguém traz um problema para outros desenvolvedores resolverem, certo? Essa pessoa é chamada de Sensei. Afinal, ela trouxe o desafio. Em outros cenários daria até para chamar de Challenger ou Desafiante, que provoca todo um dojo a resolver o problema que imaginou. Ainda assim, não é correto trazer esses termos pois remete à competitividade e esse não é o foco do coding dojo.

Então se quem traz o desafio é o Sensei, todos os demais são os Discípulos ou Aprendizes, inspirado nos dojos de artes marciais. Porém, o que diferencia da prática real de um dojo, é que o sensei não está ali para guiar os discípulos no caminho de um aprendizado específico. No máximo ele traz o desafio e organiza o evento.

Parte dessa organização consiste em sortear uma "fila" com os aprendizes que vão participar da resolução do problema, chamando um por vez para formar um par. Se você já conhece essa prática, já deve estar imaginando do que se trata: pair programming - ou programação em dupla. Essa prática é amplamente utilizada ao redor do mundo, afinal, quem nunca ouviu a frase "Duas cabeças pensam melhor que uma"?

Enfim, dessa dupla, uma pessoa irá programar e a outra irá apenas auxiliar verbalmente. No caso de coding dojo, todo mundo está trabalhando em conjunto para resolver o mesmo problema. Portanto, não é permitido mais de uma dupla atuando ao mesmo tempo, é preciso trazer a ideia de que cada pessoa vai continuar o legado de quem estava trabalhando anteriormente. Isso é a melhor representação do que acontece na realidade, não é?

Agora é preciso criar mais dois papéis: Piloto e Co-piloto. Piloto é o discípulo que está codando, Co-piloto é quem está auxiliando. Essa dupla tem um tempo limite e, quando acaba, apenas registra o que fez e troca de lugares: o piloto sai, o co-piloto vira piloto e o próximo da fila é chamado para ser co-piloto.

Com isso, toda vez que o tempo acaba o sensei deverá ir rotacionando a fila de forma a sempre voltar para a dupla inicial, onde cada piloto irá contribuir para a resolução do problema.

É só isso?

Claro que não! Mas se você quiser fazer um coding dojo com isso já é o suficiente. Entendendo as necessidades e arranjando uma forma de saná-las, você conseguirá desenrolar esse tipo de evento onde quiser. Ainda assim, é preciso aproveitar esse momento de aprendizado para reforçar boas práticas de desenvolvimento.

Você já ouviu falar de TDD?

Test Driven Development é a arte de desenvolver orientado a testes, como diz o nome. Funciona em qualquer paradigma e linguagem desde que você possa automatizar testes unitários. É através dele que você poderá desenvolver testes antes de lançar o desafio como forma de garantir que todas as regras do problema foram cumpridas.

Ou você pode exigir como parte do desafio seguir o TDD, de forma que os pilotos precisarão criar testes antes de partir para qualquer solução. Afinal, é isso que é o TDD:

• identificar um problema minúsculo;
• criar um teste que garante que ele é real (ou seja, o teste falha);
• fazer a menor solução possível para fazer o teste passar;
• refatorar para tornar a menor solução em código limpo e otimizado.

Esses passos são absolutamente perfeitos para resoluções de coding dojo. Quem não os segue acaba tendo conflitos filosóficos no meio do desenvolvimento, por não ter pensado o suficiente antes de partir para a solução.

Ao mesmo tempo você ensina uma prática surpreendentemente eficaz e força a dinâmica a resolver pequenos problemas por vez até resolver o desafio como um todo.

Tá, o que eu ganho com isso?

Depende, qual vai ser seu papel no bolo?

• se for um Sensei, você estará contribuindo profundamente para a comunidade relacionada ao desafio que lançou, mesmo que seja um evento privado na empresa onde trabalha. É sério, pensa assim: tá todo mundo estressado de ver o mesmo código todo dia. Ao trazer um desafio de fora do contexto rotineiro, as pessoas voltam a ter paixão pelo código e voltam no dia seguinte meio refrescados para encarar os problemas de sempre;
• se for um Discípulo, você poderá conhecer outros desenvolvedores no evento, aprender funções e/ou técnicas que você nem sonhava existir, descobrir recursos presentes na IDE que sempre usa, ver outras formas de raciocinar sobre problemas e, por último mas não menos importante, fazer as pessoas te conhecerem e aprenderem com você o que você já sabe;
• se for apenas assistir, você fará parte da plateia que está ali para motivar o sensei e os discípulos a continuar organizando eventos, pois demonstra um mínimo de interesse. Você vai acabar aprendendo também mas não tanto quanto os discípulos, pois eles estão colocando a mão na massa. Não tem problema nenhum em ir só assistir, mas se você se sentir empolgado, não perca a chance de pedir para participar. A menos que seja um evento extremamente popular pode ser que te encaixem ali, hehe.

E está aí o que você pode ganhar. Acabei falando bem vagamente sobre isso pois acredito que dessa forma esse artigo possa ajudar qualquer pessoa a desenrolar esses eventos para qualquer skill.

Se interessou? Eu escrevi alguns artigos sobre isso no meu LinkedIn , o que mais faz sentido pra quem está interessado em organizar um dojo é o guia " Coding Dojo: como fazer?". Lá explica como criar o ambiente da stack PHP, quais apps usar para fazer o evento on-line, etc. Se você não quiser ser o sensei mas quiser ver esse evento rolando na sua empresa ou entre seus amigos, tente engajá-los a fazer! É bem divertido.

Enfim, é isso... Se ficou com alguma dúvida não hesite em comentar!

Inté!