Pair Programming: Motivação e Interação
Oiee. Vim compartilhar a minha experiência no desenvolvimento do app Amoriá, um projeto de estudo no qual eu e minha squad nos debruçamos durante aproximadamente 2 meses como base de aprendizado de diversas ferramentas. Mais especificamente, eu irei abordar um dos momentos de maior aprendizado para mim, que ocorreu na etapa de código do projeto: O Pair Programming. Mas vamos com calma, caro leitor. Talvez chegou aqui por acaso e não tem a mínima ideia do que eu estou falando. Que tal uma breve introdução?
Na Academy, local onde sou estudante, emprega-se o método CBL (Challenge Based Learning), no qual o próprio aluno é posicionado de forma ativa no seu aprendizado. É proposto um desafio, é oferecido acesso a algumas ferramentas e somo jogados na missão de solucionar esse desafio, no caso, o desenvolvimento de um aplicativo Mobile. O meu grupo decidiu por trabalhar a temática de Cultura, buscando meios de facilitar o acesso para espaços culturais para a cidade do Recife. Era para ser muito mais, no entanto por diversas restrições técnicas e de tempo (carinha de choro), a solução se limitou a ser um catálogo de espaços culturais, coisa boba.
Coisa boba uma pinoia. Foi muito muito muito desafiador fazer essa ****. O grande desafio se deu devido ao fato do grupo ser formado por 2 designers, Danielzinho e Monteiro, 1 gestor da informação, Hubvandro, e eu, um estudante de psicologia que se aventura no mundo do código. Ou seja, nosso grupo era deficitário em competências de desenvolvimento. Estávamos num navio que havia passado pelas águas da Inovação, seguido do mar de Design e agora estávamos adentrando o oceano profundo e tenebroso da etapa de Desenvolvimento. Por ter mais experiência com código, os meus companheiros contavam comigo para assumir o leme e guiar o grupo nessa parte. Mesmo com todas as minhas inseguranças, abracei o desafio, meio com medo, meio ansioso. Vivendo na corda bamba entre “pode mandar, eu tanko” e “eu não consigo fazer isso sozinho”. Em terra de cego, quem tem um olho meio capenga, que consegue distinguir vultos e formas, já tem o suficiente pra guiar os outros.
Nos primeiros dias eu sofri. O sentimento de solidão por um momento foi tamanha. Eu não sabia como construir o app, mas tinha alguma noção de por onde começar. Sabia quais componentes usar, apesar de não saber implementá-los. Qual arquitetura, como organizar, como dividir tasks. Nada disso eu sabia, mas sabia que se ficasse parado o app que o grupo passou tantas semanas trabalhando não iria se tornar realidade.
Mas calma lá. De novo. Eu não estava sozinho. Nunca estive, aliás. O meu grupo acreditava muito em mim. Eles não tinham a mínima ideia do quanto eu me sentia inseguro, mas ainda assim pareciam completamente confiantes em me colocar na posição de liderança durante esse processo. Tudo mudou quando um colega, agora não me lembro se foi Monteiro ou Danielzinho, fez a proposta de programar juntos. Eu ditava o código que precisava ser escrito e a outra pessoa controlava o teclado, fazendo perguntas quando achava necessário.
Foi nesse momento que o projeto ganhou outra dimensão para mim. Ficar no banco do carona, como copiloto, me dava a possibilidade de pensar no código mais estruturalmente, no lugar de ter que me preocupar se estava escrevendo os nomes das variáveis da forma correta ou se a sintaxe estava compatível. Eu confesso que sou meio desatento e termino cometendo muitos erros de digitação, como comer algumas palavras. Fato esse que Monteiro nunca deixava passar em branco e sempre tinha uma piada pronta para zonar com a minha cara.
E assim boa parte do projeto se desenrolou, os meus colegas se alternavam na posição de piloto enquanto eu fazia propostas para os desafios. O processo se deu muito dentro de uma metacognição. Eu falava o meu pensamento em voz alta, prestando atenção para ser o mais explícito e objetivo nas minhas orientações. Isso deu certo uma vez que buscava ouvir a minha intuição, mas precisava dar uma lógica seguindo um raciocínio verbal. Usar da fala para guiar os meus companheiros me permitiu organizar melhor o meu próprio pensamento. O mais interessante disso tudo é que esse processo é exatamente uma das funções da linguagem que estudei no meu curso, só que de forma bem mais desconectada com a realidade. Com esse projeto, tive a chance de ver uma aplicação direta e prática de conteúdos muitas vezes excessivamente teóricos do curso de psicologia.
Claro que em várias situações deu errado. Build Failed. No entanto, estar em companhia me gerava motivação para continuar tentando desvendar o código. “Xxiii crashou…. Bora tentar entender o que houve, Hubzão”. E assim ficávamos tentando e tentando até que finalmente vinha um build Complete. Além disso, esses momentos permitiam aos meus companheiros a irem se habituando com a sintaxe e lógica por trás do código. Aos pouquinhos indo se familiarizando e perdendo o medo. Evidentemente, cada um em seu nível, mas todos tiveram receberam estímulos.
Isso me fez lembrar de outra ponte de conexão com o meu curso. Um bom senhor russo chamado Lev Vygotsky foi um importante teórico da psicologia do desenvolvimento (e de muitas outras áreas) e dentre as suas diversas contribuições, criou o conceito de Zona de Desenvolvimento Proximal, ou simplesmente ZPD para os mais íntimos. É um conceito meio complexo que envolve outros pontos, mas explicando brevemente ele poderia ser entendido como o processo de aprendizagem de um indivíduo, no qual ele se divide na potencialidade de aprender algo, no qual ainda não consegue superar um desafio sem a ajudar externa, e de fato na aquisição de um conhecimento, no qual demonstra autonomia para aplicar os conhecimentos de forma autônoma para solucionar problemas. Existe um momento específico dessa zona em que o sujeito está prestes a adquirir o conhecimento, no qual a intervenção de um mentor ou professor é extremamente eficaz em expandir o seu conhecimento.
Podemos pensar que uma professora do nível infantil precisa entender as diferentes fases do desenvolvimento das crianças de uma turma para ensinar matemática, por exemplo. Isso aconteceria por que cada criança teria o seu próprio tempo e momento específico em que a intervenção da professora se mostra mais eficaz para o seu desenvolvimento. Ficou meio confuso? Vamos resumir que se trata sobre entender que o orientador precisa compreender em que posição do processo está o orientado, para ai saber o estímulo adequado para o desenvolvimento. Ainda confuso? Não adianta tentar explicar derivada e integral quando se ainda não se domina operações matemáticas básicas.
Escrevendo agora, percebo o quanto daria pra relacionar esse conceito com o CBL proposto na Academy. Quem sabe num próximo artigo eu invisto nisso. Voltando agora para o Pair Progamming. O maior salto de desenvolvimento em código ocorreu com Monteiro, um dos designers da minha squad. Com apenas algumas sessões de programação em par, ele se sentiu à vontade o suficiente para arriscar assumir para si a responsabilidade de algumas tasks. Um homizão. Equipado com alguns tutoriais no YouTube, um código meu de referência e um sonho, esse jovem buscou sozinho dar conta de ViewControllers, TableViews e delegates. Build Failed. Deu errado. “Mig, por que o meu código não funciona?”. Eu não tinha a menor ideia, mas sentamos juntos, discutimos o que tinha sido feito até que conseguimos o tão sonhado Build Succeded.
Podemos pensar que o pair programming foi o estímulo adequado para potencializar o nosso conhecimento. Tanto para mim, quanto para Monteiro, cada um em sua especificidade. Monteiro havia saído de um estado de “Vou ficar quieto” para uma autonomia e crença em suas competências e potencialidades em código. As minhas orientações e falas nos momentos de programação em par puderam se tornar mais técnicas, menos claras, uma vez que estávamos cada vez mais próximos em entendimento do código. Agora monteiro declarava variáveis, definia funções e implementava delegates e dataSources sozinho. Um orgulho danado. Ao final do Challenge, eu tenho certeza que Monteiro possui as mesmas competências em código para certas coisas quanto eu, ele só parece que levará algum tempo para reconhecer isso.
Os meus outros companheiros também se desenvolveram, cada um em seu nível e ritmo. Com um pouco mais de assistência, Danielzinho conseguiu construir uma tela programaticamente, tirando dúvidas e se esforçando ao máximo para assimilar os conceitos. Hubzão, teve a oportunidade de se familiarizar um pouco mais com o código.
Para mim, ficou a certeza de que se conectar com pessoas é algo muito especial. Que a dinâmica de me ensinar uma coisa que eu te ensino outra, ou simplesmente vamos aprender isso juntos, é uma ferramenta poderosíssima de afastar a solidão. Não achem que eu assumi sempre a posição de copiloto. Uma vez que os meus companheiros contavam comigo, em vários momentos buscava fazer pair progamming com alunos mais experientes de outros grupos, que solidariamente me explicavam conceitos. Querer atuar no desenvolvimento dos meus companheiros me motivou a querer aprender mais, o que se refletiu no desenvolvimento deles e do meu próprio. No final eu sou muito muito grato ao meu grupo por ter me colocado nessa posição, com toda a liberdade do mundo para ditar o ritmo do projeto. Espero que eles possam ter aprendido tanto comigo quanto eu aprendi com eles.
Algumas noites sem dormir, muitos energéticos, alguns momentos de desespero. Posso dizer de certeza que foi cansativo, e muito, mas que aprendi muito. Fiz o que precisava fazer para balancear a produção e entrega do nosso app com o desenvolvimento de todos. Eu confesso que sou um cara muito sortudo, que no passado, as pessoas sempre tiveram muita paciência e cuidado para lidar comigo, acolhendo os meus erros e nunca desistindo de mim. A única coisa que sei é que buscar devolver um pouco disso que eu tive de sobra é algo que me define durante essa etapa da vida.
